Engineered for Real-World Performance.
Every figure on this page comes from a dated benchmark report in the repository, with the host and the tool named. Numbers are indicative: a shared development host, one node, data in memory. The dedicated benchmark host is still ahead.
Benchmark results
All runs on a shared development host, 3 CPUs / 6 GB; indicative, not a production promise. Raw result files accompany each report.
Key-value engine
Operations per second, YCSB-style, fsync on every write (19 Oct 2026)
TPC-H SF 0.1, seconds (log scale)
Row vs columnar storage vs DuckDB 1.1.3 one thread; all answers equal (22 Oct 2026)
Progress across phases
Seconds per query as the executor and storage improved, 21–22 Oct 2026
Key benchmark results
What was measured, with the comparison engine on the same host and the same day
| Workload | UltraFabric | Compared to | Note |
|---|---|---|---|
| Point reads (YCSB C) | 412,447 ops/s | RocksDB 274,508 | RocksDB keeps a lower p99 |
| Short scans (YCSB E) | 22,655 ops/s | RocksDB 21,927 | On par |
| Worst write latency | 23 ms | 371 ms before | Incremental compaction |
| Write-heavy RSS | 32 MB | RocksDB 26 MB | Disk use smaller |
| TPC-H Q1, SF 0.1, columnar | 0.308 s | DuckDB 0.0128 s | Row storage 0.869 s; answers equal |
| TPC-H Q3, SF 0.1, columnar | 0.166 s | DuckDB 0.0085 s | Row storage 0.71 s; answers equal |
| TPC-H Q5, SF 0.1, columnar | 0.363 s | DuckDB 0.0078 s | Row storage 0.896 s; answers equal |
| TPC-H Q6, SF 0.1, columnar | 0.074 s | DuckDB 0.002 s | Row storage 0.535 s; answers equal |
| TPC-H Q10, SF 0.1, columnar | 0.245 s | DuckDB 0.0229 s | Row storage 0.771 s; answers equal |
SQL through the gateway
pgbench, prepared statements, loopback TCP → gateway → node (23 Oct 2026); "before" is the same run one day earlier, without key seeks
| Statement | Clients | Avg ms | Before | Stmts/s |
|---|---|---|---|---|
| Primary-key SELECT | 1 | 0.143 | 5.52 | 6,984 |
| Primary-key SELECT | 8 | 0.767 | 41.7 | 10,608 |
| GROUP BY with count and sum | 1 | 5.38 | 5.64 | 189 |
| Single-row INSERT | 1 | 0.922 | 1.06 | 1,149 |
| Single-row INSERT | 8 | 6.17 | 6.8 | 1,296 |
Honest reading: key lookups now seek (one row read instead of the tenant's ten thousand), so eight clients reach ten thousand lookups a second. Aggregates still read every row on one engine thread and inserts wait on the write-ahead log sync; parallel reads and group commit for inserts are the next levers.
Tested before it is trusted
Speed numbers only matter if the answers are right. These are the counts behind that claim.
How these were measured
1Environment
Shared development server, 3 CPUs and 6 GB cap, other services running, one client, data in memory. One node. No dedicated hardware yet.
2Datasets
TPC-H SF 0.1 generated by DuckDB's dbgen (lineitem 600 572 rows); YCSB-style key-value workloads; 10 000 and 100 rows per tenant for the SQL run.
3Tools
The project's own kvbench with a RocksDB oracle, uf-tpch against DuckDB 1.1.3, pgbench 16 over the gateway, and the nightly differential runner.
4Metrics
Operations per second, median of three runs including planning for TPC-H, average latency and statements per second for SQL, and exact answer equality against the comparison engine.
Reproducible
Every report names its commit, tool invocation and raw result file. Early-access teams receive the benchmark scripts with the build so the same runs can be repeated on their hardware.
Not yet measured
Multi-node scaling, replication overhead, p99 under mixed load, and anything on a dedicated host. No number is published for these until it exists; see the roadmap.
Run your own tests when early access opens.
Hosted databases come with the benchmark scripts and the comparison baselines.