A key-value store (also called a key-value database) is a database model in which every record is a pair of a unique key and an associated value, and data is stored and retrieved by key alone. Among database models, it is the simplest: the database does not interpret the value, which may be a string, a number, a serialized object or a binary blob, and it offers only a few basic operations such as get, put and delete.
That simplicity is the source of its strength. Because each operation touches one key, a key-value store can deliver very low latency, often below a millisecond, and can be partitioned across many servers almost without limit. It is the foundation of caches, session stores, configuration services and the storage engines underneath many other databases, and it is one of the core families of NoSQL databases.
How a key-value store organizes data
A key-value store behaves like a persistent hash map. The application chooses the key, for example user:4821:profile, and the database locates the value through an internal index, usually a hash table or an ordered structure such as a B-tree or LSM tree.
The choice of internal structure decides which operations are cheap. Hash-based stores answer exact lookups in roughly constant time but cannot list keys in order. Ordered stores keep keys sorted, which enables range scans and prefix queries, such as reading every key that begins with order:2026-11.
Because the store does not understand the value, there is no schema, no join and usually no secondary index. Any query that is not a lookup by key must be designed into the key structure in advance or handled by the application.
Core operations and key design
The interface of a key-value store is intentionally small. Most systems add a few extensions to the three basic operations, such as expiration times, atomic counters and conditional writes.
| Operation | Purpose | Typical use |
|---|---|---|
| GET key | Read the value stored under a key | Load a session or cached page |
| PUT or SET key value | Create or overwrite a value | Store a computed result |
| DELETE key | Remove a key and its value | Invalidate a cache entry |
| Expire or TTL | Remove a key automatically after a time | Sessions, rate-limit windows |
| Compare-and-set | Write only if the value is unchanged | Optimistic concurrency, locks |
| Scan by prefix or range | Iterate over related keys | Ordered stores only |
Key design is the main modeling task. Good keys are predictable and evenly distributed, for example tenant:42:cart:9917. Poor keys, such as a timestamp prefix for all writes, concentrate traffic on one partition and create a hot spot that limits throughput.
Types of key-value stores
Key-value stores differ mainly in where data lives and how it is distributed. The categories below overlap, and many products combine several of them.
| Category | Characteristics | Typical examples |
|---|---|---|
| In-memory stores | Data held in RAM, optional persistence | Redis, Memcached, Valkey |
| Embedded stores | Library inside the application process | RocksDB, LevelDB, LMDB |
| Distributed stores | Data partitioned and replicated across nodes | Amazon DynamoDB, Riak, TiKV |
| Coordination stores | Strongly consistent, small datasets | etcd, ZooKeeper, Consul |
Distributed key-value stores usually spread keys with consistent hashing or range partitioning and keep several replicas of each partition. They then choose between strong and eventual consistency, a trade-off that determines whether a read always sees the latest write.
Persistence also varies widely. Some in-memory stores write periodic snapshots or an append-only log to disk, so a restart loses at most the last few seconds or nothing, depending on configuration. Embedded and distributed stores write every change to durable storage first, which costs some latency but makes them suitable as a primary system of record.
Key-value stores compared with other database models
The key-value model trades query flexibility for speed and scalability. Neighboring models add structure to the value or relationships between records, which enables richer queries at a higher cost.
| Model | Data unit | Query capability |
|---|---|---|
| Key-value store | Opaque value under a key | Lookup by key, sometimes range scans |
| Document database | Structured document such as JSON | Queries and indexes on fields |
| Wide-column database | Rows with flexible column families | Key plus column range queries |
| Relational database | Rows in tables with a fixed schema | SQL with joins and aggregation |
| Graph database | Nodes and relationships | Traversals across connections |
The boundaries are not sharp. Many document and wide-column databases are built on top of an ordered key-value engine, and some key-value products offer rich value types, such as lists, sets and sorted sets, that move them closer to a data structure server.
When to use a key-value store and what to avoid
A key-value store is the right choice when access patterns are known in advance and almost every request can be answered by one or a few keys. It is a poor choice when the application needs ad hoc queries, reporting or relationships between many entities.
- Use it for caching, sessions and counters, as well as feature flags and shopping carts, where lookups by identifier dominate.
- Avoid it as the only store for data that needs joins, complex filtering or analytical queries.
- Plan memory and eviction policies for in-memory stores, since a full store evicts or rejects data.
- Watch value size, because very large values slow down replication and network transfer.
- Do not treat a cache as durable storage unless persistence and replication are explicitly configured.
Stripped to the essentials
Think of a cloakroom at a theater. You hand over your coat and receive a numbered ticket. Later, you show the ticket and get exactly your coat back, quickly, without anyone searching through the racks. A key-value store works the same way: the ticket number is the key, and the coat is the value.
The attendant does not care what is in your pockets and cannot answer questions like “show me all blue coats”. It is extremely fast at one job: returning the right item for the right ticket. That is why it is ideal for simple lookups and less suitable for complex searches.
Where it is applied
A popular online store keeps its product catalog in a relational database, but every product page also needs the visitor’s session, cart and a set of personalized recommendations. Querying the relational database for all of this on every page view would add tens of milliseconds per request during sales events.
The engineering team moves sessions and carts into an in-memory key-value store with keys such as session:{id} and cart:{userId}, each with a 24-hour expiration. Rendered recommendation blocks are cached under keys that include the product identifier and expire after 10 minutes.
During the next seasonal sale, the key-value store answers well over 100,000 lookups per second with sub-millisecond latency, the relational database load drops sharply, and checkout remains responsive throughout the peak.