Cloud Parts

Amazon MemoryDB

A Valkey- and Redis-compatible database that keeps everything in memory but loses no acknowledged write.

What it is
Key-value stores
Used for
Caching
Type
Managed service on AWS
Made by
Amazon Web Services
License
Proprietary (engine compatible with open-source Valkey 7.2 and Redis OSS 7, both BSD-3-Clause)
Facts checked
5 October 2026
Website

What it is

A MemoryDB cluster looks like a Valkey or Redis OSS cluster: shards inside your VPC, each with a primary node and read replicas, holding the whole dataset in RAM and speaking the same commands. The difference is where durability lives. A write isn’t acknowledged until it’s stored in a separate distributed transaction log that spans several Availability Zones. Replicas follow that log. If a primary dies, a replica takes over without losing anything the client was told succeeded, and reads from primaries stay strongly consistent across the failover. Replica reads are eventually consistent. The result is microsecond reads but single-digit-millisecond writes, on clusters of up to 500 nodes and more than 100 TB.

There is no serverless option. You pay per node-hour, plus per GB written: $0.20 per GB on Redis OSS, while Valkey clusters write the first 10 TB a month free and pay $0.04 per GB after that. Snapshots up to the cluster’s size are free. Valkey nodes cost about 30% less than Redis OSS nodes. Vector search arrived in 2024, and Multi-Region clusters replicate active-active across up to five Regions. In June 2026 ElastiCache gained the same kind of Multi-AZ transaction log for Valkey 9.0, and AWS’s MemoryDB FAQ now recommends ElastiCache for new workloads.

Why teams pick it

  • Acknowledged writes survive node and Availability Zone failures; the design targets eleven nines of durability
  • Reads from primaries are strongly consistent, even across failovers
  • Microsecond reads with Valkey and Redis data structures, so one service can replace a cache plus a database
  • Multi-Region active-active clusters with up to 99.999% availability, and vector search at no extra cost

Watch out for

  • AWS now recommends ElastiCache with durability for new workloads, and MemoryDB’s engines lag behind: Valkey 7.2.6 and MemoryDB 7.3 (December 2024), while ElastiCache runs Valkey 9.1
  • Every write waits for the Multi-AZ log, so writes take single-digit milliseconds rather than microseconds, and there is no faster asynchronous mode
  • No serverless or scale-to-zero: the smallest Valkey node, db.t4g.small, costs $0.0336 an hour (about $25 a month), and high availability needs at least two. Redis OSS clusters also pay $0.20 per GB written
  • The whole dataset lives in RAM. Data tiering to SSD on R6gd nodes helps only when about 20% of the data is hot
  • Multi-Region replication is asynchronous and eventually consistent, with automatic conflict resolution (CRDTs). It works only with Valkey and in 12 Regions

Alternatives

What all key-value stores have in common →
Amazon DynamoDBAWSAWS’s serverless key-value and document database, with single-digit-millisecond reads at any size.Amazon ElastiCacheAWSAWS’s managed Valkey, Redis OSS and Memcached, as node-based clusters or a serverless cache.FoundationDBOpen sourceAn ordered, distributed key-value store with strictly serializable ACID transactions across the whole cluster, built as a small core that other databases are layered on.MemcachedOpen sourceA simple, multithreaded in-memory key-value cache; clients hash keys across independent servers.RedisOpen sourceAn in-memory data-structure server: the default cache, and also queues, counters and leaderboards.RocksDBOpen sourceThe embedded key-value engine Facebook forked from LevelDB: an LSM tree in a C++ library that many databases and stream processors use as their storage layer.ValkeyOpen sourceThe Linux Foundation’s BSD-licensed fork of Redis 7.2.4: an in-memory key-value server that Redis clients can talk to unchanged.Workers KVCommercialCloudflare’s global key-value store that keeps data in a few central stores and caches it in the data centers where it is read, so reads are fast and writes take up to a minute to show up everywhere.

How it fits with other technologies

A two-shard Valkey cluster with a password-protected user · bash

aws memorydb create-subnet-group --subnet-group-name orders-subnets \
  --subnet-ids subnet-0a1b2c3d4e5f60718 subnet-0f1e2d3c4b5a69788

aws memorydb create-user --user-name orders-app \
  --access-string 'on ~order:* +@all' \
  --authentication-mode Type=password,Passwords="$ORDERS_DB_PASSWORD"
aws memorydb create-acl --acl-name orders-acl --user-names orders-app

# 2 shards x (1 primary + 1 replica) = 4 nodes
aws memorydb create-cluster --cluster-name orders --engine valkey \
  --node-type db.r7g.large --num-shards 2 --num-replicas-per-shard 1 \
  --acl-name orders-acl --subnet-group-name orders-subnets --tls-enabled

