Performance
Benchmarked in the open
32 benchmark suites run against the real server over the wire. Every number on this page is extracted from result files committed to the repository and regenerated by script, trade-offs included.
Performance
Numbers from committed benchmarks, not a lab
Two views of the same engine, what a client gets from a running server over the wire, and the raw subsystem numbers underneath it.
OLTP throughput by concurrent clients
Thousand transactions per second over the wire, higher is better.
concurrent clients
View the numbers
| Clients | Throughput | p99 latency |
|---|---|---|
| 1 | 12K tps | 263 µs |
| 4 | 33.4K tps | 360 µs |
| 16 | 65.1K tps | 493 µs |
| 64 | 60.5K tps | 1.8 ms |
| 256 | 55.2K tps | 8.5 ms |
1.8Btuples/s
MVCC GC sweep
3.0GB/s
.zyr scan throughput
3.4Mrows/s
Compaction pipeline
5µs
QUIC Postgres handshake
80.7µs
Durable commit floor
199µs
Lake point probe via index
310Mrows/s
Picosecond timestamp decode
703Ktxn/s
Durable group commit peak
The trade-offs are published too. Bulk load, trickle load, and indexed point lookups are cases where the row heap beats the lake, and they are in the same tables. See benchmarks/ for the raw result files.
Tail latency under load
p99 stays under half a millisecond through 16 concurrent clients, then grows as saturation sets in. The full curve is published, not just the flattering part.
OLTP p99 latency by concurrent clients
Milliseconds over the wire, lower is better.
concurrent clients
View the numbers
| Clients | p99 latency |
|---|---|
| 1 | 263 µs |
| 4 | 360 µs |
| 16 | 493 µs |
| 64 | 1.8 ms |
| 256 | 8.5 ms |
Durability is not the bottleneck
Every one of those transactions was durably committed, the WAL is fsynced through group commit before the client sees an acknowledgement. Group commit amortizes the device write across concurrent transactions instead of skipping it.
~703Ktxn/s
Durable group commit peak
~80.7µs
Durable commit floor, device write
~70.9x
Group commit amplification, c=1 to c=512
The durability model is covered on the database page.
End to end, cold start to shutdown
What a client actually experiences against a running server, not a microbenchmark.
40 ms
Cold boot to accepting queries
0.60 ms
First ReadyForQuery
7.2 ms
Schema DDL bootstrap
251K rows/sec
Seed insert
1.30 ms
Analytical query, median
53 ms
Graceful shutdown
Row heap vs ZyronLake, honestly
Same workload, same rows, both formats. The heap wins write-heavy and indexed-point cases, the lake wins scan and I/O cases. Both sides are published.
| Metric | Result | Favors |
|---|---|---|
| Point-lookup bytes read | 89x less I/O for the lake | ZyronLake |
| Point lookup with a heap B+ tree index | 2.0x faster on the heap | Row heap |
| Bulk load to queryable | 10.8x faster on the heap | Row heap |
| Trickle load to queryable | 32.1x faster on the heap | Row heap |
| Zone-map row rejection | ~100% of irrelevant rows skipped | ZyronLake |
Engine internals, the full table
Raw subsystem throughput and hot-path latency under microbenchmark, straight from the committed result files.
| Subsystem | Metric | Result |
|---|---|---|
| MVCC | GC sweep | ~1.8B tuples/sec |
| Columnar | .zyr scan throughput | ~3.0 GB/sec |
| Columnar | Compaction pipeline | ~3.4M rows/sec |
| Columnar | HybridScan overhead vs heap-only | ~-2.5% |
| Columnar | Metadata-aggregate pruning speedup | ~3.1x |
| Temporal | Picosecond timestamp decode | ~310M rows/sec |
| Versioning | Time-travel scan overhead | ~20% |
| Wire | QUIC connection handshake | ~5 µs |
| Transactions | Durable commit floor, device write | ~80.7 µs |
| Transactions | Durable group-commit peak | ~703K txn/sec |
| Transactions | Group-commit amplification, c=1 to c=512 | ~70.9x |
| Lake | Scan throughput | ~154M rows/sec |
| Lake | Point probe through index | ~199 µs |
| Lake | Zone-map row rejection | ~100% |
Methodology
All figures come from a release build on a single machine, an Intel Core Ultra 7 270K Plus with 24 cores and 31.4 GB RAM on windows/x86_64. End-to-end suites talk to the real server over the wire, internals suites microbenchmark one subsystem at a time.
The 32 suites cover storage, executor, optimizer, encoding, wire, search, analytics, CDC, versioning, transactions, temporal, columnar, lake, cross-format, types, lifecycle, gateway, Zyron-to-Zyron, and end-to-end. Each run writes a timestamped JSON and TXT pair under benchmarks/, and the tables and charts in the README are regenerated from those files by script. Nothing on this page is hand-entered.
Anyone can rerun them. The suites are cargo tests, so reproducing a number takes one command.
Reproduce a suite
# Run one suite, results land in benchmarks/<suite>/
cargo test -p zyron-search --test search_bench --release -- --nocapture
# Regenerate the README charts from the latest result files
python scripts/gen_bench_charts.pyRunning in the next five minutes
Prebuilt binaries for Linux and Windows, no external dependencies, one command to a running server.