In March 2024, Redis Ltd. moved the project from its permissive BSD-3-Clause license to a dual-license model combining the Server Side Public License (SSPL) and the Redis Source Available License v2 (RSALv2). The Open Source Initiative does not recognise the SSPL as an open source license, and RSALv2 carries explicit restrictions for companies offering Redis as part of commercial caching or streaming services. For infrastructure teams running managed Redis at scale, that was not an abstract legal concern — it was a procurement problem.

Eight days after that announcement, the Linux Foundation launched Valkey: a fork of Redis OSS 7.2.4, BSD-3-Clause licensed, governed by a Technical Steering Committee with no single vendor in control. AWS, Google, Oracle, Ericsson, and a growing list of cloud and open-source companies backed it immediately. By early 2025 the project had nearly 50 contributing companies, 19.8K GitHub stars, and more than 5 million Docker pulls. In mid-2026 it is shipping the 9.1.x line while maintaining an 8.1.x branch.

Redis Ltd. partially walked back the change in May 2025 when Redis 8.0 introduced AGPLv3 as a third licensing option, influenced by the return of original Redis author Salvatore Sanfilippo. AGPLv3 is a recognised open-source license, but it is strong copyleft: any software that interacts with a Redis 8 instance over a network may carry licence obligations that legal teams at banks, insurers, and defence contractors will scrutinise carefully. Redis Software 7.2 reached end-of-life on 28 February 2026, so the clock has run out on the last fully permissive Redis release.

The practical result is that two credible, production-ready options exist: managed Redis 8.x under its tri-license model, and managed Valkey under a license that has not changed and cannot be changed unilaterally by any single vendor. The decision between them is not primarily about features — it is about governance risk, threading architecture, and cost.

Protocol compatibility: the migration story is short

Valkey maintains full wire-protocol compatibility with Redis. Existing RESP2 and RESP3 clients, Lua scripts, and Redis Cluster topologies work without modification. For session caching specifically, where workloads are dominated by GET, SET, EXPIRE, and DEL operations, the surface area for incompatibility is minimal. The migration path from a managed Redis 7.x instance to a managed Valkey instance is, in most cases, a connection string change followed by a rolling restart.

Where you should expect more careful review: Redis modules (RedisSearch, RedisJSON, RedisTimeSeries). These are proprietary to Redis Ltd. and do not carry over to Valkey. The Valkey ecosystem has community equivalents in development, but if your session layer is entangled with module-dependent features, that dependency should be resolved before migration, not during it.

Threading architecture and what it means for session throughput

Redis historically uses a single-threaded event loop for command processing. That model is predictable and cache-friendly, but it caps single-instance throughput on modern multi-core hardware. Valkey 8.0 introduced a redesigned threading model that allows parallel I/O operations while maintaining data safety. The result is better utilisation of multi-core instances without requiring application-level sharding to saturate available CPU.

For session caching, the bottleneck is almost never compute — it is I/O fan-out under concurrent connection load. Valkey’s I/O threading directly addresses the cases where a single-threaded Redis instance starts queuing connections at peak traffic.

This matters most for workloads with high connection concurrency: login storms, token validation at API gateways, or cart-session reads on a flash-sale event. If your managed Redis instance is already sized generously and latency is well within SLA, the threading difference will not be visible. If you are scaling horizontally to work around single-instance throughput limits, Valkey’s architecture is worth benchmarking against your actual traffic shape before committing to more shards.

Cost differential at the managed layer

The pricing gap between managed Valkey and managed Redis is not marginal. On AWS ElastiCache, node-based Valkey instances are priced approximately 20% lower than equivalent Redis nodes; the serverless tier is 33% lower. Google Cloud Memorystore shows a similar 20% reduction for Valkey versus Redis. Samsung Electronics reported roughly 30% infrastructure cost savings after migrating to ElastiCache for Valkey at global scale.

These figures are point-in-time and will shift, but the direction reflects something structural: cloud providers are not subsidising Valkey out of goodwill. They avoided the licence friction that would arise from distributing Redis under SSPL or RSALv2 as a managed service, and they are passing part of that margin back to customers. Expect the gap to persist as long as the licensing asymmetry does.

Governance risk: the question managed Redis cannot fully answer

The strongest argument for Valkey is not performance or price — it is governance. The Linux Foundation’s Technical Steering Committee model means that no single company can repeat what Redis Ltd. did in March 2024. The BSD-3-Clause license is locked in at the foundation level. For European infrastructure teams operating under procurement frameworks that require open-source licence stability, that structural guarantee is worth more than any benchmark.

Redis 8’s AGPLv3 option restores OSI recognition, but it does not restore governance neutrality. Redis Ltd. retains control of the project and can modify terms again. Teams that moved to Valkey after the 2024 announcement are not being paranoid — they are applying standard vendor-risk reasoning to a dependency that sits in every request path.

When managed Redis 8 still makes sense

There are legitimate reasons to stay on managed Redis. If your stack depends on Redis modules with no viable Valkey equivalent, migration cost may outweigh licence risk for now. If your organisation has an existing enterprise support contract with Redis Ltd. that covers Redis 8, the commercial relationship may provide indemnification that the open-source path does not. And if your legal team has reviewed AGPLv3 obligations and concluded they are acceptable for your network topology, Redis 8 is a technically capable product.

The case for staying is narrower than it was in 2023, but it is not zero. The decision should be made on a specific dependency inventory, not on inertia.

Choosing confidently: a practical framework

  • Audit module dependencies first. If you use RedisSearch, RedisJSON, or RedisTimeSeries, map those features before evaluating Valkey. Everything else is straightforward.
  • Benchmark against your connection profile, not synthetic workloads. Valkey’s threading advantage appears under high-concurrency I/O; single-connection latency differences are negligible.
  • Run a parallel environment for at least two weeks. Session caching failures surface under real traffic patterns, not load tests. Use feature flags or weighted routing to shift a percentage of sessions to the new instance before full cutover.
  • Lock your client library version before migrating. Most Redis client libraries added explicit Valkey support in 2024 and 2025; verify your version handles both server types cleanly.
  • Price on the managed tier you actually need. Serverless pricing is attractive for variable workloads; node-based pricing wins for sustained, predictable session volume.

We manage Redis and Valkey instances for customers across finance, healthcare, and e-commerce through DIVERSITY’s managed cache offering, and the pattern we see consistently is that teams running session caching as a pure key-value workload (no modules, no Lua-heavy pipelines) migrate to Valkey in a single maintenance window with no application changes. The IT Consulting engagements that take longer are almost always module dependency audits, not the migration itself.

The managed Redis vs Valkey decision has a clear default answer for most new deployments in 2026: start with Valkey, keep the BSD-3-Clause guarantee, and spend the cost savings on capacity rather than licence negotiation. The only reason to choose otherwise is a specific technical dependency that Valkey does not yet cover — and that list is shrinking with every release.