Amazon MemoryDB for Valkey

Definition

Amazon MemoryDB for Valkey is a durable, in-memory database using the Valkey engine — the Linux Foundation-maintained fork of Redis 7.x after Redis Inc.’s SSPL licensing change. MemoryDB targets primary-database use cases (session stores, gaming leaderboards, real-time feature flags) that need Redis API compatibility plus multi-AZ durability via a distributed transaction log — not merely a cache that can evict keys under pressure. AWS prices MemoryDB for Valkey substantially below MemoryDB for Redis OSS on equivalent shapes.

Valkey remains wire-protocol compatible with Redis clients, Lua scripts, and most open-source commands, but Redis Inc. commercial modules (some RediSearch/RedisJSON variants) may not port cleanly. ElastiCache for Valkey covers pure cache workloads at lower cost and lower write latency; MemoryDB pays the durability tax.

When to use it

• Session stores, leaderboards, rate limiters where rebuild-from-DB on cache miss is unacceptable.
• Redis API shops migrating off self-hosted Redis or ElastiCache for Redis to escape SSPL licensing uncertainty.
• Workloads needing Multi-AZ failover with Redis semantics and no custom Patroni-style clustering.
• Small-scale vector search via Valkey search modules where OpenSearch or S3 Vectors is overkill.

When not to use it

• Pure cache layers — ElastiCache Serverless or provisioned Valkey is cheaper and faster.
• Multi-region active-active — consider DynamoDB Global Tables, Aurora Global Database, or explicit multi-region MemoryDB Global Datastore patterns with eyes open on conflict handling.
• Heavy relational reporting — export to Aurora or Redshift instead of growing memory datasets indefinitely.

Tips

• Size MemoryDB 20–30% above ElastiCache guidance — durable write path consumes additional CPU headroom.
• Validate module dependencies before migration — replace Redis Inc. proprietary modules with Valkey equivalents or sidecar services.
• Use AWS DMS or RIOT for live replication and checksum validation rather than snapshot-only cutovers on busy keys.
• Enable TLS and ACL users per application — shared default user with ALLKEYS is an audit finding waiting to happen.
• Set maxmemory policies deliberately even on durable stores — unbounded key growth still hurts failover time and backup windows.

Gotchas

• Serious: Snapshot-only migration under write load loses keys — always validate key counts and checksums post-cutover.
• Serious: Assuming Redis Inc. modules work unchanged — production startup fails or silently drops features when modules mismatch.
• Regular: Durability ≠ backup strategy — schedule snapshots and test restores; transaction logs are not a time-travel archive.
• Regular: Large values in MemoryDB inflate failover and sync times — keep values small; offload blobs to S3.
• Regular: Global Datastore failover is not zero RPO for all clients — apps must handle brief write unavailability during promotion.

Official references

• Migrating to MemoryDB for Valkey — DMS and online migration paths.
• MemoryDB ACLs — user and command set restrictions.

Related FactualMinds content

• ElastiCache Serverless — cache-tier alternative
• Amazon DynamoDB — durable NoSQL at scale
• AWS Application Modernization
• AWS Serverless Architecture