Key-Value Store
The simplest NoSQL model: store data as key-value pairs. Blazing fast lookups by key. Redis, DynamoDB, and etcd are key-value stores.
What is Key-Value Store?
In short
A key-value store is a database that saves data as a collection of key-value pairs, where each unique key maps to exactly one value, and you read or write data by referencing the key directly. It is the simplest NoSQL model and gives near constant-time lookups because retrieving a value is just a hash table lookup rather than a query that scans or joins tables.
What a key-value store actually is
Picture a dictionary or a hash map. You have a key like user:1042 and a value like the JSON blob describing that user. A key-value store is that same idea persisted as a database. You hand it a key, it hands you back the value. You do not write SQL, you do not define columns, and the store does not care what is inside the value.
The value is treated as an opaque blob in most pure key-value stores. It can be a string, a number, a serialized JSON object, a binary image, or a protobuf. The database does not parse it or index its contents. That is what keeps the model so simple and so fast.
Because there is no schema, two values under different keys can have completely different shapes. user:1042 might hold a profile while session:abc holds a login token with an expiry. The store does not enforce any structure across keys, which makes it a poor fit for ad hoc reporting but excellent for fast, predictable single-record access.
How it works under the hood
Lookups are fast because the key is run through a hash function that points more or less directly at where the value lives, either in memory or on disk. There is no table scan and no join planning. A get by key is roughly O(1), so a 100 byte read or a 10 MB read both come back in single-digit milliseconds or less.
In-memory stores like Redis keep the whole dataset in RAM and use hash tables internally, which is why they answer in microseconds. Disk-backed stores like RocksDB and the engines behind DynamoDB use a log-structured merge tree (LSM tree): writes append to an in-memory buffer, get flushed to sorted files on disk, and background compaction merges those files. This makes writes very cheap and keeps reads fast through bloom filters and sorted indexes.
Distributing the data across many machines is done with partitioning. The key is hashed and that hash decides which node owns the key, usually through consistent hashing so that adding or removing a node only shuffles a small slice of keys. DynamoDB and Cassandra-style systems also replicate each key to several nodes for durability and availability, which is where tunable consistency (read your writes versus eventual consistency) comes in.
When to use it and the trade-offs
Reach for a key-value store when your access pattern is known in advance and is almost always by primary key. Session storage, user profiles fetched by id, shopping carts, feature flags, rate-limit counters, and caching layers in front of a slower database are the classic fits. If you can always answer with the key, this model is hard to beat on speed and scale.
The cost is query flexibility. You cannot say find all users in London who signed up last week unless you have built a separate index keyed on that question. There are no joins, no GROUP BY, and usually weak or no support for range scans across arbitrary fields. Every new access pattern means designing a new key or maintaining a secondary index yourself.
Many real systems use a key-value store alongside a relational database rather than instead of one. Postgres or MySQL holds the source of truth and supports rich queries, while Redis or DynamoDB serves the hot, high-volume reads. The other common gotcha is that in-memory stores are bounded by RAM, so you must set eviction policies and accept that data can be lost on a crash unless persistence or replication is configured.
A concrete real-world example
Amazon built DynamoDB after the original Dynamo paper because their shopping cart needed to stay available even during failures and traffic spikes on days like Prime Day. The cart is stored as a value under a customer key. Reads and writes are single-key operations, replicated across multiple availability zones, and the system favors staying writable over perfect consistency so a customer can always add an item.
On the caching side, almost every large website puts Redis or Memcached in front of its database. When a request comes in for a product page, the app first checks Redis for product:5567. If it is there, the page renders in under a millisecond. If not, the app reads from Postgres, writes the result back into Redis with a time to live, and serves it. The next thousand requests for that product never touch the database.
Where it is used in production
Redis
In-memory key-value store used for caching, session storage, rate limiting, and leaderboards, answering in microseconds.
Amazon DynamoDB
Managed key-value and document store on AWS that powers shopping carts and high-traffic services with single-digit millisecond reads at any scale.
etcd
Strongly consistent key-value store that holds all Kubernetes cluster state, with every config and object stored under a key.
Memcached
Lightweight distributed memory cache used by Facebook and many others to store key-value pairs in front of databases.
Frequently asked questions
- What is the difference between a key-value store and a relational database?
- A relational database stores data in tables with rows, columns, and a fixed schema, and lets you query across them with SQL, joins, and filters. A key-value store just maps a key to a value with no schema and no joins; you fetch data only by key. Relational wins on flexible querying, key-value wins on raw lookup speed and horizontal scale.
- Is Redis a key-value store?
- Yes. Redis is an in-memory key-value store, though it also supports richer value types like lists, sets, sorted sets, and hashes under each key. That makes it more than a plain string store while keeping the core key-based access model.
- When should I not use a key-value store?
- Avoid it as your only database when you need ad hoc queries, reporting, joins across entities, or filtering by fields other than the key. For example, find all orders over $100 from last month is awkward in a pure key-value store and trivial in SQL. Many teams use a relational database as the source of truth and a key-value store as a cache.
- How does a key-value store scale to millions of requests?
- It hashes each key to decide which server owns it, usually with consistent hashing, so data spreads evenly across nodes. Adding a node only moves a small fraction of keys. Because every operation is a single-key get or put with no joins, each node handles its slice independently, which scales almost linearly.
- Are values in a key-value store always strings?
- No. The value is treated as an opaque blob, so it can be a string, number, JSON, serialized object, image, or any binary data. The store typically does not parse or index the contents; it just stores and returns whatever bytes you put under the key.
Learn Key-Value Store hands-on
This page explains the idea. The full lesson lets you step through the ring as servers join and leave, read the implementation, and check yourself with a quiz. It is one of 760+ lessons in the System Design Masterclass, from your first API call to distributed consensus. Eleven Foundation lessons are free, no signup. Lifetime access is ₹499 in India or $7.99 worldwide, one payment, no subscription.
Related lessons
Lessons that touch on Key-Value Store as part of a larger topic.
Design a Key-Value Store
Design a distributed key-value store - LSM trees, compaction, consistent hashing, replication, tunable consistency, and failure detection
capstone · capstone
Key-Value Stores
The simplest database model, a giant hash map that powers caching, sessions, and real-time apps
intermediate · database types storage
See also
Related glossary terms you might want to look up next.
Redis
An in-memory data store used as a cache, message broker, and database. Blazing fast because everything lives in RAM.
NoSQL
Databases that don't use traditional table-based relational models. Includes document stores, key-value, graph, and column-family databases.
Document Database
A NoSQL database that stores data as flexible JSON-like documents. MongoDB and CouchDB let each document have a different structure.
Memcached
A simple, high-performance distributed memory caching system. Stores key-value pairs in RAM. Simpler than Redis but less feature-rich.
Column-Family Store
A NoSQL database that groups columns into families, optimized for reading and writing large amounts of data across many machines. Cassandra and HBase use this model.
Graph Database
A database built for storing and querying relationships between entities. Nodes are entities, edges are relationships. Neo4j is the most popular.