Key-value databases store data as a collection of key-value pairs. The three real options in 2026 are Redis (in-memory, fastest, rich data types), DynamoDB (managed, serverless, pay-per-request), and Memcached (in-memory, simplest, no persistence). The right answer is Redis for a cache or pub/sub that needs the rich data types, DynamoDB for a serverless app that needs predictable latency at any scale, Memcached for a simple session cache that needs the lowest possible latency. The mistake every team makes: the team picks a key-value database for data that needs to be queried (a JOIN, a search, an aggregate), and the team ends up with a NoSQL tax for a use case that a relational database handles better.
Table of contents
- The data model — the simplest database model
- Redis — the in-memory, rich-data-type option
- DynamoDB — the managed, serverless option
- Memcached — the simplest, no-persistence option
- The tradeoffs — speed, persistence, query model
- The use cases — when key-value is the right answer
- The wrong use case — when key-value is the wrong answer
- How this fits the rest of the stack
- FAQ
The data model — the simplest database model
The data model is a key-value pair. The key is unique, the value is a blob (a string, a JSON, a binary). The right answer is the key-value model for data that is naturally key-based (a session, a user preference, a feature flag, a cache entry). The wrong answer is the key-value model for data that needs to be queried by anything other than the key (a JOIN, a search, an aggregate) — the team is paying for the simple model with a query pattern that does not match.
Redis — the in-memory, rich-data-type option
Redis stores data in memory (with optional disk persistence). The data types are strings, hashes, lists, sets, sorted sets, streams, and the operations are GET/SET, HGET/HSET, LPUSH/RPUSH, PUBLISH/SUBSCRIBE. The right answer is Redis for a cache, a pub/sub, a session store, a leaderboard, a rate limiter, any use case that needs the rich data types and the low latency.
The gotcha: Redis is in-memory, so the cost is the RAM. A 1GB dataset on Redis is a 1GB RAM instance. The right answer is to size the Redis instance to the dataset, the wrong answer is to use Redis for a 100GB dataset (the team is paying for 100GB of RAM).
DynamoDB — the managed, serverless option
DynamoDB is AWS’s managed key-value and document database. The data model is a key-value pair (with optional document structure for the value), the pricing is pay-per-request (or provisioned with auto-scaling), the latency is single-digit milliseconds at any scale. The right answer is DynamoDB for a serverless app, a team that wants the zero-ops story, a team that needs predictable latency at any scale.
The gotcha: DynamoDB’s query model is limited (no JOINs, no aggregates, no full-text search without a separate index). The team that needs to query by anything other than the key must add a Global Secondary Index (GSI), the GSI has its own cost.
Memcached — the simplest, no-persistence option
Memcached is a simple in-memory key-value store. The data model is a string, the operations are GET/SET/DELETE, the value is not persisted (the data is lost on restart). The right answer is Memcached for a simple session cache, a simple rate limiter, a use case where the data is regeneratable.
The gotcha: Memcached has no persistence, no pub/sub, no rich data types. The team that needs any of these is better off with Redis.
The tradeoffs — speed, persistence, query model
The tradeoffs:
- Speed — Memcached is the fastest for simple GET/SET, Redis is close, DynamoDB is the slowest (but the latency is still single-digit ms).
- Persistence — DynamoDB persists by default, Redis persists optionally, Memcached does not persist.
- Query model — all three are key-only, no JOINs, no aggregates, no full-text search.
- Cost — Memcached is the cheapest (a small VM), Redis is in the middle (a small VM with more RAM), DynamoDB is pay-per-request (the cost depends on the team’s traffic).
The use cases — when key-value is the right answer
The right answer for a key-value database is the use case that matches the data model:
- Session cache — Memcached or Redis.
- Pub/sub — Redis.
- Rate limiter — Redis (with INCR and EXPIRE).
- Leaderboard — Redis (with sorted sets).
- Serverless app with predictable latency — DynamoDB.
- Cache for a relational database — Redis or Memcached.
- Feature flag store — Redis or DynamoDB.
The wrong use case — when key-value is the wrong answer
The key-value database is the wrong answer for data that needs to be queried by anything other than the key:
- User profiles with search by name, email, signup date — use a relational or document database.
- Time-series data with aggregate queries — use a time-series database.
- Full-text search — use a search engine (Elasticsearch, OpenSearch, Meilisearch).
- Graph data with relationships — use a graph database.
- Multi-table transactions — use a relational database with ACID.
How this fits the rest of the stack
The infrastructure question is a small piece of a larger pattern: the team’s runtime, storage, database, secret store, logs, and deployment platform are all parts of the same platform. The right answer is to model the full stack before the project ships, not after. The RunxBuild hosting calculator is the right place to do that exercise — pick the runtime, the memory tier, the storage, the secret store, and the egress, and the calculator shows what the deploy actually costs at the team’s actual usage.
Useful related references:
FAQ
What is a key-value database?
A database that stores data as a collection of key-value pairs. The key is unique, the value is a blob (a string, a JSON, a binary).
What is the best key-value database?
Redis for a cache or pub/sub, DynamoDB for a serverless app, Memcached for a simple session cache.
Is Redis a key-value database?
Yes. Redis supports strings, hashes, lists, sets, sorted sets, streams, and bitmaps. The right answer is Redis for a use case that needs the rich data types.
Is DynamoDB a key-value database?
Yes. DynamoDB supports key-value and document data models. The right answer is DynamoDB for a serverless app that needs predictable latency at any scale.
Is Memcached still relevant in 2026?
Yes — for a simple session cache, a simple rate limiter, a use case where the data is regeneratable. The wrong answer is Memcached for a use case that needs persistence or rich data types.
What is the difference between Redis and Memcached?
Redis supports more data types, has persistence, has pub/sub, has Lua scripting. Memcached is simpler, faster for simple GET/SET, and has no persistence.
Can I use a key-value database as my primary database?
Yes, if the data model is naturally key-based and the team does not need JOINs or aggregates. The right answer is DynamoDB for a serverless app, Redis for a cache or session.
What is the cost of DynamoDB?
Pay-per-request (per million reads/writes) or provisioned (per hour). The right answer is pay-per-request for a low-traffic app, provisioned for a high-traffic app.