Faster point reads, a higher tail.
The storage engine is measured against RocksDB in the same harness, on the same host, in the same run. UltraFabric reads more keys per second; RocksDB keeps the lower p99 and the smaller write-heavy footprint. All of it on a shared development host.
The tables from the report
Source: the first-results report in the repository, re-run sections of 19 October 2026. Host: shared development host, 3 CPUs / 6 GB; indicative, not a production promise. One client thread, fsync on every write, 100-byte values, no compression in either engine, 300 000 records, 4 MB memtable, 8 MB block cache.
Reads and scans, commit de1c61b
Operations per second and tail latency, same run for both engines (CRC-32C slicing-by-8 change)
| Workload | UltraFabric ops/s | Latency | RocksDB ops/s | Latency |
|---|---|---|---|---|
| C: point reads | 412,447 | p99 11.5 µs | 274,508 | p99 7.6 µs |
| E: short scans | 22,655 | p50 6.6 µs | 21,927 | — |
All workloads, commit 2f98517
After incremental compaction; the "max" column is the worst single operation in the run
| YCSB | UltraFabric ops/s | max | RocksDB ops/s | max |
|---|---|---|---|---|
| A: 50% updates | 2,622 | 22.6 ms | 2,709 | 18.2 ms |
| B: 5% updates | 28,245 | 3.0 ms | 24,542 | 1.4 ms |
| C: read only | 429,100 | 0.1 ms | 274,764 | 0.1 ms |
| E: short scans | 21,049 | 1.4 ms | 21,508 | 3.2 ms |
| F: read-modify-write | 2,680 | 25.9 ms | 2,696 | 18.8 ms |
Caveats from the report: single client; the dataset (about 35 MB) fits the OS page cache; shared host, so tail noise is large. Write throughput on A and F is bound by the disk's sync time for both engines. Nothing here is a production promise.
How it got here. On 10 October UltraFabric read 93 245 keys per second, 2.8× slower than RocksDB, and stalled for half a second on writes. Restart points inside blocks, a raw-block cache, streaming compaction, a faster checksum and incremental compaction followed, each with its own dated row in the report. The row storage page describes the engine as it stands.
Where RocksDB is ahead
A comparison that hides the other side's strengths is advertising. These are the points a buyer would find anyway.
Lower p99 on point reads
7.6 µs against UltraFabric's 11.5 µs in the run that set the throughput figure. Throughput is higher on UltraFabric; the tail is lower on RocksDB.
Smaller write-heavy footprint
RocksDB's resident memory on write-heavy runs is 26 MB against UltraFabric's 32 MB, after UltraFabric stopped buffering whole output tables.
Worst-case write latency
After incremental compaction UltraFabric's worst write is within about 25% of RocksDB's (22.6 vs 18.2 ms on workload A). Before it, UltraFabric stalled for 371 ms.
Years of production use
RocksDB is a mature library with background compaction threads, tuning knobs and a large installed base. UltraFabric's engine is weeks old and has not had its long soak test or a run on dedicated hardware.
What RocksDB does not offer
Built and tested today, not planned.
Transactions with snapshot isolation
First committer wins, idempotent writes with client keys, and a durable garbage-collection horizon, on top of the key-value layer.
BuiltTenant as a key range, checked per plan
Every query is verified to stay inside the requester's tenant and access policy before it runs. RocksDB is a key-value library; isolation is the caller's problem.
BuiltRow and columnar under one verifier
Columnar collections for analytic data and row collections for records share the same schema, SQL and check.
BuiltSQL over the PostgreSQL protocol
psql and drivers connect to a gateway with a token; the same engine answers both key lookups and TPC-H queries.
BuiltStatus today
No RocksDB API
UltraFabric does not expose a RocksDB-compatible interface and is not a drop-in replacement for an embedded key-value store. Inside the project, storage is reached through one trait with three implementations: UltraFabric's engine, a RocksDB binding used as the differential oracle and documented fallback, and an in-memory reference model. Every storage test runs against all three. The harness that produced the tables above (kvbench) drives both engines with the same workload and reports both in one result file.
Is RocksDB a competitor or a component?
Both, in a sense: RocksDB is the differential oracle every storage test runs against, and it is the documented fallback engine behind the same trait if UltraFabric's own engine cannot meet its gate. The numbers compare the two engines in the same harness.
Why are the write-heavy numbers so close?
With fsync on every write, both engines are bound by the disk's sync time on this host. The report says those rows say little about the engines themselves.
Can I use UltraFabric as a RocksDB replacement in my process?
No. There is no RocksDB-compatible API. UltraFabric's engine is reached through its own node over a Unix socket and through the PostgreSQL protocol via the gateway.
Run the same benchmark yourself.
Every report names its commit, tool invocation and raw result file. Early-access teams receive the scripts with the build.