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.
We publish dev-hardware truth. These figures were measured on Apple M4 Max (dev), macOS — server-class validation pending. When we re-run on server-class hardware, this page updates from a single data file, 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.
event → subscriber emit latency
Flat from an empty committed tail to 2M rows — up to ~37,393× faster than the pre-redesign path at the 2M-row tail.
BM_NewStreamEventToEmit/{0..2000000}/manual_time
310 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 (Apple M4 Max (dev), macOS).
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 (d4a3885b) 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.
1166 benchmark cases, v1.9.4, 16 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:
- Multi-thread ingest scaling curves — dev-box contention makes them non-reproducible (confidence: low). The server-class-validation banner covers this.
- 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 ingest throughput and wire point-read latency — a dev box under load is not representative; ingest figures here are engine-side.
Bench cases excluded from this corpus
- nyxdb-bench-part-flusher — BENCH BUG (#438) — 0 cases capturedCREATE TABLE in the fixture omits the now-required SETTINGS storage_policy='<policy>'; the engine rejects it and the bench SIGABRTs before any case runs. Bit-rot vs the current DDL contract (tracked in #438) — noted, not fixed.
- nyxdb-bench-storage — 2 of 9 cases droppedBM_PolicyResolve and BM_PolicyPickDiskJbod SIGSEGV deterministically (3/3) at this commit. Captured the working PartStoreOpen/List/Publish cases; the two policy-resolution cases are a bench/engine crash — noted, not fixed.
- 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-index-maintainer — ERRORED — 5 case(s) excluded (never emitted with median 0)seed failed
- nyxdb-bench-stream-latency-under-ingest — ERRORED — 2 case(s) excluded (never emitted with median 0)ingest-probe CREATE failed
- nyxdb-bench-streaming — ERRORED — 1 case(s) excluded (never emitted with median 0)stream delivery stalled
- streaming_segB — ERRORED — 1 case(s) excluded (never emitted with median 0)stream delivery stalled