Amazon MemoryDB for Redis
A Redis-compatible in-memory database that guarantees data durability through multi-AZ transaction logs while delivering microsecond read latency
Overview
Amazon MemoryDB for Redis is a fully managed in-memory database service that provides Redis-compatible APIs. Unlike ElastiCache for Redis, it persists data to a multi-AZ transaction log, ensuring no data loss during node failures or failovers. It delivers microsecond read latency and single-digit millisecond write latency, handling trillions of requests per day. It supports all Redis data structures (String, Hash, List, Set, Sorted Set, Stream) and works with existing Redis client libraries as-is.
The Critical Difference from ElastiCache for Redis
MemoryDB and ElastiCache for Redis both provide Redis-compatible APIs, but their data durability models are fundamentally different. ElastiCache is designed as a cache, and data persistence is not guaranteed. Replication is asynchronous, so when a failover from the primary node to a replica occurs, writes since the last replication may be lost. Snapshot-based backups are available, but data between snapshots cannot be recovered. MemoryDB is designed as a database, with every write synchronously persisted to a multi-AZ transaction log. Even if the primary node fails, data is fully restored from the transaction log, resulting in zero data loss. This difference means MemoryDB can be used as a primary database. The traditional two-tier 'RDS + ElastiCache' architecture can potentially be consolidated into a single MemoryDB tier, simplifying the architecture and improving latency simultaneously. However, write latency is lower with ElastiCache (MemoryDB adds a few milliseconds due to synchronous transaction log writes), so ElastiCache remains the better choice for cache use cases where write performance is the top priority.
Usage Patterns as a Primary Database
Typical patterns for using MemoryDB as a primary database include session stores, leaderboards, real-time inventory management, and shopping carts. These workloads require fast reads and writes, their data structures fit Redis data types well, and they demand data durability. For session stores, migrating session data previously stored in DynamoDB or RDS to MemoryDB can reduce read latency from milliseconds to microseconds. For leaderboards, Sorted Sets enable score updates and top-N retrieval in O(log N) time, supporting real-time ranking of millions of users in gaming leaderboards or e-commerce sales rankings. That said, there are cases where MemoryDB is not the right fit. Workloads requiring complex queries (JOINs, aggregations, subqueries) are better served by relational databases. Also, when data volume exceeds available memory, costs escalate rapidly, so a practical design stores only hot data in MemoryDB while offloading cold data to DynamoDB or S3. For a deeper understanding of in-memory database design, books on Redis (Amazon) are a great resource.
Cluster Design and Cost Optimization
MemoryDB clusters are composed of shards and replicas. The number of shards is determined by data volume and write throughput requirements, while the number of replicas per shard is determined by read throughput and availability requirements. For production environments, a minimum of 2 shards with 1 replica each (4 nodes total) is recommended. The latest node type is db.r7g (Graviton3), delivering up to 20% better performance over db.r6g. When selecting memory size, you need to account for Redis memory overhead (approximately 1.5-2x the data size). For example, storing 10 GB of data requires a node type with 15-20 GB of memory. For cost optimization, Reserved Nodes are highly effective - 1-year reservations save approximately 30%, and 3-year reservations save approximately 50%. Data compression is not supported in MemoryDB, so you either compress on the application side before storing or optimize the data model to reduce memory usage. The Hash data type is more memory-efficient than individual String keys when the field count is small enough for ziplist encoding to apply.