Amazon MemoryDB vs ElastiCache
Both are AWS-managed, in-memory, Valkey- and Redis OSS-compatible services. The difference is what they are for: MemoryDB is a durable primary database, ElastiCache is a cache. As of June 2026 ElastiCache for Valkey can be durable too, so the line is blurrier than it used to be.
MemoryDB or ElastiCache? The 15-second answer
Use MemoryDB when the in-memory store is your system of record: it persists every write to a Multi-AZ transactional log, gives 99.99% availability with no data loss across failovers, and needs no separate database behind it. Use ElastiCache when you want a cache in front of an existing database (DynamoDB, Aurora, RDS): cheaper per node, and data can be repopulated from the source if lost. Since 2 June 2026, ElastiCache for Valkey can also be durable, so the split is now durable database (MemoryDB) vs optionally-durable cache tier (ElastiCache).
The core difference: database vs cache
Amazon MemoryDB is a durable in-memory database. It keeps your whole dataset in memory for microsecond-latency reads, but it also persists every write to a distributed Multi-AZ transactional log before acknowledging it, which is what lets it act as a system of record. Only data committed to that log is visible, so clients can read their own writes from a primary even across node failures, and MemoryDB advertises 99.99% availability with near-instantaneous recovery and no data loss.
Amazon ElastiCache was built as the opposite: a cache tier. The assumption is that the source of truth lives elsewhere (DynamoDB, Aurora, RDS, or your own datastore) and ElastiCache holds a hot copy for speed. If an ElastiCache node fails and its data is gone, the application repopulates the cache from the primary. That assumption is exactly why a cache is cheaper: it does not have to guarantee the data survives.
This is the decision in one sentence: if the in-memory store is the database, you want MemoryDB; if the in-memory store is a fast layer in front of a database, you want ElastiCache. Both speak the same wire protocol (Valkey / Redis OSS), so your client code is largely the same either way.
The June 2026 twist: ElastiCache for Valkey can now be durable
On 2 June 2026 AWS added a durability option to ElastiCache for Valkey, backed by the same kind of Multi-AZ transactional log that powers MemoryDB. It ships in two modes. Synchronous writes make every acknowledged write durable across at least two Availability Zones with single-digit-millisecond write latency, designed for zero data loss. Asynchronous writes keep microsecond write latency at no extra cost, but up to 10 seconds of acknowledged writes may be lost in the unlikely event of a failure.
That collapses the old, simple story ("MemoryDB is durable, ElastiCache is not"). The distinction now is architectural intent rather than raw capability: MemoryDB is a purpose-built durable primary database with strongly consistent primaries and a data-written pricing model, while ElastiCache for Valkey is a cache service that can optionally turn on durability. If you were reaching for MemoryDB purely to avoid losing cache data on a failover, ElastiCache for Valkey in synchronous mode may now cover you at a lower price. If you want a single managed store that genuinely replaces a database, MemoryDB is still the cleaner answer.
Side by side (2026)
| Aspect | Amazon MemoryDB | Amazon ElastiCache |
|---|---|---|
| Primary role | Durable in-memory database (system of record) | Cache in front of a primary database |
| Durability | Always durable: Multi-AZ transactional log | Ephemeral by default; Valkey engine adds optional Multi-AZ durability (Jun 2026) |
| Consistency | Strongly consistent primaries | Eventual on replicas; sync durable mode available on Valkey |
| Engines | Valkey + Redis OSS | Valkey + Redis OSS + Memcached |
| Read latency | Microseconds | Microseconds |
| Write latency | Single-digit milliseconds | Microseconds (async) / single-digit ms (sync durable) |
| Node price (r7g.xlarge, us-east-1) | ~$0.43/hr on-demand | ~$0.35/hr Valkey, ~$0.44/hr Redis OSS |
| Data-written charge | $0.20/GB Redis OSS; Valkey free to 10 TB/mo then $0.04/GB | None |
| Snapshot storage | Free to 100% cluster storage, then $0.021/GB-mo | Free to 100% reserved memory, then $0.085/GB-mo |
| Best for | Durable queues, financial balances, session-of-record | Read-through / write-through cache, page cache, hot lookups |
Sources: MemoryDB pricing, MemoryDB for Valkey (Oct 2024), ElastiCache durability (Jun 2026), ElastiCache pricing. Verified July 2026; confirm region pricing before procurement.
The cost gap is smaller than it used to be
MemoryDB has always cost more than ElastiCache, and the reason is the data-written charge. On MemoryDB for Redis OSS you pay $0.20 per GB written, on top of node hours, because every write has to be committed durably to the transactional log across Availability Zones. For a write-heavy workload that charge can dwarf the node cost.
MemoryDB for Valkey, announced 8 October 2024, changed the maths. It lists 30% cheaper than MemoryDB for Redis OSS, and it includes data-written free up to 10 TB per month, with anything above that billed at $0.04/GB (80% lower than the Redis OSS rate). For most workloads under 10 TB of monthly writes, the data-written charge effectively disappears, leaving node hours (db.r7g.xlarge around $0.43/hour on-demand) as the main cost. Snapshot storage is free up to 100% of the cluster's storage, then $0.021/GB-month.
ElastiCache remains cheaper for a pure cache because it has no data-written charge at all and its Valkey node rate is lower (around $0.35/hour on cache.r7g.xlarge). Backup storage is free up to 100% of reserved memory, then $0.085/GB-month. Both services offer Reserved Nodes (1-year and 3-year, all / partial / no upfront) at up to 55% off on-demand for stable workloads. Full ElastiCache node maths is on the ElastiCache Redis vs Memcached page.
Which one for your workload
Pick MemoryDB
The in-memory store is your database of record and there is no separate primary behind it: durable queues, in-game currency and inventory, financial balances, or a session store where a lost session is a real incident. You want strong consistency and 99.99% availability from a single managed service.
Pick ElastiCache for Valkey
You have an existing primary database and want a hot cache in front of it: read-through / write-through caching, full-page cache, expensive-query results, rate-limit counters you can rebuild. It is the cheapest of the two, and if you occasionally need durability you can now switch on the synchronous Multi-AZ mode instead of moving to MemoryDB.
Either could work
Leaderboards and session stores sit on the boundary. If a rare data loss is tolerable and cost matters, ElastiCache. If the data is authoritative and must survive failures, MemoryDB, or ElastiCache for Valkey in synchronous durable mode. Benchmark both with your write volume, because the MemoryDB data-written charge only bites above 10 TB/month on Valkey.
FAQ
What is the difference between Amazon MemoryDB and ElastiCache?
Amazon MemoryDB is a durable, in-memory primary database: it stores your entire dataset in memory but persists every write to a Multi-AZ transactional log, so it can be your system of record with no separate database behind it. Amazon ElastiCache is traditionally a cache that sits in front of a primary database (DynamoDB, RDS, Aurora) and can be repopulated from that source if data is lost. Both are Valkey- and Redis OSS-compatible. The practical split: MemoryDB when you want one durable store that is both the cache and the database of record; ElastiCache when you want a cheaper cache tier in front of an existing database.
Is MemoryDB more expensive than ElastiCache?
Historically yes, mainly because MemoryDB charges for data written ($0.20/GB on Redis OSS) on top of node hours, which pays for the Multi-AZ durability guarantee. But MemoryDB for Valkey (October 2024) removed most of that gap: it is priced 30% lower than MemoryDB for Redis OSS and includes data-written free up to 10 TB/month, with any overage at $0.04/GB (80% lower than Redis OSS). Node-hour rates for MemoryDB (for example db.r7g.xlarge around $0.43/hour on-demand) are close to ElastiCache node rates. ElastiCache for Valkey node clusters are still the cheapest option for a pure cache, roughly $0.35/hour on cache.r7g.xlarge, because a cache does not have to pay for durable persistence.
Can Amazon ElastiCache be durable like MemoryDB?
As of 2 June 2026, yes for the Valkey engine. Amazon ElastiCache for Valkey added a durability option backed by the same kind of Multi-AZ transactional log MemoryDB uses. It offers two modes: synchronous writes (every acknowledged write is durable across at least two Availability Zones, single-digit-millisecond write latency, zero data loss) and asynchronous writes (microsecond write latency but up to 10 seconds of acknowledged writes may be lost in a failure). This narrows the historical gap, but MemoryDB remains the purpose-built durable primary database with strongly consistent primaries; ElastiCache durability is an add-on to a cache-first service.
Should I use MemoryDB or ElastiCache for a session store or leaderboard?
If losing the data on a rare failover is acceptable and you already have a primary database, ElastiCache is cheaper and sufficient. If the session store or leaderboard is the system of record and data loss is unacceptable (financial balances, in-game currency, durable queues), MemoryDB gives you strong consistency and Multi-AZ durability without bolting on a separate database. Since June 2026 you can also get durability from ElastiCache for Valkey in synchronous mode, so the choice is now more about whether you want a dedicated durable database (MemoryDB) or a durable cache tier (ElastiCache for Valkey).
Does MemoryDB support Valkey?
Yes. Amazon MemoryDB for Valkey was announced on 8 October 2024 and is both Valkey- and Redis OSS-compatible. Valkey is the recommended and cheaper engine: 30% lower list price than MemoryDB for Redis OSS, plus the 10 TB/month free data-written allowance. Existing Redis OSS MemoryDB clusters keep running, but Valkey is the default choice for new MemoryDB clusters.