DB
Back homeIndustry

AdTech

Microsecond bid-path lookups and exact impression and frequency counts — the counts that decide spend, never approximate.

The problem

Why this is hard today

Ad serving is one of the tightest latency budgets in software: the bid path has milliseconds to look up audience and budget state, and it runs millions of times a second. Frequency capping and budget pacing depend on counts that are correct — an approximate impression count is money spent wrong.

The standard stack caches audience and budget state in one system and counts impressions in another, reconciled after the fact. The bid path reads a snapshot that predates the current request, and "how many times has this user seen this ad" is an estimate that drifts.

What ad serving needs is microsecond state lookups on the bid path and exact impression/frequency counts read-your-writes — so a cap is enforced against the impression that just served, not one from a minute ago.

Where NYXDB fits

Use-case journeys

Real-time bidding

Microsecond audience and budget lookups on the bid path.

Caching & real-time serving

Exact impression & frequency caps

Counts that decide spend, never sampled — enforced read-your-writes.

Fraud & risk

Attribution pipelines

Join impressions to conversions with continuous transforms, in-database.

Observability & logs

Architecture

How NYXDB fits AdTech

Audience and budget state live in in-memory keyed tables read on the bid path; impressions append and roll into exact per-user/per-campaign counters through transforms — exact counts, no reconciliation.

  1. 01

    Bid-path lookup

    Audience/budget state in memory-resident keyed tables — µs reads.

  2. 02

    Count exactly

    Impressions append; keyed counters maintain exact per-user/per-campaign counts.

  3. 03

    Frequency cap

    A read-your-writes count enforces the cap against the impression that just served.

  4. 04

    Attribute

    Continuous transforms join impressions to conversions for attribution.

Real SQL

Representative query

Exact frequency capping
CREATE TABLE impressions_by_user (
  user_id     UInt64 NOT NULL,
  campaign_id UInt64 NOT NULL,
  seen        UInt64,
  PRIMARY KEY (user_id, campaign_id)
) SETTINGS mode='keyed', layout='row', storage_policy='memory_data';
SELECT seen FROM impressions_by_user
WHERE user_id = 7 AND campaign_id = 42;

Every statement follows the engine’s own test SQL shapes. See the SQL reference for full syntax.

Capabilities

What you get

Microsecond bid path

Memory-resident keyed lookups.

Exact counts

Impression and frequency counts are exact, not sampled.

Read-your-writes

Caps enforced against the impression that just served.

Attribution transforms

Join impressions to conversions in-database.

Proof

Measured on the vetted benchmark lane

71.6ns

bid-path point consult on warm postings

in-memory keyed read

vetted table

View benchmark230 ns

exact frequency count(), O(1)

flat 1k–16k keys

vetted table

View benchmark2.66M rows/s

durable ingest, single core

1M-row batches (~232B, 16-col)

group-fsync default

View benchmark

Measured on Apple M4 Max (dev), macOS — server-class validation pending. Release build, median of 5, commit-pinned (d4a3885b, 2026-07-07). Ingest figures are engine-side. See the full benchmark suite.

Learn more

Related documentation

Keyed tables

Exact keyed counters.

Transforms

Attribution pipelines.

Functions

Aggregates and windows.

Exact counts on the bid path

Explore caching & real-time serving or run a node.

Get started Read the docs