Scenarios

Pick a key/value engine by what your workload does most: read-heavy, write-ingest, mixed read-update, durable writes, ordered scans, smallest footprint, or a networked Redis-compatible server. 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, and says plainly what to avoid and why.

The first six pages are the embedded engines, and their throughput figures are operations per second on an Apple M4 laptop (10 cores, 24 GB), 1 KB values, 8 concurrent clients. The read and mixed pages use 100,000 keys held in cache; the ingest and footprint pages use 300,000 keys written out to disk, so each table names its own setup. The last page is a different class, the Redis-compatible servers reached over a socket, and it names its own machines and clients.

Scenario	The question	Top picks
Read-heavy	Mostly reading keys you already wrote	tamnd/kv, pogreb, buntdb
Write ingest	A firehose of new keys	tamnd/kv, badger, pebble
Mixed read-update	Reads and updates in roughly equal measure	tamnd/kv, pebble, badger
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
Redis-compatible	A networked RESP store, not an in-process library	kv-redis, valkey, redis

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 over 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. tamnd/kv leads by absorbing every write into an in-memory hot tier and spilling to disk in the background. Mixed read-update The typical service workload: reading and updating existing keys in roughly equal measure. tamnd/kv leads it, because the hot tier absorbs an update at write speed. 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. The LSM engines compress below raw size; tamnd/kv is compact too, and badger is the cautionary tale. Redis-compatible The RESP servers measured over a socket at everysec durability: redis, valkey, and kv's own Redis face. On an isolated Linux run redis and valkey lead the reads, kv-redis leads write ingest, and the client is pinned off the server so it cannot skew the numbers.