Key-Value Databases

A key-value store is the simplest database model: you put(key, value) and get(key), and the database treats the value as an opaque blob or a small data structure. Because every operation names exactly one key, the store can hash the key to find the right machine and answer in well under a millisecond. Caches, user sessions, feature flags, rate limiters and shopping carts are classic uses.

How it works

  • Lookup by key only. There is no “find all users in Tehran” unless you build that index yourself. Design keys around how you read: session:8f3a, cart:u-42, rate:ip:10.0.0.7:2026-11-16T09:30.
  • Partitioning by hash. In a cluster, hash(key) decides which node owns the key. Redis Cluster uses 16,384 hash slots; DynamoDB hashes the partition key. Adding nodes moves only some keys. See Sharding.
  • In memory or on disk. Redis and Valkey keep everything in RAM (with optional snapshots and an append-only file for durability). DynamoDB, RocksDB and FoundationDB store data on SSD and are fully durable.
  • Expiry. A TTL deletes a key automatically after a time, which is what makes key-value stores natural caches.
Store Storage Notes
Redis In memory Rich value types: strings, hashes, lists, sets, sorted sets, streams. Licensing changed in 2024 (RSAL/SSPL); Redis 8 (2025) added AGPLv3 as an open-source option.
Valkey In memory BSD-licensed fork of Redis 7.2 under the Linux Foundation, created in 2024. Drop-in compatible; used by AWS ElastiCache and Google Memorystore.
Amazon DynamoDB Durable, managed Key-value and document. Partition key plus optional sort key, single-digit-millisecond latency at any scale, pay per request or provisioned capacity.
RocksDB Embedded, on disk An LSM-tree library, not a server. The storage engine inside Kafka Streams, Flink state, CockroachDB and many others.
etcd Durable, Raft-replicated Small, strongly consistent store for configuration and coordination (Kubernetes state). Not for bulk data.

When to use one

  • Good fit: caching expensive query results, sessions, counters, leaderboards (Redis sorted sets), idempotency keys, deduplication in pipelines, lookups at very high request rates.
  • Poor fit: anything that needs ad hoc queries, joins, or range scans over values. If you keep adding secondary indexes by hand, you want a different database.

Common mistakes

  • Treating a cache as the source of truth. Redis with default settings can lose recent writes on a crash. Keep the real data in a durable database.
  • Hot keys. One key (a global counter, a celebrity’s profile) receives most traffic and overloads a single node or DynamoDB partition. Spread it (counter:{shard}) or cache locally.
  • Huge values. Multi-megabyte values block single-threaded Redis and waste network. Store large blobs in object storage and keep a pointer.
  • No TTL on cache keys, so memory fills up and eviction starts dropping keys you needed.

Learning Resources

Document Based Time Series