Valkey 8.1 has widened its lead over Redis where it counts for infrastructure teams: memory and cost. The Linux Foundation fork, born when Redis abandoned its permissive open-source license in 2024, now uses roughly 28% less memory than Redis on comparable workloads, and cloud providers are pricing managed Valkey about 33% below managed Redis. With Redis Software 7.2 reaching end of life, this stops being a licensing debate and becomes a concrete question every platform team has to answer this year. Our take: for the majority of cache and queue workloads, Valkey is now the default, and the burden of proof has flipped onto staying with Redis.

  • Valkey 8.1 reports about 28% lower memory usage than Redis on similar workloads, a direct hit to the biggest line item for an in-memory store.
  • Managed Valkey lands roughly 33% cheaper than managed Redis across major cloud providers.
  • Redis Software 7.2 end of life forces a decision: pay to upgrade, or migrate.
  • Valkey stays BSD-licensed under the Linux Foundation, the permissive terms Redis walked away from.
Valkey 8.1 advantage over Redis (approx.)Memory used ~28% lower, Managed price ~33% lower, Wire protocol compatibleValkey 8.1 advantage over Redis (approx.)Memory used~28% lowerManaged price~33% lowerWire protocolcompatiblegenztech.blog
Fig 1 · why teams switch Valkey 8.1 versus Redis on the two numbers that drive infrastructure bills.

What changed in Valkey 8.1?

The headline is efficiency. Valkey 8.1 continues the fork's push on memory layout and threading, and the practical result is that the same dataset fits in a smaller instance. Because in-memory stores are billed on RAM, a 28% memory reduction is not a benchmark curiosity; it is a smaller node, a lower bill, and more headroom before the next shard. Valkey has kept wire-protocol compatibility with Redis, so most clients and most application code do not change.

RelatedNode.js 20 Hits End of Life July 9: What to Do Now

Why did this fork happen at all?

In 2024 Redis relicensed away from the permissive BSD terms that the ecosystem was built on, moving to source-available licenses aimed at large cloud resellers. The community response was Valkey, adopted by the Linux Foundation and backed by AWS, Google Cloud and others. That governance is the quiet reason Valkey keeps winning: cloud providers have every incentive to make the permissively licensed option cheaper and better, because they can ship it without license friction.

What is the real migration cost?

For most teams the switch is close to a drop-in, because Valkey speaks the Redis protocol and reads Redis data structures. The friction is in the edges: modules and enterprise-only features that Redis ships and Valkey does not, plus tooling and dashboards that assume Redis branding. The honest framing is that a plain cache or session store migrates in an afternoon, while a deployment leaning on proprietary Redis modules needs a real plan. The 7.2 end-of-life clock is what turns "someday" into "this quarter."

DimensionRedisValkey 8.1
LicenseSource-available (SSPL/RSAL)BSD (permissive)
GovernanceRedis Ltd.Linux Foundation
MemoryBaseline~28% lower
Managed priceBaseline~33% lower
ProtocolRedisRedis-compatible

Who should stay on Redis?

Teams deep in Redis Enterprise features, active-active geo-replication, specific modules, or vendor support contracts, still have a real case to stay, and Redis has kept shipping. But for the long tail of caching, rate limiting, session storage and job queues, the calculus now favors the fork. When the compatible option is cheaper, leaner and permissively licensed, inertia is the only thing keeping a plain workload on Redis.

RelatedRust 1.96 Finally Makes Range Types Copy

How does this fit the wider database shift?

Valkey's rise is one instance of a pattern playing out across the data layer in 2026: permissive open source, backed by cloud providers and a foundation, reclaiming ground from single-vendor source-available licenses. It rhymes with the OpenSearch fork of Elasticsearch and the broader move to community governance whenever a popular project relicenses. The lesson infrastructure teams have internalized is that betting a core dependency on one company's licensing goodwill is a risk, and a foundation-governed fork with real cloud backing is the hedge. There is also a technical tailwind. In-memory stores are one of the most cost-sensitive pieces of a stack, because they are billed on RAM rather than storage, so a double-digit memory improvement compounds directly into the monthly bill at scale.

What is the bottom line for teams?

Run the numbers on your own workload before deciding, but start from the assumption that Valkey is the default. For a cache, a session store, a rate limiter or a job queue, the migration is close to painless and the savings are real in both memory and managed price. Reserve Redis for deployments that genuinely lean on its proprietary modules, enterprise support, or specific replication features. The end-of-life clock on Redis 7.2 is what turns this from a philosophical debate into a line item on this quarter's roadmap. And because Valkey holds the wire protocol steady, the switch rarely touches application code, which is what makes the migration an operations task rather than an engineering project. The teams that move early bank the savings sooner and avoid a rushed end-of-life scramble later.

What to watch · 2026
  • Provider defaults. Once a cloud makes Valkey the default new-cluster choice, adoption compounds.
  • Module parity. The gap that keeps teams on Redis is proprietary modules; watch the open equivalents mature.
  • The 7.2 deadline. End of life is the forcing function that converts intent into migrations.
Primary sources

Original analysis by GenZTech. Primary source: Valkey Project.