ElastiCache Valkey vs Redis OSS vs Memcached: Which Engine to Choose in 2026

For a new Amazon ElastiCache cluster in 2026, Valkey is the sensible default engine. It keeps the Redis OSS data model and commands, AWS prices it lowest, and new ElastiCache features such as durability arrive only on Valkey. Memcached still fits one narrow job well: a simple, multithreaded object cache that grows and shrinks by adding or removing nodes. Redis OSS mostly makes sense for an existing cluster that is not ready to move yet.

The comparison below combines the AWS documentation, checked on 20 October 2026, with my own same-node runs of Redis 7.1 and Valkey 7.2, 8.2, and 9.0. Memcached was not part of those runs, so everything about Memcached here comes from documentation, not measurement.

Where the three engines really differ

AWS describes all three engines as in-memory key-value stores that look similar on the surface. In practice the difference is less about speed and more about what happens to your data, and to your cluster, when something changes.

So the real decision is usually not "which engine is fastest". It is whether the cache can lose its contents without harm, and whether the application needs anything richer than get and set.

What my same-node runs show

I ran Redis 7.1 and three Valkey versions through the same ElastiCache test lab on the same day: one-hour runs on a single cache.t4g.micro node without cluster mode, with three load-generator tasks each. All four runs reached 100% memory and started evicting keys between 31 and 40 minutes in. These are results for a full, evicting cache, not for a working set that fits.

Valkey 7.2 had the highest throughput, 5.9% above Redis 7.1, and the lowest average latency. Valkey 8.2 and 9.0 were 6.0% and 4.3% below Redis 7.1 in throughput. Valkey 9.0 had the steadiest throughput and the lowest peak engine CPU, but also the lowest hit rate. No engine version wins every column. The full t4g.micro comparison walks through each metric.

In these particular t4g.micro runs, each Valkey version's average throughput was within 6.0% of Redis 7.1, and the highest result was 12.6% above the lowest. Each engine version was tested once, so the results cannot establish a reliable ranking or rule out a larger penalty in other runs. On three repeated Valkey 9.0 runs on cache.t3.small, average throughput differed by 49.6% between the lowest and highest run. That spread shows why repeat runs matter for that node and workload. It does not establish expected variation on t4g.micro.

When Memcached is still the right choice

AWS recommends Memcached when you need the simplest model possible, want to run large nodes with multiple cores or threads, need to add and remove nodes as demand changes, and need to cache objects. That is a real use case: a look-aside cache in front of a database, where every value can be rebuilt from the source.

The trade-off is in the same table. Memcached on ElastiCache has no replication, no automatic failover, and no backup and restore on node-based clusters. So a failed node takes its part of the cache with it, and the application has to live with a colder cache while that data is loaded again. If that is acceptable, the simplicity is an advantage, not a limitation.

I have not measured Memcached in my lab, so I make no throughput or latency claim for it here.

Why Valkey rather than Redis OSS

For ElastiCache users, three reasons now point the same way:

• Licensing. Valkey is BSD-licensed and stewarded by the Linux Foundation. Redis 7.2 and earlier use the permissive BSD 3-Clause license. Upstream Redis 8 and later offer AGPLv3, an OSI-approved copyleft open-source license, alongside two source-available options. ElastiCache supports Redis OSS 7.1 and earlier. Upstream Redis 8 is not an ElastiCache Redis OSS engine version.
• Price. AWS lists Valkey at a 20% lower node-based price and a 33% lower Serverless price than the other supported engines.
• Features. New ElastiCache capabilities come as Valkey versions: memory efficiency in 8.0, Bloom filters in 8.1, vector search in 8.2, and full-text search, hash field expiration, and durability in 9.0.

My runs add one practical point: the same memtier workload ran on Redis 7.1 and on all three Valkey versions, and each Valkey version's average throughput stayed within 6.0% of Redis 7.1.

Moving an existing Redis OSS cluster to Valkey

AWS describes Valkey as a drop-in replacement for Redis OSS 7 and supports an in-place cross-engine upgrade from the console, the CLI, or the API. The points worth knowing before you start:

• The endpoint DNS name stays the same. On node-based clusters, the node IP addresses change.
• From Redis OSS 5.0.6 or later, reads stay available and writes pause only during a failover of a few seconds. Older versions can see 30 to 60 seconds of failover during DNS propagation.
• A custom parameter group needs a Valkey counterpart with the same static parameter values.
• A single-node cluster without cluster mode must first be added to a replication group.
• Upgrading an existing non-durable cluster to Valkey 9.0 or later cannot enable durability. That requires a new cluster with durability selected at creation.
• The way back is narrow: ElastiCache supports a rollback only from Valkey 7.2 to Redis OSS 7.1.

For me, that last point sets the order. If you want a way back, move to Valkey 7.2 first, let the application run on it, and only then upgrade to a newer Valkey version. Engine upgrades cannot be reversed after that.

Durability changes the cache-only assumption

Valkey 9.0 on ElastiCache can persist writes to a Multi-AZ transactional log. With synchronous writes, acknowledged writes are not lost in a failure, at the cost of single-digit millisecond write latency and an 18% higher node-hour price. With asynchronous writes, write latency stays the same as without durability and there is no extra cost, but up to the last 10 seconds of writes can be lost in a failure. Memcached and Redis OSS do not have this ElastiCache durability option.

AWS requires a supported node family: R8g, R7g or R6g, M8g, M7g or M6g, C8gn, or C7gn. Durability also requires cluster mode enabled and Multi-AZ with at least one replica per shard. The tested T4g family is excluded. Durability must be selected when the cluster is created. Upgrading an existing non-durable cluster to Valkey 9.0 or later cannot enable it.

That turns part of the old "ElastiCache or MemoryDB" question into an ElastiCache configuration choice. I have not measured durability yet. My separate MemoryDB test lab is being built for that comparison.

What this comparison does not cover

• Memcached performance. It was not measured.
• Larger nodes. The M5, M6g, and M7g, R5, R6g, and R7g, and M7g, R7g, and C7gn analyses cover Valkey 9.0 on general-purpose, memory-optimized, and network-optimized nodes. The T3 vs T4g comparison and the Graviton vs Intel benchmark cover node choice inside one engine.
• ElastiCache Serverless.
• Durability performance.

Short answers

Is Valkey a drop-in replacement for Redis OSS on ElastiCache? AWS describes it as a drop-in replacement for Redis OSS 7 and supports an in-place upgrade. In my t4g.micro runs, the same workload ran on Redis 7.1 and on Valkey 7.2, 8.2, and 9.0.

Is Memcached faster than Valkey? Not measured here. AWS positions Memcached for large multithreaded nodes, but speed should be tested with your own workload, not assumed from the engine name.

Which ElastiCache engine is cheapest? AWS prices Valkey 20% lower than the other engines on node-based clusters and 33% lower on Serverless. Check the pricing page for your region before planning.