Every run, dated and raw.
Each report names its commit, host, tool and raw result file, and transcribes the tables as they were written. Every number is indicative: a shared development host, one node, data that fits in memory. Nothing here is a performance promise.
7 reports
10 to 23 October 2026, from the repository's docs/bench directory.
One host
All on sttiz, a shared production VPS: 8 vCPU for the first run, capped at 3 CPUs and 6 GB after that. Indicative, not a production promise.
Newest first
Four areas: the storage engine against RocksDB, the correctness campaign, analytics against DuckDB, and SQL through the gateway.
SQL through the gateway: first latency
· SQL gateway
First pgbench runs through the gateway: a one-row insert takes about 1 ms, but a primary-key lookup costs as much as a GROUP BY and nothing scales with clients.
The OLTP path through the gateway (P3b)
· SQL gateway
Primary-key seeks, a per-session catalog cache and prepared statements: a key lookup from 5.52 ms to 0.143 ms, 10 608 lookups/s at 8 clients; aggregates same.
TPC-H on columnar collections, SF 0.1
· Analytics
The same five TPC-H queries on row and columnar storage: columnar is 2.5–7.3× faster than row storage, 11–46× slower than single-threaded DuckDB, answers equal.
P2c differential: ten million plans
· Correctness
Ten million generated plans checked against the reference interpreter, every optimizer rewrite and the encoding round trip, plus isolation checks: 0 failures.
TPC-H SF 0.1 vs DuckDB through P2d, P2e
· Analytics
Five TPC-H queries at SF 0.1: answers equal DuckDB's but 137–1 408× slower at first; projected scans and vectorized expressions got them to 37–255× that day.
Storage engine: compaction, group commit
· Storage engine
Six re-runs, same host and parameters: point reads to 412k/s, worst write latency 371 ms to 23 ms, memory at or below RocksDB's, group commit at 32 clients.
First results: storage engine vs RocksDB
· Storage engine
First YCSB-style runs of the storage engine next to RocksDB on a shared host: write stalls up to 0.5 s, point reads 2.8× slower, scans fixed by a lazy merge.
What indicative means
Shared host
A production VPS with other services running, capped at 3 CPUs and 6 GB for the later runs (8 vCPU for the first). Tail latencies move from run to run for reasons unrelated to the engine.
Small data, one client
Key-value datasets of about 35 MB and TPC-H at scale factor 0.1 fit the page cache. Most runs use one client; the group-commit and pgbench runs use up to 32 and 8.
Before any claim
The claims policy requires a dedicated, idle host, a named baseline at a stated version, and the raw JSON. That host is not in place yet, so these pages publish measurements, not targets.
Comparison engines: RocksDB as the key-value oracle, DuckDB 1.1.3 for TPC-H (one and three threads), pgbench 16 for SQL. Each is run on the same host in the same session as UltraFabric.
Repeat the runs on your own hardware.
Early-access teams receive the benchmark scripts and the comparison baselines with the build.