On March 20, 2024, the Redis GitHub repository changed its license. Redis Ltd. announced that Redis 7.4 and all subsequent versions would move from the BSD-3 license to a dual RSALv2 and SSPLv1 model. Neither of those two licenses is recognized as open source by the Open Source Initiative.
For most individual developers, this felt like a bureaucratic footnote. But for cloud providers, platform engineers, and enterprise IT teams, the reaction was immediate. Within the same week, AWS, Google Cloud, and Oracle announced support for a project that had not yet formally launched: Valkey. They pledged to bring it under the Linux Foundation umbrella. That level of coordinated response does not happen by accident. it suggests these companies had contingency plans ready and were simply waiting for a trigger.
Valkey moved from fork to stable release faster than most open source projects manage. By 2026, it has shipped the 8.x series. AWS ElastiCache and MemoryDB now support Valkey natively as a Redis alternative. The question has shifted from “should we consider migrating?” to “when and how do we do it?”
—
Why the License Change Mattered
SSPLv1 was created by MongoDB in 2018. Its core requirement: if you use the software to provide a service, you must open-source the entire service stack. For a cloud provider, this is effectively impossible to comply with. AWS cannot open-source its entire infrastructure just because it offers ElastiCache. RSALv2 took a different angle, prohibiting competitive use without a commercial license, meaning you cannot offer a service that does “substantially the same thing” without paying Redis Ltd.
Pick either license, and cloud providers are backed into a corner: pay up or walk away.
This pattern has played out before. HashiCorp did it with Terraform, and OpenTofu emerged. Elastic did it with Elasticsearch, and OpenSearch emerged. Redis has a larger installed base than either of those, and the fork response was proportionally larger.
Valkey, whose name comes from “Value Key,” was formally established in late March 2024. Its initial contributors included engineers from AWS, Google, Ericsson, Oracle, and several longtime Redis core maintainers. The Linux Foundation provides neutral governance, which means no single commercial interest controls the project’s direction.
—
Switching Is Easier Than You Think
The first question most engineers ask is about migration complexity. The answer tends to surprise people.
Valkey is fully compatible with the Redis Serialization Protocol, or RESP. This means every existing Redis client: redis-py for Python, Jedis for Java, go-redis for Go, ioredis for Node.js. All of them connect to Valkey without any code changes. You point your connection string at the new host and that’s most of the work.
Data structures, commands, and persistence formats (RDB and AOF) in Valkey 8.x are highly compatible with Redis 7.x. String, Hash, List, Set, Sorted Set, Stream, and Lua scripting all behave consistently. There are no surprises for the common operations that most applications rely on.
This protocol-level compatibility is what drove rapid adoption. Migrations do not require rewriting business logic, replacing client libraries, or restructuring how applications interact with the cache layer. AWS describes the process in its documentation as roughly equivalent to upgrading an engine version, not a platform migration.
—
Is It Production-Ready?
For any fork project, the reasonable question is whether it is stable enough and whether there are enough people maintaining it. Valkey’s situation is better than most forks in a few ways.
The Linux Foundation governance model brings standardized processes: contributor agreements, a defined release cycle, and dedicated security response channels for CVEs. This is not a single company’s internal project that can be abandoned or redirected at a board meeting.
The engineers contributing to Valkey include people who spent years working on the Redis codebase. Their familiarity with the internals is not something you build quickly. Throughout 2025, Valkey maintained an active commit cadence, and the 8.x series introduced real performance improvements alongside the standard maintenance work.
Cloud provider backing adds another layer. AWS integrating Valkey into ElastiCache means its availability is partially bound to AWS’s own service reliability commitments. That is a different category of risk than relying on a community-maintained fork with no commercial stakeholder.
Redis itself is not going away. Redis Ltd. continues developing its commercial offering, and Redis Stack, which includes vector search, JSON document support, and time series, remains more mature than the Valkey equivalents. For workloads that depend heavily on those extensions, the calculus looks different.
—
On Performance
There are benchmarks circulating online, and their conclusions vary enough that reading them selectively can support almost any position. Treat specific numbers cautiously.
What can be said with confidence is the direction: Valkey 8.x includes multi-threaded I/O improvements that show meaningful throughput gains under high-concurrency read-write workloads. Redis 7.x has also received performance work driven by Redis Ltd.’s commercial interests. On single-instance latency, the two are close enough that this is rarely the deciding factor.
In practice, what affects performance most is not which engine you choose but how you configure it: persistence strategy, key expiration policy, memory allocation settings, and network topology. A well-tuned Valkey instance and a well-tuned Redis instance will behave similarly for most typical workloads.
If you need precise benchmark data to support a decision, run it yourself using your actual traffic patterns. The access pattern distribution, key size distribution, and command mix of your specific application will produce different results than any published benchmark.
—
The Ecosystem Question
“Ecosystem” means different things to different people, and the answer changes depending on what you mean.
If you mean client libraries, there is essentially no problem. All Redis clients communicate through RESP, so connecting to Valkey looks identical at the client level. Major Redis client maintainers have confirmed Valkey compatibility in their documentation.
If you mean third-party framework integrations like Celery,, Django’s cache framework, Spring Data Redis, Rails cache store. Those all benefit from protocol compatibility. Most work without modification when pointed at a Valkey instance.
If you mean Redis Modules like RedisJSON,, RediSearch, RedisTimeSeries. there is a real gap. These modules are part of Redis Ltd.’s commercial product. Valkey’s community is building open equivalents like valkey-search, but they are still catching up on maturity and feature completeness.
Here is a direct comparison of the two options:
| Dimension | Valkey 8.x | Redis 7.4+ |
|---|---|---|
| License | BSD-3 (OSI-approved open source) | RSALv2 / SSPLv1 (not open source) |
| Protocol compatibility | Full RESP2/RESP3 compatibility | N/A |
| Governance | Linux Foundation | Redis Ltd. (commercial) |
| Cloud hosting | AWS ElastiCache/MemoryDB, Google Memorystore | AWS (requires commercial license), Azure, GCP |
| Vector search | valkey-search (in development) | Redis Stack (mature) |
| Multi-threaded I/O | Improved in 8.x | Supported |
| Community activity | Active, multi-vendor contributions | Active, Redis Ltd.-led |
Every cell in that table has a value. Run through your own requirements against each row.
—
What Migration Actually Looks Like
For self-hosted deployments on servers or Kubernetes, the process is straightforward: replace the Redis container image with the official Valkey image, keep the same port and persistence configuration, take an RDB backup, then swap the instance. Valkey 8.x can read Redis 7.x RDB files, but the reverse is not guaranteed. Migration is one-directional. back up first and do not count on rolling back.
For managed cloud deployments on AWS, you create a Valkey cluster through the ElastiCache console or migrate from an existing Redis cluster using backup-restore or a data sync tool like riot-redis. This is not an in-place engine swap; it requires standing up a new cluster and redirecting traffic.
For client configuration, change the hostname in your connection string to point at the Valkey instance. Port, password, and connection pool settings typically do not need to change. Cluster mode topology configuration works the same way.
—
When Redis Still Makes Sense
Staying on Redis is a reasonable choice in specific situations.
If your application depends heavily on Redis Stack extensions, particularly RediSearch for full-text and vector search, migrating now carries real cost. The open-source alternatives in the Valkey ecosystem are not yet at feature parity. Waiting until valkey-search and related projects mature further, likely 2026 or into 2027, is a sensible call.
If you are a paid Redis Enterprise customer, you have commercial support and SLA guarantees from Redis Ltd. that disappear when you migrate. For enterprise environments with strict compliance requirements, that support layer has real value.
If your team has built up significant internal knowledge around Redis: tuning scripts, alerting rules, runbooks. The migration work is real even if it is not large. That cost is worth factoring in honestly.
—
The Practical Takeaway for 2026
The decision has become clearer as Valkey has matured.
For new projects, there is little reason not to start with Valkey. BSD-3 licensing, Linux Foundation governance, native support from major cloud providers, and full Redis command compatibility cover the requirements for most use cases without any meaningful tradeoffs.
For existing Redis deployments without heavy Redis Stack dependency, migration cost is low and the benefits are concrete: eliminating license compliance risk and aligning with where cloud-native caching infrastructure is heading. This is worth scheduling into the next maintenance window.
For workloads that rely on Redis Stack extensions, monitor the valkey-search project’s progress and plan around a 2026-2027 migration window when the open-source equivalents have had more time to stabilize.
Redis’s technical legacy is not going away. But its position as the default choice for most engineers is being replaced by Valkey. That is not because Valkey is dramatically superior. it is because Valkey does the same job without adding license uncertainty into your infrastructure planning. For a caching layer, predictability and the absence of unexpected constraints matter more than marginal feature differences.
Related reading
- LMCache vs vLLM: How Much Faster Is KV Cache Acceleration for LLM Inference?
- One Developer, Seven Clones, and a Declaration That Software Is Over
- Dagger vs GitHub Actions vs CircleCI: Which One Actually Works for Containerized CI?
Stay updated with our latest AI insights
