Valkey 9 GA: What the Cache Fork Means for DACH Ops Teams 18 Months After the Redis Split

The Valkey community released version 9 on April 14, 2026 – 18 months after forking from Redis 7.4 under the Linux Foundation umbrella. Valkey now has its own release history that goes beyond pure Redis compatibility. For DACH ops teams, the question is no longer if, but when and in what order to migrate.

RelatedCloud Repatriation 2026: The TCO Model  /  Broadcom-VMware channel: the provider landscape 2026

What Valkey 9 actually delivers

The release brings three categories of change. New features: RDMA transport for cluster replication in high-throughput scenarios, improved ACL handling with Active Directory integration and a reworked scripting interface that picks up Lua scripts without breaking changes. Under the hood: faster I/O threading, which in Linux Foundation benchmarks shows around 20 percent throughput gains on read-heavy workloads versus Redis 7.4. Finally, license cleanup: everything under BSD-3, no SSPL clauses.

Two points matter in the DACH enterprise context. First, the BSD license allows use cases that the SSPL of Redis 8 would have blocked in internal approvals – especially in heavily regulated industries such as banking and healthcare. Second, managed availability on AWS: ElastiCache for Valkey brings up to 33 percent price advantage over ElastiCache for Redis OSS. For teams running double-digit cache clusters, that quickly adds up to five-figure annual savings.

Valkey 9 versus Redis 8 side by side

The two stacks run in parallel in 2026. Teams that choose between them rarely do so on purely technical grounds – most of the time it is licensing and commercial terms. The differences at a glance:

What the migration actually costs

For existing Redis clusters, the move to Valkey is, in most cases, a rolling replacement exercise. The data stays compatible, persistence files (RDB, AOF) can be reused without export/import. In practice this means: reconfigure replication topology, swap node by node, leave the client configuration alone. For typical 3-node setups the effort is in the range of a few person-days – the real work sits in rebuilding monitoring and alert rules that expect Redis-specific metric names.

The interesting decision is no longer Valkey versus Redis. It is Valkey versus Redis Stack capabilities that are deliberately not carried over into the OSS release. Anyone using Bloom filters, graphs or time series has to check which Valkey modules or alternatives fit.

The point where it gets uncomfortable is the commercial Redis Stack modules: RedisGraph, RedisTimeSeries, RedisBloom and RediSearch. Teams using them in production currently find either community alternatives in varying states of maturity inside Valkey, or have to move to external services. The Linux Foundation has announced that Valkey Modules will have a stable extension ecosystem by Q3 2026 – until then, migrating these use cases is the actual project, not swapping out the cache itself.

Who should switch

Three groups have a clear business case in 2026. First, companies in regulated industries where the SSPL license stops internal OSS approvals – banks, insurers, healthcare KRITIS. Second, AWS customers with large cache clusters where the 33 percent price advantage becomes material. Third, teams that build out of the open-source ecosystem and depend on long-term community support.

For everyone else: the migration is not a fire drill. Anyone running Redis 7.2 or 7.4 in a stable managed service setup does not have to jump immediately. The right moment is the next bigger infrastructure overhaul or the next contract negotiation window with the cloud provider. Valkey 9 is available now – but spinning up a full parallel operation just to try it out is rarely worth the effort.

Frequently Asked Questions

Does my existing Redis client work with Valkey 9 without changes?

Yes, as long as the client does not rely on Redis 8 extensions. The wire protocol is identical, standard commands are backward compatible. Spring Data, Node-Redis, redis-py, go-redis and Jedis switch over without code changes – only the connection URL points somewhere else.

What happens to RedisSearch, RedisGraph, RedisTimeSeries and RedisBloom?

These stack modules are Redis Inc. proprietary and do not run on Valkey. The Linux Foundation is working on Valkey Modules for vector, search and time series – maturity varies. Teams relying on these modules in production should plan the migration as a separate sub-project, not as a cache swap.

Does AWS ElastiCache for Valkey really pay off financially?

On smaller single-node caches, the absolute amount stays manageable. The 33 percent price advantage becomes material on multi-AZ clusters with multiple r7g or r7gd instances. A typical 6-node cluster on r7g.large saves a low five-figure sum per year – enough to justify an internal migration.

Are there compliance arguments in favor of Valkey in DACH audits?

Yes. BSD-3 is OSI-compliant open source, the SSPL of Redis 8 is not. In internal OSS committees at banks, insurers and public authorities, Redis 8 falls through the SSPL filter while Valkey passes it. Teams that depend on an internal OSS policy have fewer debates with Valkey.

Cover image source: Pexels / panumas nikhomkhai (px:1148820)