Valkey: Placing the Open-Source Fork After Redis' License Change

1. The March 2024 license change: from BSD to SSPL and RSAL

Redis had been licensed under the three-clause BSD license since its creation in 2009, one of the most permissive open-source licenses in existence, which allowed commercial use and offering it as a hosted service without restriction. In March 2024, Redis Ltd announced that starting with Redis 7.4 it would switch to a dual licensing model consisting of the Server Side Public License and the newly created Redis Source Available License.

Both licenses still permit reading and modifying the source code, but noticeably restrict offering Redis as a managed cloud service by third parties, unless those third parties themselves make substantial contributions to the project. This restriction targeted mainly large cloud providers selling Redis as a managed service without meaningfully contributing to the core project, but in the eyes of many developers it also struck at the spirit of an open project.

2. Why the Linux Foundation founded Valkey as an independent fork

A few days after the announcement, a new project called Valkey formed with participation from AWS, Google Cloud, Oracle, Ericsson, and other companies, placed under the umbrella of the Linux Foundation. The Linux Foundation offers a neutral governance structure in which several competing companies can jointly work on a project, without any single company being able to unilaterally change licensing terms in the future, as happened with Redis Ltd.

The starting point was the last BSD-licensed codebase of Redis, specifically version 7.2.4, on top of which Valkey has since been developed independently. Within a few months, several Linux distributions, including Debian and Amazon Linux, along with cloud providers, adopted Valkey as the replacement for Redis in their respective package sources, quickly giving the fork broad practical traction.

3. Technical starting point and governance model of Valkey

Valkey is led by a technical steering committee made up of representatives from several participating companies, which makes decisions about the roadmap, larger architectural changes, and release cycles. This model deliberately differs from the previous structure at Redis, where a single company held final decision-making power over licensing and direction, and is meant to prevent a similar license change from happening again without community consensus.

Developers contributing to Valkey continue to follow an open contribution process on GitHub with publicly visible discussions, similar to how Redis operated before the license change. Several key developers of the original Redis project have moved to Valkey, giving the fork not only institutional backing but also deep technical knowledge of the existing codebase.

4. Current feature and compatibility status relative to Redis

Since Valkey started from the same codebase, its protocol- and command-level compatibility with Redis was practically complete at launch. Since then, both projects have developed new features independently: Valkey has pushed forward a reworked multi-threading architecture for I/O handling as well as a native hash field expire feature, while Redis Ltd is expanding its own new capabilities, such as extended vector search features, in its more proprietary Redis editions.

For the vast majority of standard use cases, particularly caching, session storage, and basic data structure operations, compatibility between the two projects remains high, since both implement the same RESP protocol and support the bulk of classic commands like GET, SET, HSET, or EXPIRE identically. For very new features introduced by either project after the fork, however, a targeted check before adoption is worthwhile.

5. Practical compatibility: clients, RDB and AOF format, RESP protocol

For application developers, the key point is that common Redis client libraries such as predis or phpredis in the PHP ecosystem work against Valkey without modification, because these libraries are written against the RESP protocol rather than a specific server implementation. The RDB snapshot format and the AOF persistence format also remained identical at launch, allowing existing datasets to be carried over from Redis to Valkey without conversion.

It remains worth checking the Redis version in use against the Valkey version, since the formats could in theory diverge over time as independent development continues. For a Magento setup using Redis primarily for full page cache, configuration cache, and sessions, this rarely affects critical functionality in practice, since Magento itself communicates through standard Redis adapters and does not depend on proprietary Redis extensions.

# Check the currently running Redis version
redis-cli INFO server | grep redis_version

# Valkey reports through the same INFO structure, with an
# additional field to distinguish itself
redis-cli INFO server | grep -E "redis_version|valkey_version"

# Back up the RDB file before migrating
redis-cli SAVE
cp /var/lib/redis/dump.rdb /backup/dump-before-valkey-migration.rdb

6. Real-world performance differences: Valkey's reworked I/O threading

The most visible technical difference between the two projects lies in how the I/O threading model has evolved. While Redis has so far mainly used I/O threads for raw reading and writing of network data, keeping actual command processing bound to a single main thread, the Valkey team reworked this model to genuinely spread more work across multiple threads in parallel, without giving up the atomicity of individual commands applications expect.

Published benchmarks from the Valkey maintainers show this results in noticeably higher throughput compared to similarly configured Redis for workloads with many concurrent connections, particularly on machines with eight or more cores. For Magento operators running very high-traffic shops, this difference can become relevant, but as with any vendor figure it should be confirmed through an own load test against the application's actual access pattern before serving as a reason to migrate.

7. Distro support: Debian, Amazon Linux, and cloud providers switch to Valkey

A meaningful signal for Valkey's practical relevance is that several major Linux distributions, including Debian from a certain version onward, have replaced the redis-server package with Valkey or added Valkey as an independent, equivalent package. Amazon Linux and several cloud providers have also switched their managed cache services to Valkey as the default engine, in some cases alongside a paid option for licensed Redis.

In practical terms, a plain apt install redis-server on newer Debian systems now effectively installs Valkey, though the compatibility layer keeps this transparent for most applications. Anyone who explicitly still needs licensed Redis Ltd Redis now has to consciously add the corresponding repositories separately.

8. Assessing license risk for Magento operators: self-hosted versus managed

For a Magento shop that only uses Redis as a caching and session backend internally, without reselling Redis itself as a managed service to third parties, the restrictions of SSPL and RSAL barely apply in practice, since the license mainly targets offering it as a competing cloud service. Still, uncertainty about future license developments leads many operators to prefer projects with a clearly and permanently permissive license as a matter of principle.

Anyone sourcing Redis through a cloud provider's managed service barely needs to worry about this question at all, since the provider settles the licensing terms in the background. For operators who value maximum long-term stability of their open-source dependencies, the Linux Foundation's governance structure behind Valkey offers a structurally more reliable foundation than a single, commercially driven company.

9. Practical migration path: switching from Redis to Valkey step by step

Switching from Redis to Valkey can usually be done in practice without application changes, since the configuration file, the RESP protocol, and the standard commands remain identical. It is advisable to first test in a staging environment where Valkey is installed as a replacement for the existing Redis instance, while the Magento configuration for the cache and session backend stays unchanged, since both systems expect the same connection parameters.

For the production switch, a replication-based approach is recommended: Valkey can be attached as a replica of an existing Redis primary, synchronously take over the full dataset, and then be promoted to the new primary as part of a controlled maintenance window. This approach minimizes downtime and allows a fast rollback if unexpected compatibility issues arise.

10. Summary

11. FAQ: Valkey as a Redis Fork: The Essentials at a Glance