Why migrate to Valkey if Redis is open source again?

Last week someone asked me why they should migrate from KeyDB to Valkey, if Redis is open source again. Redis has a more mature ecosystem, nobody "officially" supports Valkey (not even Microsoft in StackExchange.Redis), and Valkey itself still says Redis when you run the INFO command. So what's the point?

That is a genuinely good question, and it deserves a longer answer than a LinkedIn message. I'll break it down into four sections. Quick disclosure before we start: I used to work at Redis, and now my company builds monitoring for Valkey, Redis, and all compatible RESP databases. Discount accordingly.

1 - The OSS standard

Redis is open source again since May 1, 2025, when Redis 8.0 added AGPLv3 as a licensing option. Here is the full timeline, so you can have context:

• Until March 2024, Redis was BSD-3-Clause. Fully permissive, do what you want.
• On March 20, 2024, Redis Ltd. moved Redis 7.4 to a dual license: RSALv2 or SSPLv1. Neither is OSI-approved. This is the moment Valkey forked (from 7.2.4, the last BSD version), under the Linux Foundation, announced March 28, 2024.
• On May 1, 2025, with Redis 8.0, they added AGPLv3 as a third option. You pick one of the three. AGPL is OSI-approved, so "Redis is open source again" is technically true.

Valkey has been BSD-3-Clause the entire time. And the difference between BSD and AGPL is not academic if you're the one choosing a database. BSD asks for attribution and nothing else. AGPL is strong copyleft: if you modify Redis and offer it over a network, you owe your users the modified source. For most people just running a cache, that obligation never triggers. But plenty of legal departments (Google's famously among them) ban AGPL outright as a precaution, which means for a chunk of the industry "open source again" still reads as "can't use."

The more important question is why the license changed, and who can change it next. The AGPL addition came, to a non-trivial extent, as a response to Valkey's momentum - to take away the "Valkey is the OSS one" argument. Allegedly. (I worked at Redis at the time, btw.) And everything that allowed the 2024 relicense are all still in place: Redis Ltd. requires a CLA, holds the rights to the whole codebase, and can relicense future versions whenever it suits them. They've done it twice now - modules in 2018, core in 2024. The 2025 move was the third license change in seven years, just in the friendly direction this time.

Valkey can't do that, structurally. Contributions come in under the DCO, so contributors keep their copyrights - there is no single entity that could relicense the code, even if it wanted to. Governance sits with a Technical Steering Committee where no single organization may hold more than a third of the seats. "Open source" that one company can re-close is a different procurement risk than open source held by a neutral foundation.

And you can see the difference in who actually writes the code. I pulled the numbers for the last 12 months (Oct 2025 - Oct 2026), classifying commit authors by their GitHub profile and commit email¹:

• redis/redis: 582 commits from 117 people. At least 26 of those people are Redis employees, and those 26 wrote 47% of the commits - and that's a floor, because several of the top committers (including the #1 committer by volume) have blank profiles. The confirmed external contributors - people from Intel, Alibaba, Tencent, Baidu, SUSE, Upstash and others - wrote 47 commits between them. About 8% of the total.
• valkey-io/valkey: 786 commits from 157 people. The biggest single bucket is AWS at 38% of commits, then one remarkably prolific engineer from Tencent at 17%, then Ericsson, Google, Alibaba, Huawei, plus people from Percona, Red Hat, ByteDance, Apple, Cloudflare, universities, and a long tail of individuals (including yours truly). No company is close to a majority.

One repo is a company's product that accepts outside patches. The other is a commons that several companies fund because they all run it. Which brings us to point 2.

2 - A singular decision maker vs the community

Redis still calls itself a startup. It has several hundred employees and the processes to match: decisions go through layers of approval, and at the end of every layer it is still one company deciding. Which modules exist, which get folded into the core, what the roadmap is - all of it.

On the other side you have Valkey. You can open issues, open PRs, or build something adjacent to it, and the direction is set in the open. Jacob Murphy (Google) had a great talk at ValkeyConf on exactly this: "Evolving Valkey Together: Building Fast Without Central Control" - how decisions get made, and how quickly. My favorite anecdotes from it: Google and Tencent independently implemented the same feature, and the version that landed in Valkey took the best of both. AWS writes an RFC, Google co-edits it. As Mas put it in one of the introductions - a lot of the speakers are at competing companies, yet they all contribute and push the product forward. (Mas, if you end up reading this, apologies if I butchered the quote.)

It goes beyond the conference talks. The day after ValkeyConf was Valkey Contributor Day: a room full of people voting on what happens next, when, and who drives it. All of that becomes public issues that get broken down and worked. Every Valkey meeting is public. Anyone can join, anyone can listen, anyone can weigh in.

