Amazon MemoryDB for Redis - Designing and Using a Durable In-Memory Database
Learn how to use MemoryDB as a primary database with Multi-AZ durability, including when to choose it over ElastiCache and practical usage patterns for in-memory workloads.
Differences Between MemoryDB and ElastiCache
MemoryDB for Redis is a Redis-compatible in-memory database, and the biggest difference from ElastiCache is data durability. ElastiCache is designed as a cache, meaning data can be lost during node failures. MemoryDB synchronously replicates its transaction log across multiple Availability Zones, so data is preserved even after node failures or process restarts. This durability allows MemoryDB to be used as a primary database rather than just a cache. It is ideal for workloads that require both data persistence and low latency, such as session stores, user profiles, leaderboards, and shopping carts.
Architecture and Performance
A MemoryDB cluster consists of shards, each containing a primary node and read replicas. Writes are handled by the primary node, and the client receives a response only after the transaction log has been synchronously replicated across Multi-AZ. Reads can be distributed across read replicas (up to 5 per shard), achieving microsecond latency. Write latency is slightly higher than ElastiCache due to synchronous transaction log replication, typically in the single-digit millisecond range. Write throughput scales horizontally by adding more shards, and a cluster can hold up to 500 nodes with hundreds of terabytes of data.
Using MemoryDB as a Primary Database
Using MemoryDB as a primary database lets you consolidate the traditional two-tier architecture of RDB + ElastiCache into a single MemoryDB layer. This eliminates cache invalidation logic, cache-database consistency management, and the operational overhead of running two separate services. However, MemoryDB does not support relational queries (JOINs, aggregations), so it is limited to workloads whose data models can be expressed using Redis data structures. For complex queries, an effective approach is to use MemoryDB as the real-time access layer while syncing data to Redshift or Athena for analytics. You can also find practical insights on MemoryDB in related books on Amazon.
MemoryDB Pricing
MemoryDB pricing consists of per-node hourly charges and data transfer fees. A db.r7g.large node costs approximately $0.337 per hour (about $243 per month). Compared to an equivalent ElastiCache node (cache.r7g.large at about $0.252/hour), it is roughly 34% more expensive, but Multi-AZ durability is included by default. Reserved nodes offer discounts of up to 55%. Choose MemoryDB when using it as a primary database, and ElastiCache for cache-only use cases, balancing cost against durability requirements.
Summary
MemoryDB is an in-memory database that combines Redis's low latency with data durability. It can serve as a primary database rather than just a cache, simplifying the traditional two-tier RDB + cache architecture. It is the best choice for workloads where the data model fits Redis data structures and both low latency and durability are required.