DynamoDB vs Redis: Differences and When to Use Each

Choose DynamoDB for durable application records with predictable key-based access and AWS-managed operations. Choose Redis for low-latency data structures, caching, counters, leaderboards, and workloads that benefit from processing data in memory. They often work together: DynamoDB holds the authoritative record, while Redis holds a disposable copy or a derived view.

DynamoDB and Redis: an overview

Amazon DynamoDB is a managed key-value and document database. AWS operates its storage, replication, and partition infrastructure. You still design keys and indexes, choose capacity settings, configure backups, and monitor throttling. Its main advantage is predictable access to records without running a database cluster.

Redis is an in-memory data structure server that you can operate yourself or buy as a managed service. Its data types include strings, hashes, lists, sets, sorted sets, streams, and geospatial indexes. Redis 8 also brings JSON, search, and other capabilities into the main distribution. Redis Cloud and Redis Software add deployment and operational capabilities; their guarantees are not identical to a self-managed Redis instance.

Comparison at a glance

The item-size limit includes attribute names and values; see DynamoDB constraints. Neither system removes the need to test your own access pattern.

Shared features of DynamoDB and Redis

Both support key-oriented access, atomic updates, expiration, and partitioning across machines. Both can serve web, mobile, and gaming applications. The useful distinction is how your application uses those features.

A DynamoDB item can hold a user's profile or an order. A Redis sorted set can maintain a leaderboard and return a score range without your application rebuilding the ordering. Although DynamoDB can model a leaderboard with keys and indexes, that is a different design from calling a specialized Redis command.

Expiration also differs. DynamoDB TTL performs asynchronous cleanup, so your application must reject expired records while they await deletion. Do not use its deletion time as the exact instant a session becomes invalid. Redis expiration is part of its key-access behavior, making it a natural fit for short-lived cache entries.

Latency and performance of DynamoDB vs Redis

DynamoDB

DynamoDB is designed for low-latency key-based operations. A correctly designed Query reads a specific key range; a Scan works through a table or index. Moving a SQL-style search into a filter does not make it an indexed query. Start with your DynamoDB access patterns before comparing throughput.

DynamoDB Accelerator (DAX) is a managed cache for compatible DynamoDB access patterns. It can reduce read latency, but cache hits, cache misses, and strongly consistent reads have different behavior. It is an alternative to writing a separate Redis cache when you want DynamoDB-specific caching rather than Redis data structures.

Redis

Keeping the working data in memory and executing specialized commands can make Redis a good fit for tight latency budgets. End-to-end performance still depends on network distance, connection reuse, payload size, persistence configuration, and command complexity. A large operation that blocks a shard can hurt unrelated requests.

Benchmark the actual operation, including serialization and failure behavior. Comparing a cached Redis GET against a durable database write answers a different question from comparing two equally durable storage designs. Measure tail latency, cache hit rate, and performance after a node replacement, not just a warm-cache average.

Availability and durability

DynamoDB

AWS manages replication across Availability Zones within a Region. For regional resilience, global tables offer multi-Region eventual consistency (MREC) or multi-Region strong consistency (MRSC). These modes have different latency and feature tradeoffs; MRSC does not support transactions or TTL.

Regional replication protects against infrastructure failures. Backups protect against accidental writes and deletions. One does not replace the other.

Redis

Redis is not limited to disposable caching. Open Source Redis supports RDB snapshots and append-only file persistence. Snapshots and AOF have different recovery and write-cost tradeoffs, and neither should be confused with a tested off-host backup.

Redis Cluster uses asynchronous replication. Its cluster specification explicitly describes failure windows in which acknowledged writes can be lost. Managed Redis offerings can provide additional availability and persistence features, but choose those features explicitly when Redis stores authoritative data.

Consistency and transactions

DynamoDB supports conditional writes and ACID transactions across items in the same account and Region. Strongly consistent reads are available on tables and local secondary indexes, while global secondary indexes are eventually consistent. Global replication needs its own consistency decision.

Redis commands are atomic, and MULTI/EXEC transactions execute queued commands without another client's command interleaving. WATCH provides optimistic concurrency control. Redis does not roll back successful commands when another command encounters an execution-time error. In Redis Cluster, multi-key operations generally require the keys to share a hash slot.

For an inventory decrement, decide what happens during a retry, failover, or concurrent purchase. The presence of a feature called “transactions” in both systems does not make those behaviors interchangeable.

Security

DynamoDB integrates with IAM, resource-based policies, KMS encryption at rest, and VPC endpoints. Scope permissions to the tables, indexes, streams, and operations the application needs. The AWS Database Encryption SDK provides client-side encryption when the application requires it.

Redis supports ACLs for users, commands, and key patterns, as well as TLS. The old claim that Redis has no access control is incorrect. Use private networking, restricted users, and appropriate encryption. For managed deployments, check which controls your plan includes rather than assuming all plans have the same network isolation.

Backups and scalability

DynamoDB offers on-demand backups and configurable point-in-time recovery. A restore creates a new table, so rehearse how the application switches to it. Scaling is managed, but a hot key, a restrictive throughput cap, or an underprovisioned index can still throttle requests.

For Redis, plan for memory overhead, replication, persistence, backups, and temporary resource use during maintenance. Redis Cluster distributes data across shards; it does not turn an expensive operation on one key into a distributed operation. Managed services can automate scaling and failover, but the application must still handle connection interruptions and retries.

Redis licensing, Valkey, and AWS offerings

Redis licensing is version-specific. According to the official licensing overview, Redis 7.2 and earlier use BSD-3-Clause, Redis 7.4 uses RSALv2 or SSPLv1, and Redis 8 and later add AGPLv3 as a third option. Do not describe all current Redis releases as BSD-licensed.

Valkey is a separate, Linux Foundation-backed BSD-licensed project. AWS ElastiCache offers Valkey, Redis OSS, and Memcached engines. Choosing ElastiCache for Valkey is not the same as choosing the latest Redis 8 release: check command and feature compatibility, particularly for search and JSON workloads.

When to use each, or both

Choose DynamoDB for orders, account records, device state, and other durable records when you can describe their access paths up front. Choose Redis for leaderboards, rate limiting, real-time counters, session caches, and stream-based application features where its commands reduce application work.

A common combined design is cache-aside:

1. Read Redis using the application record's cache key.
2. On a miss, read DynamoDB and cache the result with an expiration time.
3. After changing DynamoDB, invalidate or update the relevant cache entry.
4. Fall back to DynamoDB when the cache is unavailable, with rate limits to protect the database.

Use DynamoDB Streams for asynchronous invalidation when useful, but account for propagation delay. Concurrent reads can refill an old value after an invalidation; versions or bounded expiration times help manage that race. Cache sensitive or rapidly changing data only when the accepted staleness is clear.

Pricing

DynamoDB pricing combines storage with on-demand request charges or provisioned capacity. Indexes, replicated writes, backups, and other features can add charges. Use the pricing calculator with your item sizes and access mix.

Self-hosted Redis incurs infrastructure and operational costs even when there is no software subscription. Redis Cloud pricing depends on plan, capacity, and deployment features. ElastiCache pricing distinguishes node-based deployments from serverless storage and compute usage. Price the required replicas and recovery behavior, then estimate whether avoided database reads justify the cache's cost.