DB
Benchmarks

Every number, measured — and where the reference wins, we say so

The full suite: Release build, median of 5, commit-pinned, hardware-labeled. No estimated numbers, no lab-tuned cherry-picks — the whole point of a financial-grade engine is that you can trust the measurement.

~2.56µs
event → subscriber, flat
flat from empty to 2M-row tail — up to ~53,150× vs the pre-redesign path
~900ns
sharded point lookup
warm postings
~48×
HNSW ANN vs brute force
VectorTopKProbe vs BruteForceKnn (cosine)
1293cases
benchmark cases published
commit 7945ae33 · median of 5

We publish measured truth. These figures were measured on AMD EPYC 9554P 64-Core Processor (64t), 1505GB RAM, 6x NVMe measured on server-class hardware. This page renders from a single data file: every re-run swaps the corpus, and every number moves with it.

Streaming & PSI

The redesigned PSI event path propagates a committed change to a subscriber in a flat ~3.2µs — from an empty tail all the way to a 2M-row committed tail. The pre-redesign path degraded with tail size to ~136ms; the flat line is the headline.

~2.56µs

event → subscriber emit latency

Flat from an empty committed tail to 2M rows — up to ~53,150× faster than the pre-redesign path at the 2M-row tail.

BM_NewStreamEventToEmit/{0..2000000}/manual_time

010k100k1M2M2.8µs3.5µs2.84µs3.37µs2.56µs136ms
NYXDB (redesigned PSI)pre-redesign pathevent → emit latency vs committed-tail size · log scale

323 cases

Methodology

How we measure — and why you can trust it

For a database that markets financial-grade correctness, the benchmark methodology is not a footnote — it is the product claim. Here is exactly how every number on this page is produced.

Release build

Optimized Release builds only — never debug or sanitizer builds — on labeled hardware (AMD EPYC 9554P 64-Core Processor (64t), 1505GB RAM, 6x NVMe).

Median of 5

Each figure is the median of repeated runs, not a best-of. Outliers do not become headlines.

Commit-pinned

Every number is tied to a specific engine commit (7945ae33) so a result is reproducible against the exact source.

No unmeasured claims

If a bench is not wired or not reproducible, its number is omitted — not estimated. Where a reference kernel wins, we show it.

One data file drives this page

Every figure — here, in the landing benchmark section, and in each solution’s proof strip — reads from a single bundled dataset. It is compiled into the static site at build time, so there is no runtime fetch and no way for the page to drift from the source of truth. Re-running the suite on server-class hardware is a one-file swap; the entire site updates with it.

1293 benchmark cases, v1.9.5, 64 CPUs. This file is generated from the consolidated corpus by scripts/build-benchmarks.mjs and is the single source of truth for every performance figure on the site; a server-class re-run is a one-file swap.

Times auto-scale to the unit that reads cleanly (ns / µs / ms / s); every figure is the measured median in its native unit. Bars are log-scaled relative to the largest magnitude in the category, so rows of very different scale stay legible; bar length is a visual aid, not a linear ratio.

What we didn’t measure — and won’t claim

Saying what we left out is part of the measurement. These are held back on purpose:

  • Ephemeral / no-WAL durability numbers at any batch size — a known storage-path artifact (engineering-tracked). We publish the durable sweep instead.
  • Amortized "billions of items/s" GB counters as throughput claims — we render measured median + unit only.
  • Wire-protocol end-to-end ingest/read latency — figures here are engine-side by design; the wire adds client and network variables that belong in a separate, clearly-labeled measurement.
  • Single-core pinned numbers for internally-threaded benchmarks — whole-process pinning distorts cross-thread paths, so pinning is restricted to single-threaded kernel families.

Bench cases excluded from this corpus

  • nyxdb-bench-index-maintainer — EXCLUDED — no publishable datano cases
  • nyxdb-bench-access-policy — EXCLUDED — no publishable dataEXCLUDED by disposition: full-filter runs exceed every wall budget on this box (600s rc124 both capture nights); the salvageable remnant (2 cases) is below publishable quality. Needs a bench-side fixture rework before its numbers can be published.
  • nyxdb-bench-block-ingest — 2 slow cases droppedBM_DurableHashShardedBlockWalIngest and BM_DurableTradeBlockWalIngest DROP+CREATE a 32-shard table every iteration, triggering a committed-tail 'relation is changing; retry' storm (500k+ warnings) that spins many minutes under machine contention. Excluded to keep the run bounded; the durability sweep, block/sql insert, and the concurrent scaling curve are all captured.
  • nyxdb-bench-enrichment-join — ERRORED — 9 case(s) excluded (never emitted with median 0)join produced no rows
  • nyxdb-bench-functions — ERRORED — 4 case(s) excluded (never emitted with median 0)no synthetic input shape executed successfully
  • nyxdb-bench-stream-latency-under-ingest — ERRORED — 2 case(s) excluded (never emitted with median 0)ingest-probe CREATE failed