What Is a Key-Value Store? Redis, Valkey, DynamoDB and etcd Explained

A key-value store files every value under a key. You hand it a key and a value to keep, and later you hand it the key and get the value back. That’s the whole contract. Think of a coat check: you get a ticket, and the ticket is all anyone needs to find your coat. Nobody goes through the coats looking for a blue one.

That simple contract is why key-value stores are fast. Finding a value by its key is a direct jump, through a hash table or a sorted tree, with no query to plan and no tables to join. It’s also why they spread so well over many machines: if every request names its key, the key alone says which machine to ask.

The price is what you can’t ask. A key-value store can’t find “every user in Lisbon” unless you’ve built and kept up that list yourself, under a key of its own. There are no joins, and transactions, where a store has them, come with limits: a Redis or Valkey cluster runs one only when all its keys share a slot, and DynamoDB caps one at 100 items. A SQL database answers questions you didn’t plan for. A key-value store answers the ones you designed it for, quickly, at any size.

The Main Kinds

In-memory data structure servers. Redis is the best known, and Valkey is its open-source fork, started under the Linux Foundation in 2024 from Redis 7.2.4 after Redis changed its license. They hold everything in memory, and a value can be more than a string: a hash of fields, a list, a set, a sorted set with scores, a stream. That makes them the usual choice for caches, sessions, rate limits, queues and leaderboards.

Managed cloud stores. Amazon DynamoDB keeps items under a partition key, with an optional sort key to keep related items in order, and scales to any size without servers to manage. Its API writes every value wrapped in its type, which is what the Typed JSON Converter unwraps. Cloudflare Workers KV keeps values close to users at the edge of its network.

Coordination stores. etcd, Consul and ZooKeeper keep small amounts of data that must never disagree, such as configuration and which server leads. They copy every write to a majority of their nodes before saying it’s done. Kubernetes keeps the whole state of a cluster in etcd.

Embedded stores. RocksDB, LevelDB, LMDB and bbolt are libraries inside a program rather than servers, keeping their data in local files. Many bigger databases are built on top of one.

How Keys Spread Over Machines

When a store runs on many machines, something has to decide which machine holds which key. The usual answer is to hash the key. DynamoDB hashes the partition key to pick a partition. Redis and Valkey clusters run a checksum over the key and file it in one of 16,384 slots, and each primary server owns a range of slots. Commands that touch several keys only work when the keys share a slot, which is what hash tags are for: in user:{42}:name, only the 42 is hashed. The Hash Slot Calculator shows where any key lands.

The hard part is changing the number of machines. Hash a key and divide by the number of servers, and adding one server sends almost every key somewhere new. Consistent hashing fixes that by moving only the keys the new server should take. The Consistent Hashing Playground lets you watch the difference.

Designing Keys

Since the key is the only way in, key names carry the structure that tables carry elsewhere. Most teams write keys as parts joined by a separator, broadest first: user:42:profile, user:42:cart, session:9f86d081. The first part works like a table name. Keys stay short, because every key name sits in memory next to its value, and a million long names add up.

Two habits save trouble later. List keys with SCAN, never KEYS *, which blocks the server while it walks every key. And look at what’s really in there now and then, because naming drifts: usr: turns up next to user:, and old features leave keys nobody remembers. The Keyspace Map does that from a plain key list.

When a Key-Value Store Fits

It fits when you know the key at the moment you need the value: a user’s session, a cached page, a rate-limit counter, a feature flag, a shopping cart, a leaderboard. It’s a poor fit for questions you can’t predict, reports across all your data, or data full of relations that need joins. Most real systems use both: a SQL database as the record, and a key-value store in front of it for the reads that must be fast. How many keys that store needs to hold is something the Traffic Analyzer works out from a capture of real traffic.

Loading a lot of data into Redis or Valkey is its own small craft, covered by the Mass Insert Builder. All the tools are free and run in your browser, on the tools page.