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:

​
Comparisons

FeatureBadgerRocksDBBoltDB
DesignLSM tree with value logLSM tree onlyB+ tree
High Read throughputYesNoYes
High Write throughputYesYesNo
Designed for SSDsYes (with latest research1)Not specifically2No
EmbeddableYesYesYes
Sorted KV accessYesYesYes
Pure Go (no Cgo)YesNoYes
TransactionsYesYesYes
ACID-compliantYes, concurrent with SSI3NoYes
SnapshotsYesYesYes
TTL supportYesYesNo
3D access (key-value-version)Yes4NoNo
1 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. 2 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. 3 SSI: Serializable Snapshot Isolation. For more details, see the blog post Concurrent ACID Transactions in Badger 4 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.