The Redis fork everyone expected to die is what you should be running

March 2024. Redis, LLC announces it’s changing its license from BSD-3 to a dual RSAL/SSPL model — “source available” language designed explicitly to prevent AWS and Google from running hosted Redis services without paying up. It was a reasonable business decision by a company watching hyperscalers extract margin from their open-source work. It was also, in practice, the moment Redis stopped being open source.

Two weeks later, AWS, Google Cloud, Oracle, Ericsson, Alibaba, and Snap filed the papers to donate a Redis fork to the Linux Foundation. They called it Valkey. I wrote a twenty-line note to myself that said approximately: this is how you get a committee-managed zombie project that still runs Redis 7.2 in 2028.

Valkey 2.0 just shipped. I was wrong.

Why I thought it was going to rot

Foundation forks have a pattern. The business logic is sound — a bunch of companies with shared infrastructure needs throw some engineers and some legal cover at a project and agree to not compete on the underlying layer. What usually goes wrong is that “governance by committee” and “moving fast” are architectural contradictions. The companies have conflicting priorities. The engineers rotate. Nobody owns the roadmap in the way one opinionated maintainer owns a project they built from scratch.

Look at the graveyard: OpenOffice after Oracle. Hudson before Jenkins got momentum. OpenSolaris. The number of successful open-source projects incubated in a foundation structure from day one is a much shorter list than the number that arrived there already mature and just needed a neutral home.

Valkey was neither. It was a fork of a production-quality codebase from a company that was still actively developing its own commercial branch. Redis 8.0 would keep shipping. You’d have two diverging trees, a set of enterprise users caught between them, and a Linux Foundation project trying to compete with a well-funded commercial product while running on committee cycles.

That was my read. I stand by it as a risk model. I was wrong about the outcome.

What actually happened

The founding members had skin in the game in a way that’s different from the usual foundation math. AWS and Google weren’t doing this to be charitable. They were doing it because they were already maintaining substantial internal patches to Redis for their managed service offerings, and the alternative was a relicensing negotiation with a vendor that had just demonstrated it viewed them as the problem to solve. Their incentive to keep Valkey actually good was structural, not aspirational.

That alignment matters more than governance process. A project where the maintainers need it to work is different from a project where the maintainers agreed to show up to meetings about it.

The technical stewardship helped. The Valkey contributors kept RESP3 protocol compatibility as a hard constraint — you can point an existing Redis client library at a Valkey server and it doesn’t care. That’s the right call even though it constrains what you can change, because the ecosystem value of drop-in compatibility with everything that already works against Redis is enormous. They treated backward compatibility as infrastructure, which it is.

Antirez (Salvatore Sanfilippo, Redis’s original author, who had already stepped back from Redis development before the license change) has said very little publicly about Valkey. The silence reads as tacit. He built the thing, he handed it off, and the people who took a copy of it are doing what he’d have done with it. I have no evidence for this interpretation and I’m making it anyway.

What Valkey 2.0 actually changes

The headline feature is multi-threaded command execution as a real first-class path, not the bolt-on io-threads model from Redis 6. Redis’s single-threaded command execution loop was always the tradeoff the project lived with: simpler reasoning about atomicity, real predictable latency at the cost of CPU utilization above a certain throughput ceiling. Valkey 2.0 keeps the single-threaded path as the default for compatibility, but the multi-threaded command execution option is now production-ready rather than experimental.

Benchmark results from the Valkey project show meaningful throughput gains on multi-core hardware for workloads that can tolerate slightly less strict ordering guarantees. If you’re running Valkey as a cache — which is most people — the ordering subtleties don’t matter and the throughput headroom does.

The clustering and replication story has also gotten materially better. Replica lag during leader failover has been a quiet operational pain point since Redis Cluster shipped in 2015; the Valkey team has been reworking the replication internals in a way that the Redis core team, dealing with the commercial product roadmap, never had the cycle budget to address. It’s the kind of thing that only gets fixed when you have a bunch of companies whose support teams have been explaining the same failover latency spike for five years.

Who should actually switch

If you’re running AWS ElastiCache or Google Cloud Memorystore, you’re already running Valkey. Both services migrated their default engine in 2024 and if you didn’t go out of your way to pin to Redis, you’ve been on Valkey for over a year. This isn’t a decision you’re making; it’s one your cloud provider made for you.

If you’re running self-managed Redis on your own infrastructure, the calculus is straightforward: Valkey is what you should be evaluating. The license is proper open source (BSD-3, same as Redis used to be). The protocol compatibility is real — your client libraries don’t care. The feature delta from Redis 7.2 is closing, and in a few specific areas like multi-threaded throughput and replication stability, Valkey has genuinely moved ahead.

The case for staying on Redis 8.0 under the commercial license is: you need features Redis has shipped under RSAL/SSPL that Valkey hasn’t matched, or you want the vendor support relationship. Both are legitimate. The days of “Redis is obviously the right answer for in-memory data structures” are over; now it’s a choice with a real alternative, and you should make the choice deliberately rather than by default.

The part I didn’t see coming

I’ve spent thirty-plus years watching open-source licensing fights. The pattern is: company makes something popular, gives it away, hyperscalers eat the margin, company relicenses, community forks, fork dies or fragment, company wins the commercial market anyway. It’s a story I know the ending to.

The Valkey outcome breaks the pattern. The fork didn’t die. It didn’t fragment. It’s shipping better code than the original tree in measurable ways, two years in, with a governance structure I would have bet against. The structural incentive alignment was strong enough to overcome the usual committee entropy.

I don’t know if this generalizes. The conditions were unusual: huge well-resourced founding members with genuine economic incentive, a mature codebase with real protocol compatibility as a constraint, and a commercial competitor that decided to go fully proprietary rather than staying in the open-source conversation. That combination may not repeat.

But it worked this time. I was wrong. I try to update when I’m wrong — this is me updating.