TurboKV: async Rust key-value store ships tunable durability and unusually candid benchmarks

TurboKV is a new embedded key-value database written in Rust, distributed as the turbokv crate (v0.6) and built to run on top of Tokio. It offers the feature set expected of a modern LSM-style store: atomic write batches, lexicographically ordered range and prefix scans with point-in-time snapshots, LZ4 compression, a configurable block cache and memtable, and background compaction. One notable low-level detail is that its persisted Bloom-filter format depends on hardware AES, so builds need explicit target-feature flags (+aes plus SSE2 or NEON) rather than working out of the box on every target.

The project’s headline pitch is speed, and it leans on a three-tier durability model to frame it: Fast skips the write-ahead log entirely, Durable writes a recoverable WAL record without fsyncing each acknowledgment, and Paranoid syncs before returning — which caps single-key throughput at storage-sync latency unless writes are amortized across a batch. Benchmarks pit TurboKV 0.6.0 against fjall 2.11.2 and redb 2.6.3 on an Apple M4, measuring acknowledged keys per second over 200,000 keys.

What stands out more than the numbers is the honesty of the methodology. The write-up openly flags that redb’s ‘Eventual’ mode performs a full macOS F_BARRIERFSYNC on every transaction while TurboKV and fjall stop at their weaker, process-crash-recoverable OS-cache boundaries — meaning the single-key rows are not a like-for-like durability comparison, and cross-engine settled timings aren’t compared at all. It also publishes raw repetitions, latency percentiles, dependency versions, and a rerun command. In a field where ‘insanely fast’ database claims are routinely gamed, that level of disclosed caveat is the more interesting signal for anyone evaluating the crate.