// the find
spacejam/sled
the champagne of beta embedded databases
sled is a pure-Rust embedded key-value store built on a lock-free B+ tree over a log-structured pagecache. It targets long-running, highly-concurrent processes that need something between SQLite (too conservative) and RocksDB (too much ops overhead). The API is deliberately close to std's BTreeMap, which makes the learning curve short.
Lock-free all the way down — tree, pagecache, and log are all implemented without traditional mutexes, which means it actually scales on multi-core hardware instead of bottlenecking at a global lock. The crash testing suite is serious: dedicated fuzz targets, fail-point tests, and separate crash_* test binaries that kill the process mid-write and verify recovery. Prefix encoding and suffix truncation on B-tree nodes means sequential or shared-prefix keys are stored very efficiently without you doing anything. The watch_prefix API for subscribing to key-range changes is a genuinely useful primitive that most embedded KV stores don't offer.
Still beta after years of development, and the README itself warns that the on-disk format will change before 1.0 — meaning any production adoption needs a migration plan baked in from day one. Space amplification is bad enough that the maintainer explicitly recommends RocksDB if storage cost matters; the komora rewrite meant to fix this is still in progress and not merged. Only one process can open a sled database at a time, which rules out a wide class of deployment patterns (sidecars, multiple services sharing state, CLI tools running alongside a daemon). The README is explicitly out of sync with the main branch because of the ongoing rewrite, so you're flying partially blind on what the current API actually guarantees.