DEV Community

Cover image for DynamoDB vs Redis
DynoTable
DynoTable

Posted on • Originally published at dynotable.com

DynamoDB vs Redis

#dynamodb #aws #database #nosql

DynamoDB and Redis are both called NoSQL, but they sit in different tiers of the stack. DynamoDB is a fully managed, serverless database of record that keeps data durable on disk across an AWS Region. Redis is an in-memory data-structure store — most often deployed as a cache, session store, or message broker in front of a durable database. For many systems the answer is not either/or but DynamoDB as the store, Redis (or DAX) as the cache.

Should you use DynamoDB or Redis?

Use DynamoDB as your durable system of record: structured items you must not lose, read and written by key at scale. Use Redis as an in-memory layer for microsecond reads, rich data structures (sorted sets, streams, counters), caching, rate limiting, or pub/sub. They are commonly paired — Redis (or DynamoDB's own DAX cache) sits in front of DynamoDB rather than replacing it.

DynamoDB vs Redis at a glance

Characteristic DynamoDB Redis
Data model NoSQL key-value and document; typed items up to 400 KB, grouped in tables In-memory key-value with typed values — strings, hashes, lists, sets, sorted sets, streams, and more
Primary role Durable database of record In-memory cache, session/rate-limit store, message broker; can be a primary store with persistence enabled
Query language / API Native API (GetItem, Query, Scan, PutItem, …) plus PartiQL, a SQL-compatible language Per-data-structure commands (GET, HSET, ZADD, XADD, …); no general query language or ad-hoc joins
Durability Data persisted to disk and replicated across Availability Zones in a Region In-memory by default; durability is optional via RDB snapshots and/or AOF append-only logging
Consistency Eventually consistent by default; strongly consistent reads available per request A single node is strongly consistent for its keys; replicas are asynchronous, so replica reads can lag
Scaling model Automatic partitioning managed by AWS; serverless, scales throughput and storage Vertical (RAM-bound) plus Redis Cluster for horizontal sharding across nodes; capacity bounded by memory
Latency profile Single-digit-millisecond reads/writes at any scale Microsecond operations because data lives in RAM
Pricing / ops model Serverless pay-per-request or provisioned capacity plus storage; AWS-only, no servers to run Open-source (self-hosted) or managed (e.g. Redis Cloud, ElastiCache); typically billed by node memory/throughput
Best-fit workloads Durable records with predictable key access needing consistent latency at scale Caching, leaderboards, counters, rate limiting, queues, pub/sub, ephemeral session data

When DynamoDB is the better choice

  • The data must survive. DynamoDB persists every write to disk and replicates it across Availability Zones. Redis is in-memory first; without RDB/AOF persistence a restart loses data, and even with persistence it is tuned for speed over guaranteed durability.
  • You need a system of record on AWS. DynamoDB integrates natively with IAM, Lambda, and Streams, and offers point-in-time recovery and backups as configuration.
  • Your working set is larger than memory. DynamoDB stores data on disk, so cost scales with storage rather than RAM. Redis capacity is bounded by the memory you provision.
  • You want serverless scaling. On-demand capacity scales to traffic with nothing to size or patch.

When Redis is the better choice

  • You need microsecond latency. Redis keeps data in RAM, so operations complete in microseconds — a step below DynamoDB's single-digit-millisecond profile.
  • You need rich in-memory data structures. Sorted sets for leaderboards, atomic counters, lists for queues, and streams for event fan-out are first-class Redis operations, not something you model in a durable store.
  • The data is ephemeral or cache-like. Session tokens, rate-limit windows, and computed results that can be regenerated fit Redis's in-memory model, often with a short TTL.
  • You need pub/sub or a lightweight message broker. Redis provides publish/subscribe and stream primitives out of the box.

Using them together

The most common production pattern is not choosing one — it is layering them:

  • Keep the durable records in DynamoDB as the source of truth.
  • Put Redis in front as a read cache for hot keys, or use it for leaderboards, counters, and rate limiting alongside DynamoDB.
  • If you want caching without running Redis yourself, DynamoDB offers DynamoDB Accelerator (DAX) — a fully managed, DynamoDB-API-compatible in-memory cache that reduces eventually consistent read latency from milliseconds to microseconds without application changes. DAX is read-through/write-through and caches items by primary key.

DAX versus Redis is itself a trade-off: DAX is DynamoDB-specific and drop-in, while Redis is a general-purpose data-structure store you can use across many data sources but must operate or pay a managed provider to run.

What a Redis sorted set becomes in DynamoDB

A monthly leaderboard in Redis is one key and four commands:

ZADD leaderboard:2026-07 GT CH 4820 user:8231
ZRANGE leaderboard:2026-07 0 9 REV WITHSCORES
ZREVRANK leaderboard:2026-07 user:8231
EXPIRE leaderboard:2026-07 2678400
Enter fullscreen mode Exit fullscreen mode

GT raises a score only when the new one is higher, REV reads the top ten
highest-first, and ZREVRANK answers "where does this player sit" in O(log(N)).
The sorted set stays ordered on the server, and none of that ordering is your
application's problem.

Only the write survives the move. A ConditionExpression reproduces GT
exactly:

{
  "TableName": "leaderboard",
  "Key": {"PK": {"S": "BOARD#2026-07"}, "SK": {"S": "USER#8231"}},
  "UpdateExpression": "SET #s = :score",
  "ConditionExpression": "attribute_not_exists(#s) OR #s < :score",
  "ExpressionAttributeNames": {"#s": "score"},
  "ExpressionAttributeValues": {":score": {"N": "4820"}}
}
Enter fullscreen mode Exit fullscreen mode

ZINCRBY maps just as cleanly onto ADD #s :delta, DynamoDB's atomic counter.

The top ten needs a modeling decision Redis never asked you to make. Add a GSI
with boardId as its partition key and score as its sort key, and the read
becomes a Query walking that index backwards:

{
  "TableName": "leaderboard",
  "IndexName": "board-score-index",
  "KeyConditionExpression": "boardId = :b",
  "ExpressionAttributeValues": {":b": {"S": "BOARD#2026-07"}},
  "ScanIndexForward": false,
  "Limit": 10
}
Enter fullscreen mode Exit fullscreen mode

Every player on the board now shares one partition key on that index, so the
board's entire write traffic and every top-N read land on a single partition.
That is the hot-partition shape key design exists to avoid, and this access
pattern requires it.

ZREVRANK has no counterpart at all. DynamoDB will not tell you an item's
position in an index, so a player's rank means querying the index descending and
counting until you reach them. Select: "COUNT" returns a number instead of
items, but AWS computes capacity on the items read rather than the response, and
the query still pages at 1 MB. Ranking the 40,000th player of a 50,000-player
board is 40,000 items read and a pagination loop you maintain. Redis did it in
one command.

Expiry drifts too. Redis has bounded its expire error at 0 to 1 milliseconds
since version 2.6, so a board keyed by month disappears when you said it would.
DynamoDB deletes expired items "within a few days of their expiration time", and
AWS's own guidance is to "use filter expressions to remove expired items from
Scan and Query results". Last month's board keeps answering queries until the
background process reaches it, and hiding it is your read path's job.

DynoTable's SQL Workbench does not close this gap. ORDER BY score DESC LIMIT 10
is a shape it plans well against that index; there is no rank operator for it to
compile to.

Working with DynamoDB

Once DynamoDB is your durable store, DynoTable is a native desktop client for browsing, editing, and querying your tables across macOS, Windows, and Linux. It reads your standard AWS credential chain, so there is nothing to migrate — point it at your Region and tables and your data stays in DynamoDB. Its SQL Workbench expresses relational-shaped queries within DynamoDB's access-pattern rules, and its AI agent runs on your own AWS Bedrock credentials.

For building the key conditions, filters, and update expressions your caching and record-keeping code needs, the free DynamoDB Expression Builder generates ready-to-paste SDK, CLI, and PartiQL output with no install. DynoTable is a closed-source commercial app; this page describes what it does, not how it is built.

FAQ

Can Redis replace DynamoDB?

Usually not as a system of record. Redis is in-memory first, so unless you enable and tune its persistence it is designed as a cache or ephemeral store, not a durable database. DynamoDB persists and replicates every write across Availability Zones. Many teams use both: DynamoDB for durable data, Redis (or DAX) as the fast in-memory layer in front of it.

Is DynamoDB or Redis faster?

Redis is faster per operation because it serves data from RAM in microseconds, while DynamoDB targets single-digit-millisecond reads and writes from durable storage. If you need DynamoDB with cache-like latency, DAX brings eventually consistent reads down to microseconds without leaving the DynamoDB API.

What is DynamoDB's equivalent of Redis caching?

DynamoDB Accelerator (DAX) is AWS's built-in, fully managed in-memory cache for DynamoDB. It is API-compatible, so existing DynamoDB calls work unchanged, and it caches items by primary key as a read-through/write-through layer. It is DynamoDB-specific, whereas Redis is a general-purpose data-structure store.

Related

References

Last verified 2026-07-13 against the official AWS DynamoDB Developer Guide and Redis documentation. Redis is a trademark of its respective owner; referenced here for identification only.

Top comments (0)