# redb: a pure-Rust embedded key-value store with copy-on-write B+trees

> redb is an ACID embedded key-value database written entirely in Rust, aimed at applications that want a BTreeMap-like API persisted to a single file. The API is small and the file format is declared stable, but the benchmarks in the README put it behind LMDB on reads and behind RocksDB and fjall on space.

**cberner/redb** — An embedded key-value database in pure Rust

- Repository: https://github.com/cberner/redb
- Website: https://www.redb.org
- Stars: 4,816 · Forks: 244
- Language: Rust
- License: Apache-2.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/cberner-redb

## What redb replaces in a Rust application

redb targets the case where an application needs durable, transactional storage but should not ship a separate database process. The README describes it as "a simple, portable, high-performance, ACID, embedded key-value store" written in pure Rust and loosely inspired by lmdb. Because it is pure Rust, there is no C toolchain in the build path and no FFI boundary at runtime, which matters when you cross-compile or target unusual platforms. The unit of storage is a table, declared as a typed constant, and the read path returns a value that can be read without copying out of the database. If your data model is a sorted map from a key type to a value type, and you want that map to survive process restarts inside a single file, redb is aimed at you. If you want SQL, joins, or a query planner, it is not.

## Copy-on-write B+trees and the MVCC read path

The design doc referenced from the README is the authoritative description, and the README's own summary is that data is stored in a collection of copy-on-write B+trees. The practical consequence is that a committed write never mutates pages a reader may still be traversing, so readers and the single writer do not block each other. The README lists MVCC support for concurrent readers and one writer, fully ACID transactions, crash safety by default, and savepoints and rollbacks. The transaction shape is explicit: begin_write, open a table inside that write transaction, insert, commit. Reads go through begin_read and open_table on the read transaction. The API is thread-safe according to the feature list, and the repository ships examples/multithread.rs alongside int_keys.rs and special_values.rs, so the intended usage patterns are demonstrated in-tree rather than only in prose. Two things the README does not spell out are how savepoints interact with long-running read transactions and what the rollback granularity is; you would need the API documentation for that.

## Installing redb and writing a first table

The crate is published as redb on crates.io, so the dependency line is the normal Cargo entry. Add it to Cargo.toml:

```toml
[dependencies]
redb = "4.3.0"
```

Then the README's own example is the shortest complete program. It creates a database file, writes one key inside a write transaction, commits, and reads the value back through a separate read transaction:

```rust
use redb::{Database, Error, ReadableDatabase, TableDefinition};

const TABLE: TableDefinition<&str, u64> = TableDefinition::new("my_data");

fn main() -> Result<(), Error> {
    let db = Database::create("my_db.redb")?;
    let write_txn = db.begin_write()?;
    {
        let mut table = write_txn.open_table(TABLE)?;
        table.insert("my_key", &123)?;
    }
    write_txn.commit()?;

    let read_txn = db.begin_read()?;
    let table = read_txn.open_table(TABLE)?;
    assert_eq!(table.get("my_key")?.unwrap().value(), 123);

    Ok(())
}
```

After running it, my_db.redb exists in the working directory and the assertion passes. Note the scoping: the table handle is dropped before commit is called, which is the pattern the example uses to end the borrow of the write transaction. For integer keys, examples/int_keys.rs in the repository shows the same flow with a numeric key type.

## Where redb loses: reads, disk size and removals

The README publishes a benchmark table against lmdb, rocksdb, fjall and sqlite, collected on a Ryzen 9950X3D with a Samsung 9100 PRO NVMe, with source at crates/redb-bench/benches/lmdb_benchmark.rs. Read it honestly. LMDB is faster on every random read row, including the multi-threaded ones, where the gap widens: at 32 threads the table shows 410ms for redb against 125ms for lmdb. Bulk load is also slower than lmdb (17063ms against 9232ms). On disk, redb's uncompacted size is 4.00 GiB against 893.18 MiB for rocksdb and 2.61 GiB for lmdb, and the compacted figure is 1.69 GiB against 454.71 MiB for rocksdb. Removals are the worst row for redb at 23297ms, roughly double lmdb and nearly four times fjall. The rows redb wins are individual writes (920ms), batch writes relative to sqlite, and len(), which the table shows at 0ms. So the honest summary is that redb's advantage is write latency and a cheap length query, not read throughput or space efficiency. A read-heavy, latency-sensitive service is the wrong fit.

## no_std, storage backends and what you give up

