Redis and DynamoDB get compared because both are key-value stores, but they solve different problems: Redis optimises for latency, DynamoDB optimises for durability and unattended scale.
Teams usually arrive at this comparison from one of two directions. Either they have Redis and are wondering whether it can be the primary datastore, or they have DynamoDB and the latency is not what they hoped. Both instincts point at the same answer, which is that these two things are frequently used together rather than instead of each other.
That said, there are workloads where one is clearly correct and the other is a mistake. Knowing which is which saves an expensive architectural detour.
Table of contents
- What each one actually is
- Latency and the difference between fast and predictable
- Data models: structures versus items
- Durability, eviction, and what happens on a bad day
- Cost shape, which is where the surprise usually lands
- The layered pattern most production systems land on
- How this fits the rest of the stack
- FAQ
What each one actually is
Redis is an in-memory data structure server. It holds your working set in RAM and gives you sub-millisecond access to strings, hashes, lists, sets, sorted sets, bitmaps, and streams — with atomic operations built into each type. Persistence exists via snapshots and an append-only file, but memory is the design centre.
DynamoDB is a fully managed NoSQL database. Data is written to disk and replicated across multiple availability zones before the write is acknowledged. It scales without you provisioning nodes, and it will keep doing that at a volume where you would be operating a Redis cluster by hand.
The distinction that matters: Redis is fast because the data is in memory, and memory is finite and volatile. DynamoDB is durable because the data is on replicated disks, and disks are slower. Neither is a defect. They are the trade being made.
Latency and the difference between fast and predictable
Redis delivers sub-millisecond reads for in-memory data. Nothing that writes to disk before acknowledging will match that, which is why Redis is the default answer for session stores, rate limiters, and leaderboards.
DynamoDB delivers single-digit millisecond latency at essentially any scale, and — this is the underrated part — it delivers it consistently. A Redis instance under memory pressure, mid-eviction, or failing over is far less predictable than its happy-path number suggests.
So the useful question is not “which is faster” but “how much latency does this operation actually tolerate”. A rate limiter checked on every request needs Redis speed. An order record read once per checkout does not.
Data models: structures versus items
Redis gives you data structures with operations attached. You can atomically increment a counter, push to a list, add to a sorted set with a score, or compute a set intersection — server-side, without reading data into your application.
DynamoDB gives you items in tables, addressed by a partition key and optional sort key, with secondary indexes for alternate access patterns. It is a document and key-value model, and query patterns must be designed up front because you cannot join and you cannot efficiently query on an unindexed attribute.
# Redis: the operation lives in the database
ZADD leaderboard 4200 player:17
ZREVRANGE leaderboard 0 9 WITHSCORES
INCR ratelimit:user:17
EXPIRE ratelimit:user:17 60
# DynamoDB: you design the key schema around the access pattern
PK = USER#17 SK = ORDER#2026-08-04#a91f
PK = USER#17 SK = PROFILEThis is why the Redis data-structure catalogue matters so much in practice. A sorted set with an atomic increment replaces a read-modify-write cycle that would be a race condition in most databases.
Durability, eviction, and what happens on a bad day
DynamoDB writes are durable on acknowledgement, replicated across availability zones. Losing an instance does not lose data. Backup and point-in-time recovery are managed features rather than things you build.
Redis persistence is real but weaker by design. Snapshotting writes point-in-time dumps, so a crash loses everything since the last one. The append-only file is more durable, though the default fsync policy still leaves a window. And when memory fills, the eviction policy decides what disappears — which is exactly right for a cache and exactly wrong for your only copy of a record.
The rule that keeps teams out of trouble: if losing a key would require an apology to a user, that key should not live only in Redis.
Cost shape, which is where the surprise usually lands
Redis costs scale with memory. You provision an instance sized for your working set plus headroom, and you pay for that whether it is full or empty. Predictable, and cheap while the dataset is small — but RAM is the expensive storage tier, and a large dataset in Redis gets costly fast.
DynamoDB costs scale with usage: read and write capacity plus stored data. On-demand pricing means an idle table costs almost nothing, which is excellent for spiky workloads. The failure mode is different — a hot partition or an unindexed scan can produce a bill that does not resemble last month’s.
- Small hot dataset, high request rate: Redis is usually cheaper and much faster
- Large dataset, moderate request rate: DynamoDB is dramatically cheaper
- Spiky and unpredictable traffic: DynamoDB on-demand absorbs it without provisioning
- Steady predictable load on a small working set: a provisioned Redis instance wins
The layered pattern most production systems land on
In practice the two end up stacked. DynamoDB, or any durable database, holds the record of truth. Redis holds the hot subset, the session state, the rate-limit counters, the derived leaderboards, and anything that can be recomputed if it vanishes.
That split gives you the latency of memory on the read path that needs it, and the durability of replicated disk on the data you cannot lose. It also makes the cache invalidation question explicit rather than accidental, which is worth something.
If you are running a single application and are not on AWS, the comparison often resolves differently: Redis for the cache and a managed PostgreSQL instance for the durable store, which gives you relational queries that DynamoDB will not.
How this fits the rest of the stack
Layering a cache in front of a database means two services, not one, and the cost of that pair is easier to reason about before you build it than after. RunxBuild runs managed Redis and managed databases on the same deployment path, with a private network between them, so the cache never has to cross the public internet to reach the record of truth. The RunxBuild hosting calculator puts the service, the cache, and the database side by side as separate line items.
Useful related references:
- ioredis vs node-redis: Which to Ship With
- Redis Pipeline: How to Batch Commands, When to Use It, and Why It Is Not the Same as a Transaction
- Redis Persistence: RDB, AOF, and the Right Defaults
- Databases on RunxBuild
FAQ
Can Redis replace a primary database?
For data that can be recomputed or safely lost, yes. For records that must survive a crash, treat Redis as a cache in front of a durable store. Redis persistence reduces the risk but does not make it a system of record.
Is DynamoDB faster than Redis?
No. Redis serves in-memory reads in under a millisecond; DynamoDB is typically single-digit milliseconds because it reads from replicated durable storage. DynamoDB’s advantage is consistency of that latency at large scale, not raw speed.
Why do teams run both?
Because the trade-offs are complementary. DynamoDB holds durable records at scale; Redis holds the hot working set, sessions, counters, and derived structures. The layering gives memory latency where it matters and durability where it matters.
What happens when Redis runs out of memory?
The configured eviction policy takes over — commonly evicting the least recently used keys, or rejecting writes if eviction is disabled. This is correct behaviour for a cache and dangerous if Redis holds your only copy of something.
Can I use DynamoDB outside AWS?
Not for production. DynamoDB is an AWS-managed service; the downloadable local version exists for development and testing only. If you need a managed key-value store elsewhere, Redis or a managed database is the practical route.