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.
Hi makers! I ve been obsessed with storage performance lately. We keep buying 7GB/s NVMe drives, but most databases still use architecture (like LSM-trees) designed for a time when disks were the bottleneck.
Background compactions, write-amplification spikes, and P99 latency jitters seem to be the "tax" we pay for general-purpose storage. Is it time we move toward memory-first, zero-compaction engines, even if it means trading off some RAM? Or is the LSM-tree still the king of the hill? Would love to hear from anyone fighting database latency at scale!
VeltrixDB: High-Performance KV Storage
We built VeltrixDB for bare-metal NVMe. By ditching LSM-trees for an In-memory Adaptive Radix Tree (ART) and append-only Value Log, we’ve eliminated compaction spikes.
Stack: Linux io_uring + Direct I/O.
Performance: Flat, microsecond latencies at billion-key scale.
Trade-off: Optimized for pure IOPS & lock-free point reads (No range queries).
Perfect for HFT, AdTech & extreme caching.
Benchmarks: https://github.com/VeltrixDB/vel...
