badger

Design

We wrote Badger with these design goals in mind:

• Write a key-value database in pure Go
• Use latest research to build the fastest KV database for data sets spanning terabytes
• Optimize for modern storage devices

Badger’s design is based on a paper titled WiscKey: Separating Keys from Values in SSD-conscious Storage.

References

The following blog posts are a great starting point for learning more about Badger and the underlying design principles:

• Introducing Badger: A fast key-value store written natively in Go
• Make Badger crash resilient with ALICE
• Badger vs LMDB vs BoltDB: Benchmarking key-value databases in Go
• Concurrent ACID Transactions in Badger

Comparisons

Feature	Badger	RocksDB	BoltDB
Design	LSM tree with value log	LSM tree only	B+ tree
High Read throughput	Yes	No	Yes
High Write throughput	Yes	Yes	No
Designed for SSDs	Yes (with latest research1)	Not specifically2	No
Embeddable	Yes	Yes	Yes
Sorted KV access	Yes	Yes	Yes
Pure Go (no Cgo)	Yes	No	Yes
Transactions	Yes	Yes	Yes
ACID-compliant	Yes, concurrent with SSI3	No	Yes
Snapshots	Yes	Yes	Yes
TTL support	Yes	Yes	No
3D access (key-value-version)	Yes4	No	No

¹ The WiscKey paper (on which Badger is based) saw big wins with separating values from keys, significantly reducing the write amplification compared to a typical LSM tree.

² RocksDB is an SSD-optimized version of LevelDB, which was designed specifically for rotating disks. As such RocksDB’s design isn’t aimed at SSDs.

³ SSI: Serializable Snapshot Isolation. For more details, see the blog post Concurrent ACID Transactions in Badger

⁴ Badger provides direct access to value versions via its Iterator API. Users can also specify how many versions to keep per key via Options.

Benchmarks

We’ve run comprehensive benchmarks against RocksDB, BoltDB, and LMDB. The benchmarking code with detailed logs are in the badger-bench repo.

This site is open source. Improve this page.