BadgerDB

BadgerDB is an embedded, persistent key-value store written in pure Go by the Dgraph team. Designed in 2017 to address the problem that LevelDB- and RocksDB-cgo bindings were the only practical KV options for Go programs at the time, BadgerDB is a native Go LSM implementation with a key innovation: it stores values separately from keys (WiscKey design) when values are above a threshold, dramatically reducing write amplification.

Key Features:

• Pure Go. No CGO, no C library dependency — deploys as a single Go binary.
• WiscKey Value Separation. Keys + small values in the LSM-tree; large values in a separate value-log. Compaction touches only keys, slashing write amplification.
• Concurrent Writers. Unlike LevelDB’s single-writer model, BadgerDB supports concurrent transactional writes via SSI (serializable snapshot isolation).
• Transactions. First-class ACID transactions with snapshot isolation.
• Streaming Backups. Backup / Load APIs for hot-incremental backup.
• TTL. Per-key time-to-live with automatic expiry during compaction.
• Encryption at Rest. AES-128/256 encryption of SSTables and value logs.

BadgerDB vs. LevelDB / RocksDB:

• Language. BadgerDB — pure Go. LevelDB / RocksDB — C++ with bindings.
• Concurrent writes. BadgerDB — yes. LevelDB — no. RocksDB — via TransactionDB.
• Write amplification. BadgerDB — lower (WiscKey). RocksDB — tunable per workload.
• Ecosystem. RocksDB has wider production deployment; BadgerDB is the go-to for Go-native embedding.

Use Cases:

• Storage layer for Dgraph — the canonical user.
• Go applications wanting an embedded KV without CGO build complexity.
• Single-binary services that ship persistence inside the executable.
• Workloads with large values (> 1 KiB) where WiscKey’s value separation pays off.