Turning off the std feature, with experimental-api-5 enabled, builds redb without the standard library. The README is specific about the cost: alloc is still required, panic = "abort" is required, and the target needs atomic compare-and-swap, which means Cortex-M3 and above but not Cortex-M0. There is no filesystem in that configuration, so you supply storage by implementing StorageBackend and passing it to Builder::create_with_backend(). Three features become unavailable: cache_metrics, chrono_v0_4 and uuid. Note also that the std feature is described as a no-op unless experimental-api-5 is on, so a dependent who sets default-features = false without that feature gets the standard library anyway. That is a subtle trap worth reading twice before you design around it.

## redb against LMDB and RocksDB in practice

LMDB is the closest comparison because redb is loosely inspired by it, and the difference is in the implementation rather than the model. LMDB is C with a memory-mapped design and a fixed maximum map size you configure up front; redb is pure Rust with copy-on-write B+trees and a Rust type system carrying the key and value types through TableDefinition. The benchmark table shows LMDB ahead on reads and bulk load, so choosing redb over LMDB is a bet on the build and deployment story (no C dependency, no mmap sizing) rather than on raw read speed. RocksDB is the other direction entirely: a larger, LSM-tree-based engine that wins the batch write and space rows in the same table but costs a much heavier dependency, and the README's own numbers show RocksDB ahead on batch writes (451ms against 1595ms) and far ahead on compacted size. If you need a log-structured store with compaction tuning, RocksDB is the established answer. redb's pitch is a smaller API surface and a stable file format, not outrunning either.

## File format stability, release cadence and licence terms

The README states that the file format is stable and that a reasonable effort will be made to provide an upgrade path if there are any future changes to it. That is a commitment about the on-disk format, not about the Rust API, and the two should not be confused when you plan upgrades. The Cargo.toml pins edition 2024 and rust-version 1.90, so the toolchain floor is explicit and worth checking against your CI images. Version 4.3.0 is the current release listed, with 4.2.0 and 4.1.0 before it, and the repository's last push was on 2026-09-22, so the project is not archived and the codebase is being touched. Development uses just and rootless podman, with cargo build artifacts cached in the redb-sandbox-target Podman volume; removing that volume forces a clean sandbox build. Licensing is dual: Apache-2.0 or MIT, at your option, and the README notes that contributions are dual licensed under the same terms unless stated otherwise. The repository also carries a dev-dependency pinned at redb 2.6.0 for backwards-compatibility testing, which tells you the project tests against an older on-disk format rather than assuming forward-only users. Check your own obligations against the full licence texts; nothing here is legal advice.

## Conclusion

Adopt redb if you want an embedded store with no C dependency, a BTreeMap-shaped API, MVCC readers that do not block the writer, and a file format the project states is stable. Do not adopt it if your workload is read-heavy and latency-bound, if disk footprint matters more than API ergonomics, or if you need a query language, secondary indexes or a server protocol, none of which redb provides. Before committing, reproduce the README benchmark numbers for your own read/write mix against LMDB on your storage, and confirm that the crates.io release you pin matches the 4.3.0 source you reviewed.

## FAQ

### What is redb?

redb is an ACID embedded key-value store written in pure Rust, loosely inspired by LMDB. It keeps data in a collection of copy-on-write B+trees and exposes a BTreeMap-shaped, zero-copy, thread-safe API.

### How do I install redb in a Rust project?

Add it as a Cargo dependency on the redb crate, for example redb = "4.3.0" in Cargo.toml, then use Database::create to open a file and begin_write to start a transaction. The README's example is the shortest working program.

### Does redb work without the Rust standard library?

Yes, if you turn off the std feature with experimental-api-5 enabled. The README states that alloc and panic = "abort" are still required, the target needs atomic compare-and-swap (Cortex-M3 and above, not Cortex-M0), and storage must be supplied by implementing StorageBackend and passing it to Builder::create_with_backend().

### How does redb compare with LMDB?

redb is loosely inspired by LMDB but is pure Rust, so it avoids a C dependency in the build. The README's benchmark table shows LMDB faster on bulk load and on every random read row, including the multi-threaded ones, so redb's case rests on portability and API rather than read throughput.

## Sources

- [cberner/redb on GitHub](https://github.com/cberner/redb)
- [License: Apache-2.0](https://github.com/cberner/redb/blob/master/LICENSE)
- [Project website](https://www.redb.org)
- [README](https://github.com/cberner/redb/blob/master/README.md)
- [Releases](https://github.com/cberner/redb/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cberner-redb