Badger VS BoltDB: Persistent key-value store written in Go
Hendra Huang 黃漢忠

This benchmark is unfair for BoltDB.

  1. BoltDB supports ACID while Badger does not, which means you will lost the data written to Badger if the machine powers off immediately after the write.
  2. BoltDB is just a thin wrapper around B+ tree but Badger has a write-head log before LSM, so you are comparing the write performance between a B+ tree and a write-ahead log, which means the data written to BoltDB is immediate available for lookup again while the data written to Badger is still in the log. (In an extreme case, anyone can make a “DB” that stores in memory the []byte written but do nothing else, and the performance will be only limited by the client, but it does not make any sense at all)
  3. BoltDB is a traditional on-disk DB while Badger stores all the keys in memory, which means you cannot store keys more than your memory can store. In this sense, BoltDB is more costly efficient.
  4. The throughput of B+ tree should be compared with batch in mind, please try use a batch size of 1000 you will see a different result. I have benchmarked MongoDB (also implemented with write-ahead log and LSM) and BoltDB with bulk/batch size of 1000 and the write throughput of BoltDB is 80% of the throughput of MongoDB. BoltDB is not that bad.

Anyway, It is still a good thing to have a competitive LSM implementation of Go.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.