Skip to content
ElastiCache for Redis/Valkey
Sub-page 3 of 9
Cost & billing mechanics · Free

Choosing Valkey Over Redis OSS

Decision drivers
  • Whether any current or planned feature depends on Redis-specific modules (vector sets, RedisSearch-descended functionality, Enterprise active-active)
  • Client library's confirmed (not assumed) Valkey compatibility
  • Node-based price delta at your specific instance type/region (20% below Redis OSS is AWS's stated rate; confirm the exact current hourly figure, since AWS pricing pages do change)
  • Existing operational tooling/monitoring's Valkey support maturity

Production premise

Valkey is the community fork of Redis. It split from Redis 7.2.4 in April 2024, after Redis Ltd moved its license from BSD-3 to SSPL/RSALv2 — neither of those is a conventional open-source license, and the fork was the response. The Linux Foundation governs Valkey now, with AWS as a founding contributor.

Nothing changes at the application layer. Valkey is wire-compatible with existing Redis clients — redis-py, ioredis, Jedis — with no code changes. AWS made it the default engine for new ElastiCache and MemoryDB clusters in October 2024.

It's also cheaper. AWS prices Valkey 20% below Redis OSS on node-based deployments and 33% below on Serverless — both numbers from AWS's own Valkey launch post, not a third-party estimate.

Failure mode & inflection point

By 2026 the two engines have genuinely diverged. They're still roughly 90% command-compatible. But Redis 8 added vector sets, and Redis keeps iterating on the Redis Query Engine — the search and vector functionality descended from the old RediSearch module. Valkey's compatible modules haven't fully matched either yet.

The divergence bites on a schedule you don't control. A team that picks Valkey for the cost and licensing story, then finds it needs Redis's vector search or Redis Enterprise's active-active replication, discovers the gap mid-project. By then planning is over.

Production guardrail

Default to Valkey for new deployments unless you can name the feature that forces Redis OSS. The usual names: vector search, a particular Redis Enterprise module, a compliance tool that hasn't validated Valkey yet.

One caution from production migration reports holds up in practice: check your client library's Valkey compatibility explicitly. "Redis-compatible" does not guarantee "tested against Valkey." Verify the specific client library version itself, beyond the protocol family, before assuming a drop-in swap.

For existing Redis OSS clusters, there's no urgency — but the swap belongs on the roadmap. AWS supports an in-place engine change to Valkey without changing the endpoint, and existing Reserved Nodes carry over to the new engine automatically, so the migration itself is cheap. The pressure is financial: Redis OSS's long-term licensing trajectory is murkier than Valkey's, and since February 2026, Extended Support surcharges apply to aging Redis OSS versions. They don't apply to Valkey.