Benchmarks
go test -bench . -run XXX ./tests/ — from a development laptop (i7-9750H, SATA SSD, Go 1.26):
| Benchmark | Result | Notes |
|---|---|---|
| Columnar scan | ~19M samples/s | merged segment, single channel, mmap + block decode |
| Merge throughput | ~0.9M samples/s | 51k rows, 20 entities, delta→columnar fold |
| Durable ingest (group commit) | ~2K appends/s | 2ms window, 12 parallel writers — fsync-bound on laptop disk |
Reading the numbers:
- Scans are where the columnar layout pays: tens of millions of samples per second on one core.
- Durable ingest is bounded by the disk's fsync latency, by design — in strict mode every ack means "on disk". Two levers amortize it. Batch-append: a multi-row
INSERTis one fsync for the whole statement, so bulk loading hits ~100k rows/s on a single connection even on a modest cloud disk (vs a few hundred/s per row). Relaxed durability (ALTER DATABASE SET DURABILITY RELAXED) acks single-row writes from the buffer and fsyncs behind them, ~5× faster where strict is fsync-bound — see Durability. Concurrent writers (many connections, ILP streams) also share fsyncs via group commit; server-grade NVMe moves everything an order of magnitude. - Compression on friendly data: steady-cadence timestamps ≈ 1 byte/point, constant f64 ≈ 1 bit/point, low-cardinality state strings collapse to RLE runs (guaranteed by tests, not just observed).
The chaos suite (concurrent writers + racing merges + readers + repeated crash/reopen cycles) runs with -race in CI fashion: zero acked-row loss is an invariant, not a benchmark. An end-to-end death test goes further — bulk-load, a real kill -9 of the server, restart — and recovers every acked row (strict), confirming the guarantee on a live process, not just an in-memory reopen.