SysPad › Lessons › database lessons › MemoryDB for Redis

How MemoryDB for Redis works

Durable, Redis-compatible in-memory database - a primary datastore, not just a cache. Writes are committed to a multi-AZ transactional log for durability. Sharded for write scale; replicas add read capacity.

Everyone knows the rule "never make a cache your only copy of the data." MemoryDB breaks that rule, safely. It’s Redis/Valkey-fast (microsecond reads) but adds a durable, multi-AZ transaction log, so it can be your actual database, not just a cache in front of one.

What you will learn

How can something in-memory be durable enough to be a primary database?
What exactly does the transaction log guarantee when a node dies?
When do you reach for MemoryDB instead of ElastiCache, and vice versa?
What’s the cost of that durability?

In-memory speed, on-disk durability

MemoryDB keeps your data in memory using the Redis/Valkey data structures, so reads are in microseconds and writes in single-digit milliseconds. The twist: every write is also recorded in a distributed transaction logspread across multiple Availability Zones before it’s acknowledged.

What the log guarantees

Because acknowledged writes are already in the multi-AZ log, losing a node, or an entire AZ, doesn’t lose data: MemoryDB promotes a replica and the log ensures consistency. You get strong durability with strongly consistent reads on the primary.

⚓ Used as the primary store for things needing both speed and safety: session and user state, leaderboards, real-time ML feature stores, message/streaming workloads.

MemoryDB vs ElastiCache

Same Redis/Valkey API, different job. ElastiCache is a cache: fastest and cheapest, but recent data can vanish on failover, so it sits in front of a real database. MemoryDB is a durable primary database you can trust as the source of truth.

Why are MemoryDB writes "milliseconds" when ElastiCache writes are sub-millisecond?

The difference is the durability step. MemoryDB must commit each write to the multi-AZ transaction log before acknowledging, which adds a little latency, single-digit milliseconds for writes. Reads, served straight from memory, stay in microseconds. You’re paying a small write-latency tax for not losing data.

The price of durability

Durability isn’t free: MemoryDB generally costs more than an equivalent ElastiCache cluster, and writes carry slightly higher latency due to the log commit.

Flashcards

How can MemoryDB be a primary database when it’s in-memory?: Every write is committed to a durable multi-AZ transaction log before acknowledgement, so acknowledged data survives node/AZ failure.
MemoryDB read and write latencies, roughly?: Microsecond reads (straight from memory), single-digit millisecond writes (the log-commit step adds a little).
Same Redis API, so when MemoryDB and when ElastiCache?: MemoryDB when it’s your durable source of truth. ElastiCache when it’s a rebuildable cache in front of another database (cheaper, sub-ms writes).
A MemoryDB AZ goes down mid-traffic. What happens to acknowledged writes?: They’re preserved. MemoryDB promotes a replica and the multi-AZ log guarantees no acknowledged write is lost.
Why might you NOT use MemoryDB even though it’s durable?: It costs more and has slightly higher write latency than ElastiCache. If you already have a durable DB and just need caching, ElastiCache is the better value.

Sources

Open the SysPad canvas · Official MemoryDB for Redis documentation