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

¹ 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.