Launched this week
VeltrixDB
Zero-compaction, memory-first NVMe key-value storage engine
3 followers
Zero-compaction, memory-first NVMe key-value storage engine
3 followers
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/veltrixdb-benchmark
Hi Product Hunt! I’m Shubham, Co-founder of VeltrixDB.
The Problem: Managing huge key-value stores at scale is frustrating. You provision expensive, blazing-fast NVMe drives, but legacy LSM-tree databases (like RocksDB or Pebble) choke your hardware with heavy background compactions and massive write amplification. Write-stalls and latency spikes become inevitable.
The Solution: We wanted a storage engine that stops fighting the hardware. So, we threw out the LSM-tree entirely. VeltrixDB uses an in-memory Adaptive Radix Tree (ART) index paired with an append-only disk log. By utilising io_uring and O_DIRECT, we write straight to the NVMe at its physical limits—achieving zero background sorting, zero compaction stutter, and a strict ~1.0x write amplification.
The Trade-offs: I want to be brutally honest with developers—this isn't a drop-in SQL replacement.
It is memory-bound: The entire index lives in RAM (~80 bytes/key).
No range queries: It is built strictly for high-speed point lookups.
Bare-metal only: It bypasses OS caches, meaning it will crawl on standard cloud EBS volumes.
It is a hyper-specialised scalpel built for AdTech (RTB), High-Frequency Trading, and extreme session caching where microsecond point-lookup speed is everything.
For the tech-savvy folks, we've open-sourced our benchmarks here: https://github.com/VeltrixDB/veltrixdb-benchmark
I’d love to answer any deep architectural questions or hear about the database scaling bottlenecks you are currently dealing with! Fire away in the comments.