aws memorydb describe-clusters --cluster-name orders \
  --query 'Clusters[0].ClusterEndpoint.Address' --output text

# the reply comes back only after the write is in the Multi-AZ log
valkey-cli -c --tls -h clustercfg.orders.ab12cd.memorydb.us-east-1.amazonaws.com -p 6379 \
  --user orders-app --pass "$ORDERS_DB_PASSWORD" HSET order:1042 status paid total 59.90

ElastiCache, MemoryDB or DynamoDB?#

All three can hold an app’s key-value data. They differ in where the data lives, when a write counts as safe, and how you pay. Node prices are US East (N. Virginia) on-demand list prices for one 13.07 GiB r7g.large Valkey node, checked 2026-10-05.

ElastiCache (Valkey)MemoryDBDynamoDB
Where data livesRAM on nodes (optionally SSD with data tiering)RAM on nodes, plus a transaction log across Availability ZonesSSD-backed partitions replicated across Availability Zones
When a write counts as safeDefault: once the primary has it; replicas copy later. With durability (Valkey 9.0): synchronous or asynchronous logAlways after the Multi-AZ log commitsWritten to partitions replicated across Availability Zones
LatencyMicrosecond reads; microsecond writes, or single-digit milliseconds with synchronous durabilityMicrosecond reads, single-digit-millisecond writesSingle-digit milliseconds
Lost on a primary failureDefault: recent unreplicated writes. Asynchronous durability: up to 10 seconds. Synchronous: nothing acknowledgedNothing acknowledgedNo nodes to fail over; AWS manages replicas
BillingNode-hours, or serverless per GB-hour and ECPUNode-hours plus data written (Valkey: first 10 TB a month free)Per request (on-demand) or provisioned throughput
One `r7g.large` node$0.1752 an hour; $0.2067 with synchronous durability (+18%)$0.2163 an hourNot node-based
APIValkey, Redis OSS or Memcached commandsValkey or Redis OSS commandsDynamoDB’s own API
FitsCaches, and since 2026 durable in-memory data on new clustersExisting MemoryDB users, Multi-Region active-active in memoryLarge datasets that don’t need memory speed, with pay-per-request billing
  • Durability on ElastiCache needs a node-based cluster on Valkey 9.0 or later; serverless caches don’t offer it.
  • Both in-memory services need at least two nodes per shard for high availability, so double the node prices for a minimal highly available setup.

See it in a real stack

No architecture uses Amazon MemoryDB yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2021–2026

Teams that wanted Redis speed for their main data usually ran two systems: ElastiCache as a cache in front of a durable database such as Aurora or DynamoDB. That meant writing code to keep the two in sync and paying for both. Redis’s own persistence didn’t close the gap: its append-only file sits on one node’s disk, and replicas copy writes asynchronously, so a failover could lose data.

AWS launched MemoryDB for Redis on 19 August 2021 in four Regions. It was compatible with Redis 6.2 and scaled to 500 nodes and more than 100 TB. A 2024 SIGMOD paper by its engineers describes the design: keep Redis as the in-memory execution engine, but move durability into a separate low-latency transaction log service, so performance, availability and durability can scale independently.

Data tiering to SSD came in 2022. Vector search went GA in July 2024. In October 2024 Valkey support arrived at 30% lower prices, and Multi-Region clusters followed that December. In June 2026 ElastiCache added the same kind of Multi-AZ log for Valkey 9.0, with a choice of synchronous or asynchronous writes, and AWS began recommending ElastiCache for new workloads.

Why it’s built this way

Durability in a separate log service, not on the node
Offloading durability to a distributed transaction log let MemoryDB keep the open-source engine nearly unchanged while scaling performance, availability and durability independently.
Acknowledge a write only after it is in the Multi-AZ log
Clients must never be told a write succeeded and then lose it in a failover. The cost is single-digit-millisecond writes instead of microseconds.
Stay compatible with Redis
Supporting the same data types, commands and clients let teams point existing Redis code at MemoryDB and drop the separate cache-plus-database setup.

Timeline

  1. 2021

    Launches in August, compatible with Redis 6.2, in four Regions

  2. 2022

    Data tiering moves cold items to SSD on R6gd nodes

  3. 2024

    Vector search GA (July); Valkey support at 30% lower prices (October)

  4. 2024

    Multi-Region active-active clusters for Valkey (December)

  5. 2026

    ElastiCache adds a Multi-AZ log; AWS recommends it for new workloads

Sources23 · facts checked 5 October 2026

Improve this page on GitHub