arXiv: 2607.02401 · PDF: pdf · Published: 2026-07-02
TL;DR
NVM key-value stores have gotten fast at ingest and point lookup, but they’ve skipped the interface guarantees a real database engine needs: point-in-time snapshots, consistent iterators, and atomic batches. FlintKV is an NVM-optimized, skiplist-based engine that natively supports all three under durable linearizability, using a novel flat-combining multi-version concurrency control algorithm co-designed with its persistence path. Standalone it beats prior work by up to 75% in end-to-end throughput; its durable skiplist can also be dropped into existing NVM stores as a component upgrade.
Why it matters
The gap the paper flags is a real one. Production engines like RocksDB assume the storage layer offers atomic batches (for transactions), snapshot-consistent iterators (for MVCC), and durable point-in-time reads (for backups and CDC). Prior NVM KV research has consistently benchmarked bare put/get throughput and left the harder interface work as future-work. That’s why NVM stores haven’t displaced LSM engines in production despite years of impressive microbenchmarks.
FlintKV closes that gap without collapsing throughput. Flat combining — a batching technique that lets one thread execute a small buffer of operations on behalf of many — pairs well with NVM’s asymmetric write costs: fewer distinct persistence events, better cache locality on the shared skiplist, and a natural place to hang MVCC version chains.
Where it fits
Two useful mental models for FlintKV:
- A drop-in NVM backend for RocksDB-shaped systems — atomic batches + snapshots + iterators are the API contract most storage engines already speak.
- A component library — the durable skiplist can be lifted out and slotted into an existing NVM KV store to add snapshot/iterator support without a full rewrite.
Authors
See the arXiv listing for the full author roster.