First results: storage engine vs RocksDB
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.
Run details
| Date | |
|---|---|
| Commit | afc6248 (table-bound run); 118c45a (memtable-bound run) |
| Host | sttiz, a shared production VPS with 8 vCPU and other services running. Not a dedicated host: none of these numbers may be compared with spec targets. |
| Tool | The project's own key-value benchmark (crate uf-bench) with a RocksDB oracle. One client thread, fsync on every write, 100-byte values, no compression in either engine, 20 000 operations per workload. |
| Raw results | docs/bench/results/2026-10-10-sttiz-indicative-table-bound.jsonldocs/bench/results/2026-10-10-sttiz-indicative-memtable-bound.jsonl |
| Report | docs/bench/2026-10-10-first-results.md |
Indicative only. Measured on a shared development host with other services running, one node, data that fits in memory. These figures show direction, not performance to expect. The claims policy requires a dedicated host before any target is published.
The tables, as written
Transcribed from the report without rounding. Bracketed values are the previous measurement where the report gives one.
Table-bound run: 300k records, 4 MB memtable, 8 MB block cache, 20k ops
| YCSB | UltraFabric ops/s | p50 / p99 / max | RocksDB ops/s | p50 / p99 / max |
|---|---|---|---|---|
| A (50% update) | 2,220 | 85 µs / 1.21 ms / 532 ms | 2,347 | 40 µs / 1.27 ms / 49 ms |
| B (5% update) | 19,274 | 1.8 µs / 905 µs / 2.3 ms | 24,655 | 3.9 µs / 803 µs / 3.0 ms |
| C (read only) | 93,245 | 1.0 µs / 56 µs / 0.6 ms | 258,102 | 3.2 µs / 7.7 µs / 0.5 ms |
| E (scans) | 17,937 | 5.5 µs / 832 µs / 2.6 ms | 19,332 | 9.0 µs / 885 µs / 2.8 ms |
| F (read-modify-write) | 2,179 | 82 µs / 1.25 ms / 493 ms | 2,447 | 33 µs / 1.13 ms / 46 ms |
Idle RSS after open: UltraFabric 9.9 MB, RocksDB 11.5 MB. End-of-run RSS: UltraFabric about 70 MB, RocksDB about 28 MB. Disk: UltraFabric about 70 MB, RocksDB about 39 MB.
Operations per second, log scale
Table-bound run, one client, fsync on every write
Before and during this run
- Block cache, two-level compaction, garbage collection of old versions with a durable horizon, and a memory governor were in place for the first time.
- The first run of the day (memtable-bound, commit 118c45a) showed YCSB-E at 44 ops/s because range scans collected every key after the start in each layer. A lazy k-way merge (commit a0ae43e) brought it to 17 937 ops/s in the table-bound run, within 10% of RocksDB.
What the numbers say
The report's own reading, including what went wrong and what is still open.
- Write-path stalls: maximum latency of about 0.5 s on A and F. Flush and compaction ran synchronously inside the write that crossed the memtable limit, and compaction merged all its inputs in memory. RocksDB does this on background threads.
- Point reads were 2.8× slower than RocksDB once data was on tables (C). Every cache miss decoded a whole block, and the cache stored decoded entries, so fewer blocks fit in 8 MB.
- Memory and disk were about 2× RocksDB's: compaction held its inputs in memory, the WAL's active segment was never truncated, and no GC horizon was set, so all versions were retained (also for the RocksDB oracle).
- Write throughput on A and F is fsync-bound on this disk for both engines and says little about the engines themselves.
- Before any target can be claimed: a dedicated, idle host (8 vCPU / 32 GB / local NVMe), datasets larger than the RAM caches, multiple clients and the full YCSB parameter set.
Files and tools
Report
docs/bench/2026-10-10-first-results.md in the repository.
Raw results
docs/bench/results/2026-10-10-sttiz-indicative-table-bound.jsonldocs/bench/results/2026-10-10-sttiz-indicative-memtable-bound.jsonl
Access
The repository is private during development. Early-access teams receive the build, the benchmark scripts and the raw files.
See the measurements in context.
The performance page draws the latest figure from each area and states what is not measured yet.