Let’s be clear from the beginning, comparing those two can be seen like comparing apples to oranges. Even though both are Redis API compatible, they support different usage patterns.
Amazon ElastiCache for Redis
Amazon ElastiCache for Redis is a manged version of Redis – in-memory data store used mainly for caching. It can be placed in front of a database, like DynamoDB or RDS, to speed reads operations. Two common caching strategies are lazy loading and write-through.
In this other example you can read how to integrate Amazon DocumentDB and Amazon ElastiCache to achieve microsecond response times.
MemoryDB for Redis
In other hand, MemoryDB for Redis aims to replace both cache and database in one component – provides microsecond read latency and data durability.
MemoryDB usage example
Features comparison
| Feature | ElastiCache for Redis | MemoryDB for Redis |
|---|---|---|
| Performance | Performance comparison | MemoryDB can support up to 390K read and 100K write requests per second and up to 1.3 GB/s read and 100 MB/s write throughput per node (based on internal Amazon testing on read-only and write-only workloads). |
| Latency | Microsecond latencies for both reads and writes. | Microsecond read and single-digit millisecond write latency. |
| Scalability | Vertical and horizontal scaling. Allows data sharding and read replicas. | Vertical and horizontal scaling. Allows data sharding and read replicas. |
| Availability | SLA 99.9% Multi-AZ for a failed primary node to a read replica. Replication group consists of a primary and up to 5 read replicas. Redis asynchronously replicates the data from the primary to the read replicas. | SLA 99.9% MemoryDB also supports multi-AZ availability with up to 5 replicas in different AZs. |
| Data consistency | Weakly consistent with an unbounded inconsistency window. Redis allows writes and strongly consistent reads on the primary node of each shard and eventually consistent reads from read replicas. These consistency properties are not guaranteed if a primary node fails, as writes can become lost during a failover and thus violate the consistency model. | Strong consistency on the primary node, eventual consistency reads on replica nodes. The consistency model of MemoryDB is similar to ElastiCache for Redis. However, in MemoryDB, data is not lost across failovers, allowing clients to read their writes from primaries regardless of node failures. Only data that is successfully persisted in the multi-AZ transaction log is visible. Replica nodes are still eventually consistent. |
| Failover to read replica | Automatic detection of and recovery from cache node failures. In scenarios where the primary node fails ElastCache for Redis will automatically promote an existing read replica to the primary role. Redis replication system is asynchronous: all updates to primary nodes are replicated after being committed. In the event of a failure of a primary, acknowledged updates can be lost. | MemoryDB supports lossless failover. When a failure occurs on a primary node, MemoryDB will automatically failover and promote one of the replicas to serve as the new primary and direct write traffic to it. Additionally, MemoryDB utilizes a distributed transactional log to ensure the data on replicas is kept up-to-date, even in the event of a primary node failure. Failover typically happens in under 10 seconds for unplanned outages and typically under 200 milliseconds for planned outages. |
| Data durability | ElastCache for Redis includes an optional append-only file (AOF) feature, which persists data in a file on a primary node’s disk for durability. When this feature is enabled, the node writes all of the commands that change cache data to an append-only file. When a node is rebooted and the cache engine starts, the AOF is “replayed.” The result is a warm Redis cache with all of the data intact. AOF can’t protect against all failure scenarios. For example, if a node fails due to a hardware fault in an underlying physical server, ElastiCache provisions a new node on a different server. In this case, the AOF file is no longer available and can’t be used to recover the data. | MemoryDB stores your entire data set in memory and uses a distributed multi-AZ transactional log to provide data durability. |
| Price | Example: ondemand cache.r6g.2xlarge (8 vCPU, 52GB mem) = $0.916/h. | Data written $0.20/GB. Example: ondemand db.r6g.2xlarge (8 vCPU, 52GB mem) = $1.374/h. |
| Reserved nodes | Available. | Not available (at least not in January 2022). |
| Management | Managed service. Elasticache for Redis automates common administrative tasks such as failure detection and recovery, and software patching. Every cluster and replication group has a weekly maintenance window during which any system changes are applied. Also self-service updates are available where you can choose when to apply updates. | Managed service. MemoryDB automatically patches your cluster during maintenance windows which you specify. For some updates, MemoryDB utilizes service updates, which you can apply at any time or schedule for a future maintenance window. |
| Backup and restore | Automated and manual snapshots. | Automated and manual snapshots. |
Materials
Amazon MemoryDB for Redis – Where speed meets consistency
Before using Redis, read also interesting issue when using Spring Data Redis