Valkey: the best open-source drop-in replacement for Redis
In March 2024, Redis Inc. moved from its permissive BSD license to RSALv2/SSPLv1, creating real compliance exposure for commercial engineering teams.
In response, the OSS and user community almost immediately forked Redis into a new option called Valkey. Launched the same month under the Linux Foundation, Valkey offers a true drop-in replacement that sidesteps the legal baggage introduced by Redis.
Replace Redis without rebuilding your apps
The response from communities to Redis's license change features was to search for fast, coordinated, and well-resourced options, in the main a fork from the communities. Valkey is not a protest fork with little support. Valkey benefits from substantial institutional backing and support and active development – so it's fully BSD-licensed alternative with full compatibility with the Redis codebase most teams are already running.
Valkey: Reassurance built into the project and service
![[object Object]](https://assets.ovhcloud.com/1fiLCdLm2rnpzzL64g7Ebupwy_sN2JmNTk4MzJkMDY1NjMw/fde60b08-8e21-4aab-8c78-ddfe838a0c77_ite_96bcf0ea.svg){kind=small}
![[object Object]](https://assets.ovhcloud.com/1fihA7kvoqCdjbpFh8CSqrAFg_sODM3OGYwNzczYjJhNGI5/fde60b08-8e21-4aab-8c78-ddfe838a0c77_ite_a2fe1080.svg){kind=small}
![[object Object]](https://assets.ovhcloud.com/1fi4ELnwoChAbqnnwm3zvgAv5_sODJhOTlmMGI0OTUzYWJl/fde60b08-8e21-4aab-8c78-ddfe838a0c77_ite_f9914d17.svg){kind=small}
![[object Object]](https://assets.ovhcloud.com/1fiz8uqm8kwozpmrpt2nCdg5F_sNzRjNjI0Y2U4ZDlmOWQ0/fde60b08-8e21-4aab-8c78-ddfe838a0c77_ite_fe1d1635.svg){kind=small}
Why developers are looking for a Redis alternative in 2026
The 2024 Redis license change explained
For most of its life, Redis was distributed under the BSD 3-Clause license, one of the most permissive open-source licenses. You could use, modify, and build commercial products on top of Redis without restriction. That changed on March 20, 2024, when Redis Inc. announced that Redis 7.4 and all future feature releases would move to a dual-license model: RSALv2 (Redis Source Available License v2) and SSPLv1 (Server Side Public License). Neither license is approved by the Open Source Initiative (OSI), and both place explicit restrictions on how the software can be used in commercial and cloud environments.
Why SSPL creates a compliance risk for commercial products
SSPL was originally written by MongoDB to prevent cloud providers from offering managed database services without contributing back. The core problem for commercial product teams is Section 13: if your application is made available as a service and it relies on SSPL-licensed software, you may be required to release the source code of your entire service stack, including proprietary components that you developed
For most engineering teams, that obligation is a non-starter when developing features and alternatives. Even where legal counsel determines the risk is low in practice, the uncertainty alone creates friction with procurement, security reviews, and enterprise customer contracts. RSALv2 compounds this by explicitly prohibiting use in competing products or features, giving Redis Inc. broad discretion over what constitutes competition… again leaving Redis users exposed to a legal minefield of legal challenges – challenges that are readily sidestepped by using code governed by an OSI-approved license instead.
Staying on Redis 7.2: the hidden security debt
The last Redis caching release under BSD was version 7.2. Some teams choose to freeze on that version, rather than accept the new license terms. It's arguably a pragmatic short-term decision that carries a long-term cost. Redis 7.2 is no longer receiving search security patches or bug fixes from Redis Inc., meaning any CVEs discovered after the license change go unaddressed on that branch. For teams running Redis 7.2 caching in a production environment, handling sensitive data or operating under frameworks like NIS2 or SOC 2, this is not a theoretical risk. Sticking with Redis 7.2 creates an active compliance gap that grows wider with every month that passes.
Why AGPLv3 for Redis 8.0 isn’t a third option
With the release of Redis 8.0 in 2025, Redis Inc. made another licensing move, this time to AGPLv3, which is OSI-approved. It is a genuine step forward in terms of open-source legitimacy, and it addresses one of the core criticisms leveled at the 2024 change. However, AGPLv3 is a strong copyleft license, and it introduces its own complications for commercial teams.
Any software that interacts with an AGPLv3-licensed component over a network may trigger a requirement to release the source code of that software under the same license. For proprietary SaaS products, this remains a significant constraint for alternatives. Several prominent voices in the industry, including contributors to the Valkey project, have noted that AGPLv3 (while more principled than SSPL) still places Redis in a different category from truly permissive open-source alternatives.
Preserve app behaviour and control data location
Multi-node layouts can also preserve familiar resilience patterns. Compatibility still requires testing. Modules, version-specific behaviour and unusual command combinations may produce a different reply. Storage design, client settings and topology can also affect stability or throughput. No migration should assume every edge case will run faster or behave identically. Valkey's OSI-approved license gives commercial teams a durable open-source alternative to Redis without binding application architecture to restrictive terms.
Deployment choice then adds an operational dimension. A managed European offer can combine threaded processing, resilient node placement and controlled data hosting. This approach supports European data sovereignty by keeping location, access and contractual handling visible while reducing routine platform administration.
DragonflyDB leads on raw single-node throughput in some tests, but that advantage narrows significantly in cluster configurations. Feature parity with Redis 7.2 is complete, and Valkey's roadmap has since added multi-threading improvements and memory efficiency gains that in some workloads put it ahead of the version it forked from.
Other technologies can suit specialised requirements, such as vector search or intermittent serverless workloads. Research may include technical material found through Google, community discussions and vendor documentation, but primary documentation and controlled testing should carry greater weight. Compare each alternative by application change, operational maturity, available support, governance and total migration effort. The appropriate technology is the one that meets measured requirements with acceptable licensing and operational risk.
Match the operating model to your requirements
Managed Valkey
Managed Databases for Valkey suits companies that want simple operations and predictable infrastructure cost. OVHcloud manages high availability, maintenance, monitoring and backups, reducing the internal work needed to run a resilient service. Included bandwidth and IOPS also make budgeting clearer. This is a practical default when platform teams need Valkey without owning every operational task.
Self-managed Valkey
Self-management provides control over software versions, topology, security settings and deployment location. It can fit companies with specific requirements or established database operations. The cons are equally real: the internal team owns upgrades, backups, observability, failover testing and incident response. Community resources help, but they do not replace accountable production support or operational capacity.
KeyDB
KeyDB may suit teams investigating multithreaded execution for particular memory data workloads and latency goals. Evaluate compatibility, release activity, project health and available support before committing. Benchmark the actual application rather than assuming an architectural feature will improve every request pattern. Information associated with a founder or early project statement should also be checked against current documentation.
Specialised alternatives
Serverless services can reduce capacity planning for intermittent workloads, while vector databases support similarity search and other specialised data models. Alternative in-memory software may target narrow throughput or persistence needs. These tools can solve defined problems, but they are not necessarily drop-in choices. Account for application changes, data movement, operational ownership and long-term cost before selecting them over Valkey.
Choose a migration path that fits downtime
Bring down your Redis instance for consistency, copy the file to your Valkey data directory, start Valkey, and you are done. Total migration time is proportional to dataset size, not application complexity. For production environments where downtime is not acceptable, live replication is the safer path. Valkey can be configured as a replica of a running Redis 7.2 instance using the standard REPLICAOF command.
Once the replica is fully synchronized, you update your application's connection support string to point at Valkey, promote it to primary, and decommission the Redis instance. Because both systems speak the same replication protocol, this process is clean and well-tested in production by teams across all major cloud providers.
![[object Object]](https://assets.ovhcloud.com/1fiX676v6wSp4t82zXEm6hhry_sNzAzOTNmMTIyZWVkYzg0/555a10a6-71ae-4d77-959e-b2a8dc0e9831_ima_c8d0550b.png)
Build a four-part migration-readiness framework
1. Application compatibility
Create an inventory of every command, client library and protocol version in use. Record RESP3 features, Lua scripts, transactions, pub/sub patterns, JSON or module dependencies, and application-specific timeout behaviour. A compatible core does not prove that every extension behaves the same way. Compare the current environment with the target version and test representative requests. Include failure handling, connection pooling and retry logic. If an application relies on technology supplied by an external plugin, verify its maintenance status separately. This inventory turns general compatibility into evidence based on specific requirements.
2. Protect data integrity
Measure the dataset before migration, including key counts, expiry distribution, object sizes and peak memory consumption. The target needs enough memory for normal operation, replication and temporary overhead during synchronisation or persistence. Review snapshot and append-only settings rather than copying them without analysis. After transfer, compare key counts, sampled values and expiry behaviour. Application-level checks can reveal problems that raw totals miss, such as malformed sessions or incomplete queue state. Share acceptance criteria with service owners before cutover so everyone uses the same definition of a valid dataset.
3. Map the target topology
Document whether the current platform is standalone, replicated or distributed across a cluster. Record each node, network route, security rule, DNS dependency and physical location. This map helps teams select a target layout that reflects resilience needs rather than reproducing historical choices. Connectivity tests should cover the application, monitoring systems and administrative tools. For a distributed workload, verify slot handling, replica placement and behaviour during node loss. Data location requirements may also determine which regions or availability zones are acceptable.
4. Control the cutover
Establish latency, error-rate and resource baselines before moving traffic. Define monitoring thresholds, rollback criteria and decision owners while the service is stable. This prevents teams from debating acceptable behaviour during an incident. Shift traffic in stages where the architecture allows it. Start with internal or low-risk workloads, observe client errors and compare results, then increase the share. Keep the source recoverable until validation is complete. A safe cutover depends on measured evidence, clear ownership and a rollback route, not compatibility claims alone.
Why choose OVHcloud Managed Databases for Valkey
One of the persistent frustrations with cloud-managed databases is bill unpredictability. Think charges that balloon under load because bandwidth, IOPS, and backup storage are metered separately. OVHcloud's pricing model bundles these costs into a flat monthly rate. Bandwidth, I/O operations, and automated backups are included, so the cost you see at provisioning is the cost you pay in production. For finance and procurement teams in scale-ups managing tight infrastructure budgets, this makes capacity planning significantly cleaner.
