redb

redb is a simple, portable, high-performance, ACID-compliant embedded key-value store written entirely in Rust. It stores data in a collection of copy-on-write B+trees, giving it lmdb-style crash safety and MVCC concurrency: a single writer and multiple concurrent readers can operate on the database without blocking each other, and every transaction is serializable.

The public API mirrors BTreeMap closely — tables are opened from typed TableDefinition constants, and reads/writes go through a zero-copy access-guard pattern rather than deserializing into owned values by default. Because the crate has no runtime dependencies beyond alloc and (optionally) std, it embeds cleanly into CLIs, services, and — behind an experimental no_std feature — constrained embedded targets with atomic compare-and-swap support.

redb has been stable since its 1.0 release and the on-disk file format is explicitly documented and versioned, with a stated commitment to upgrade paths across format changes. Development is active and disciplined: strict clippy lints, cargo deny license/advisory auditing, fuzz targets for the B+tree and page store, and CI running the full test suite across Linux, macOS, Windows, and ARM.

What You Get

• A Database handle opened directly from a file path (or a custom StorageBackend), with typed TableDefinition/MultimapTableDefinition constants that give compile-time key/value typing
• Fully ACID write transactions and lock-free concurrent read transactions via MVCC, so readers never block a writer or each other
• Zero-copy access guards for reads, plus owned-value variants (get_owned, range_owned) when the result needs to outlive the transaction
• Savepoints and rollbacks for point-in-time recovery within a session, and crash-safety by default without extra configuration
• A documented, versioned on-disk file format (see docs/design.md) with an explicit upgrade-path commitment across format changes
• An experimental no_std build path (via the experimental-api-5 feature) for embedded targets with atomic compare-and-swap, using a pluggable StorageBackend

Common Use Cases

• Embedded local storage for CLI tools and desktop apps that need transactional persistence without shipping a database server
• A caching or indexing layer inside a larger Rust service where lmdb/sled-style embedded storage is preferred over an external KV store
• State storage for daemons and long-running services that require crash-safe writes and concurrent read access from multiple threads
• Backing store for higher-level data structures (queues, graphs, search indexes) that need ordered key iteration and range scans
• Storage for resource-constrained or embedded targets, via the experimental no_std build with a custom StorageBackend

Under The Hood

Architecture redb is organized around a Database (src/db.rs) that owns a TransactionalMemory/page store and hands out ReadTransaction/WriteTransaction objects (src/transactions.rs); each transaction opens typed Table/MultimapTable handles (src/table.rs, src/multimap_table.rs) backed by copy-on-write B+trees implemented in src/tree_store/ (btree.rs, btree_base.rs, btree_mutator.rs, btree_cursor.rs). The page store (src/tree_store/page_store/) manages page allocation via a buddy allocator and bitmap tracker, a region-based file layout with double-buffered commit slots for atomic commits, and an LRU page cache; a TransactionTracker (src/transaction_tracker.rs) coordinates MVCC visibility across concurrent readers and the single writer. Swapping the core B+tree or page-allocation strategy would ripple through nearly every module, since transactions, cursors, and the multimap layer all consume the tree_store’s page and checksum primitives directly.

Tech Stack The crate is pure Rust (99%+ of the codebase) targeting Rust 1.90 / edition 2024, with zero required runtime dependencies beyond alloc; std is an optional default feature, and log, chrono, and uuid are opt-in integrations for logging and typed values. Platform file locking is implemented via libc byte-range locks on Linux/Apple targets to support its multi-process locking protocol, with a WASI target also supported. The workspace additionally ships a benchmark crate (redb-bench) comparing against lmdb, rocksdb, fjall, and sqlite, a redb-derive proc-macro crate for deriving Value/Key impls, and a redb-python crate exposing bindings via maturin.

Code Quality The project enforces #![deny(clippy::all, clippy::pedantic, clippy::disallowed_methods)] at the crate root plus custom deny-lints for endian-unsafe byte handling, and CI runs with RUSTFLAGS=--deny warnings across Linux, macOS, Windows, and ARM runners. Testing is extensive: dedicated integration test files cover basic operations, cursors, multimaps, multithreading, crash consistency, backward compatibility against a pinned older redb version, and corrupted-btree-descent handling, alongside fuzz targets under fuzz/. cargo deny enforces license and advisory policy, and cargo fmt/clippy gate every change; the CI workflow also explicitly bans AI-authored commits, indicating a deliberate human-authorship policy for this project.

What Makes It Unique redb’s defining technical choice is being a from-scratch, pure-Rust reimplementation of the lmdb copy-on-write B+tree model rather than a wrapper around a C library or a LSM-tree design (unlike sled or rocksdb-backed alternatives) — this gives it a documented, versioned binary file format with an explicit backward-compatibility contract, zero-copy reads by default, and an experimental no_std mode for embedded targets that few comparable embedded KV stores offer. The published benchmark suite comparing directly against lmdb, rocksdb, fjall, and sqlite on the same workload is also unusually transparent for a library in this space.