1 Billion keys with 500µs P99 latency. Here is why we completely stopped sorting data on disk.
Hey Product Hunt! 👋
If you’ve ever scaled a traditional Key-Value store (like RocksDB or LevelDB), you already know the pain of the "Compaction Death Spiral." You write a 1KB value, but your storage engine rewrites it 10 to 30 times in the background just to keep things sorted. Eventually, your disks choke, your CPU spikes, and your P99 latency goes completely off the charts.
We got tired of babysitting database tuning parameters. So we asked a crazy question: What if we build a KV store that simply never sorts values on disk?
Meet VeltrixDB—a storage engine purpose-built for the raw parallelism of modern NVMe drives. We just stress-tested it at 1 BILLION unique keys across 24 raw NVMe drives (80% reads / 20% writes).
The results fundamentally change what you should expect from your storage engine:
Write Amplification is ~1.0x: Every byte hits the NVMe exactly once. No compaction jitter.
Sub-millisecond Tail Latency: P99s stayed completely flat at ~500 µs at scale.
GC Emergencies: ZERO: We ran a 30-minute max-stress test, and background reclaim never blocked a single foreground read.
How we actually did it:
Decoupling: Keys live in an ultra-fast Radix Tree in DRAM. Values are appended to an NVMe Value Log and they never move sideways.
25x Block Packing: Standard NVMe writes require 4KB alignment, which wastes massive space for small values. We built a packer that squeezes 26 records into a single 4KB block before it hits the drive.
Zero-Syscall Reads: We implemented io_uring with SQPOLL. A kernel thread continuously polls our queue, meaning our app never calls io_uring_enter(). Zero syscalls = flat P99 latency.
If you are scaling write-heavy systems, managing massive caches, or just hate unpredictable latency spikes, we built this architecture for you.
Please visit: https://www.veltrixdb.com for more details.
Thank you
Replies