bbolt

bbolt is an embedded, pure-Go B+tree key-value store, originally written by Ben Johnson as BoltDB and now maintained by the etcd team as bbolt. It is to Go what LMDB is to C: a single-writer, mmap-based, B+tree key-value store with strict ACID semantics and remarkable simplicity. bbolt is the storage engine inside etcd, Consul, InfluxDB’s metadata, Open Policy Agent, and many other Go infrastructure tools.

Key Features:

• B+tree on a single file. The whole database is one mmap-backed file; no compaction, no SSTables, no background threads.
• Single-Writer ACID. One writer transaction at a time (serializable); concurrent readers are wait-free.
• Buckets. Hierarchical namespaces inside the file — nested key-value collections.
• Pure Go, No CGO. Builds and deploys as part of any Go binary.
• Crash-Safe. Copy-on-write pages and a meta-page double-buffer guarantee atomic commits even on power loss.
• Tiny Footprint. ~3,000 lines of Go; the whole API surface fits in your head.

bbolt vs. BadgerDB:

• bbolt. B+tree, single-writer, simpler, lower write throughput. Best for control-plane / metadata workloads.
• BadgerDB. LSM, concurrent writers, higher write throughput. Better for application data.

bbolt vs. LMDB:

• Conceptually nearly identical — both are mmap-backed B+tree single-writer KV stores.
• LMDB in C, used outside Go ecosystems; bbolt in Go, used inside Go ecosystems.

Use Cases:

• etcd uses bbolt as the underlying storage for the Raft state machine.
• Consul, InfluxDB metadata, OPA, Tendermint, NATS Jetstream — bbolt is the de-facto Go embedded KV for control-plane data.
• CLI tools that need a small persistent store (e.g. credentials, history, indexes).
• Workloads where strict serializable transactions matter more than write throughput.