// the find
cberner/redb
An embedded key-value database in pure Rust
redb is a pure-Rust embedded key-value store using copy-on-write B+trees, API-compatible in spirit with lmdb but with a typed, zero-copy BTreeMap-style interface. It's for Rust developers who want an embedded ACID store without linking against a C library, and who need MVCC concurrent reads alongside a single writer.
No FFI or C toolchain dependency, unlike lmdb-rs or rocksdb bindings, which means no libclang/cmake headaches in the build. MVCC gives you non-blocking concurrent readers while a write transaction is open, and the table API is generic and zero-copy rather than raw byte slices. The file format is explicitly declared stable with a commitment to upgrade paths, and there's a backward_compatibility test suite in tests/ backing that claim up. The published benchmarks are refreshingly honest — they show lmdb and rocksdb beating redb on several axes instead of only picking favorable numbers.
Read throughput falls behind lmdb by 2-3x as concurrency increases (652ms vs 216ms at 16 threads, widening to 410ms vs 125ms at 32), so it's not the pick if read-heavy multi-threaded access is your bottleneck. Compacted database size is roughly 3-4x larger than rocksdb for the same data (1.69 GiB vs 454 MiB), and the README doesn't say whether compaction is automatic or something you have to trigger yourself. no_std support is gated behind an experimental feature flag and pushes StorageBackend implementation onto you, so it's not a real option yet for constrained embedded targets. The dev setup requires just and rootless podman for a sandboxed build, which is an unusual bar for a library this size and will slow down first-time contributors.