# Source: https://docs.hypermode.com/badger/design.md

# Design

> Architected for fast key-value storage in Go

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](https://www.usenix.org/system/files/conference/fast16/fast16-papers-lu.pdf).

## 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](https://hypermode.com/blog/badger/)
* [Make Badger crash resilient with ALICE](https://hypermode.com/blog/alice/)
* [Badger vs LMDB vs BoltDB: Benchmarking key-value databases in Go](https://hypermode.com/blog/badger-lmdb-boltdb/)
* [Concurrent ACID Transactions in Badger](https://hypermode.com/blog/badger-txn/)

## 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 research<sup>1</sup>) | Not specifically<sup>2</sup> | 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 SSI<sup>3</sup>   | No                           | Yes     |
| Snapshots                     | Yes                                    | Yes                          | Yes     |
| TTL support                   | Yes                                    | Yes                          | No      |
| 3D access (key-value-version) | Yes<sup>4</sup>                        | No                           | No      |

<sup>1</sup> 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.

<sup>2</sup> 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.

<sup>3</sup> SSI: Serializable Snapshot Isolation. For more details, see the
blog post [Concurrent ACID Transactions in
Badger](https://hypermode.com/blog/badger-txn/)

<sup>4</sup> 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](https://github.com/dgraph-io/badger-bench) repo.