Redis to Valkey: What the BSL Fork Means and How to Migrate

The License Change and the Fork

In March 2024, Redis Ltd. relicensed Redis from the BSD-3-Clause license to the Business Source License (BSL 1.1) and a dual Server Side Public License option. The BSL restricts use in products or services that compete with Redis Ltd.'s database offerings. For the majority of enterprise Redis users — caching, session storage, pub/sub, rate limiting — the BSL restriction is unlikely to be triggered. But the license change created two practical problems: legal uncertainty about what "competing" means in edge cases, and the loss of OSI-approved open source status, which matters for organisations with open source procurement policies.

Within days of the announcement, several Redis maintainers and major cloud providers (AWS, Google Cloud, Oracle, Ericsson) announced the Valkey fork under the Linux Foundation, retaining the BSD-3-Clause license. Valkey 7.2 was the initial release, maintaining API compatibility with Redis 7.2.

Valkey vs Redis: What's the Same, What's Different

Valkey 7.x is a drop-in replacement for Redis 7.2 at the protocol level. The RESP3 protocol, the command set, the persistence model (RDB and AOF), clustering, and Sentinel are all compatible. Existing Redis clients (redis-py, jedis, ioredis, go-redis) work with Valkey without code changes — the client connects to the server and speaks the same wire protocol.

Where Valkey has begun to diverge from Redis:

• Valkey 8.0 introduced multi-threaded I/O improvements that significantly increase throughput for high-connection workloads — a direction that Redis Ltd. has also pursued but with a different implementation approach.
• Valkey's development roadmap is community-driven via the Linux Foundation governance model, meaning feature prioritisation reflects the needs of the broader user community rather than Redis Ltd.'s commercial priorities.
• The module ecosystem diverges: Redis Ltd.'s commercial modules (RedisSearch, RedisJSON, RedisTimeSeries) are not available for Valkey, but open source alternatives (RediSearch is partially open source, there are JSON and TimeSeries alternatives in the Valkey ecosystem) are available or in development.

Migration Path: Redis to Valkey

The migration from Redis to Valkey is the most straightforward major infrastructure migration we encounter at OSSeva:

1. Verify no commercial Redis modules are in use. If you use RedisSearch, RedisJSON, RedisTimeSeries, or RedisAI, evaluate whether the Valkey-compatible alternatives meet your requirements before migrating.
2. Deploy Valkey in parallel. Valkey can be deployed alongside an existing Redis deployment. Because the wire protocol is compatible, you can run both and gradually shift traffic.
3. Update client configuration. Change the connection string from the Redis endpoint to the Valkey endpoint. No code changes required for standard Redis command usage.
4. Migrate data using DUMP/RESTORE or replication. For live migration, Redis replication can be configured with Valkey as a replica (since Valkey speaks the same replication protocol), allowing a live sync before the cutover.
5. Validate and cut over. Run integration tests against the Valkey instance, then update DNS or load balancer configuration to complete the cutover.

OSSeva's Redis and Valkey Coverage

For organisations that have chosen to remain on Redis 6.2 or 7.0 (for operational continuity reasons or because the migration timeline hasn't been scheduled), OSSeva provides CVE-patched builds under a BSD-compatible license — separate from Redis Ltd.'s commercial offering. These builds maintain the open-source licensing chain while providing the CVE patching that Redis Ltd. no longer provides for older version lines.

When to Stay on Redis vs Migrate to Valkey

For most enterprise use cases, Valkey 8.x is the right long-term choice: BSD license, Linux Foundation governance, growing community, and compatibility improvements. The cases where remaining on Redis Ltd.'s Redis makes sense are narrow: heavy commercial module dependency (RedisSearch at scale, for example, where alternatives aren't yet mature), or contractual requirements for Redis Ltd. commercial support. For everyone else, the migration to Valkey is low-risk and strategically correct.

Conclusion

The Redis license change created real licensing uncertainty, but the Valkey fork provided a clean resolution. The migration is straightforward for the common Redis use cases, and Valkey's protocol compatibility means minimal client-side work. The window to migrate on a deliberate schedule is now — before EOL pressure on older Redis versions creates urgency.