Scenarios

Pick a key/value engine by what your workload does most: read-heavy, write-ingest, mixed read-update, durable writes, ordered scans, or smallest footprint. Each scenario has real numbers.

The fastest way to pick an engine is to name what your workload does most, then read the one scenario that matches. Each page below states the question, names the winners with real numbers from four machines, and says plainly what to avoid and why.

All throughput figures are operations per second. Unless a table says otherwise, the headline number is an Apple M4 laptop (10 cores, 24 GB), 100,000 keys of 1 KB each, 8 concurrent clients. Where an engine scales differently on a server, the page shows the cross-machine numbers too.

Scenario	The question	Top picks
Read-heavy	Mostly reading keys you already wrote	tamnd/kv, pogreb, buntdb
Write ingest	A firehose of new keys	pebble, badger, buntdb
Mixed read-update	Reads and updates in roughly equal measure	buntdb, badger, pebble
Durable writes	Every write must survive a crash	badger, sqlite
Range scans	Walking keys in sorted order	bbolt, pebble, goleveldb
Smallest footprint	Least disk per byte stored	goleveldb, pebble

If you are not sure which one you are, you are probably mixed read-update: most real services read and write in roughly equal measure. Start there.

Read-heavy Caches, lookup tables, and read-mostly indexes. tamnd/kv reads at 6.8 million keys per second, ahead of every other embedded Go engine measured. Write ingest Event logs, metrics, and bulk loads that write new keys fast. LSM engines like pebble and badger absorb writes without rewriting a tree. Mixed read-update The typical service workload: reading and updating existing keys in roughly equal measure. buntdb, badger, and pebble keep updates cheap as the data churns. Durable writes When a write must survive a power cut, the engine flushes the disk on every commit. badger and sqlite win by batching many commits into one flush. Range scans When you need to iterate keys in order (prefix scans, range queries, ordered exports), you need an engine that keeps keys sorted. bbolt, pebble, and goleveldb do. Smallest footprint When storage cost is the constraint, space amplification is the number that matters. LSM engines compress 1 KB values below their raw size; one engine here uses 22x.