Are benevolent dictators better than democracies in some cases? Sure. Are you certain the dictator is really benevolent, though?

3 - The ecosystem

This is the strongest argument against migrating, so let me not strawman it: most client libraries still say "Redis" on the box, StackExchange.Redis lives in the Redis-aligned world (Microsoft is a major Redis partner and won't be leading a rename), and your stack was built with Redis in mind. All true.

Two things make it less scary than it looks.

First, RESP compatibility means you are not blocked today. Your existing Redis clients - redis-py, Jedis, node-redis, StackExchange.Redis, all of them - work against Valkey right now. You don't wait for the ecosystem to rename itself; you point it at a different endpoint. (It's also how we support Redis, Dragonfly and KeyDB in our own product despite Valkey being the main focus.)

Second, the native client story is further along than people assume, just not where they look. Look at valkey-glide: a Rust core with Python, Java, Node.js and Go bindings (C# and PHP in preview, Ruby and C++ in development), started inside AWS in 2022 and now, per its own README, "Backed and Supported by AWS and GCP". In the last 12 months it saw 709 commits from 63 contributors - for scale, redis-py, the most-contributed Redis client, had 300 commits from 92 contributors in the same window. And new native clients keep appearing: valkey-swift went from first commit in March 2025 to a 1.5.0 release, Spring Data Valkey is shipping, and GLIDE wrappers for Ruby and PHP went from zero to 1.0 releases within months.

I'll be honest about the rest, because the numbers are public: the drop-in forks of the classic clients (valkey-py, iovalkey, valkey-java) are maintained but quiet - a few commits a month, not hundreds. That's not a scandal; it's what you'd expect when the upstream Redis clients already work against Valkey unchanged. The forks exist as insurance, GLIDE is where the investment goes, and the insurance only becomes load-bearing if the Redis clients ever stop speaking to Valkey.

This is also where smaller vendors matter, including us. The gaps in the ecosystem are exactly the kind of thing a lean org can close quickly, because we're not waiting on a large company's roadmap. Build the missing piece, use it, pass it upstream to the foundation when it makes sense. Fast at the edges, consolidated upstream.

4 - So why does Valkey still say Redis?

Run INFO against a Valkey 9 server and you'll see redis_version:7.2.4. People read that as "Valkey is stuck on 2023 Redis." It isn't - it's a compatibility shim, and it was designed as one before Valkey's first release.

Here's the actual situation. Valkey forked from Redis 7.2.4 in March 2024, and that was the only time the codebases touched. Since then Valkey shipped 8.0, 8.1, 9.0, 9.1 on its own - its own features, its own on-disk format. And now has 9.2 as a release candidate with a lot of optimisations. But a decade and a half of client libraries, health checks and deploy scripts parse redis_version to decide what the server can do. Report "9.1" in that field, or remove it, and all of them break for no benefit to anyone. So redis_version is pinned to 7.2.4 - "this server is compatible with Redis 7.2.4" - and the real version lives in valkey_version and server_name:valkey, which have been there since the first release.

If you think that's a Valkey quirk: Dragonfly - a from-scratch C++ implementation that shares zero code with Redis - also reports redis_version in INFO. It claimed 6.2.11 for years, then bumped the fake version to 7.2.0 in December 2024 specifically so Sidekiq would accept it. Its real version is in dragonfly_version. Every browser's user-agent string still starts with "Mozilla/5.0" for the same reason: the field stopped meaning identity decades ago and now means "here's what you can assume about me."

So "Valkey still says Redis" is true in exactly the way that keeps your existing tooling working. The honest caveat sits elsewhere: commands Redis added after the 7.4 split aren't in Valkey, and Valkey has its own equivalents in some cases. With Redis spending the last couple of years focused on AI features while Valkey invested in performance and observability, that divergence is narrower than the version label suggests - but it's the thing to actually check per workload. Not the shim.

So, should you migrate?

If you're on KeyDB, you're migrating somewhere regardless - the question is only where to. And then it comes down to this: Redis is open source again under a license one company added and that company can route around next time; Valkey was never anything else, and its structure has no mechanism for a re-close. Your clients work today over RESP. The native library story is improving on AWS's and Google's payroll, not a hobbyist's weekend. The one real homework item is the post-7.4 command divergence for your specific workload.

Migrate for the governance and the licensing certainty. Keep your clients. Check your commands. The version string is the least interesting thing about the whole question.

When you're ready to move, BetterDB's migration planner will analyze the source, execute the copy, and verify the target against it - so "done" means "correct," not just "finished."

---