Issue #022 - Valkey, one year on: you're probably running it already
Redis license flip, BSD vs AGPL copyleft, hyperscaler defaults, distro swaps, trivial migration
A teammate's Terraform plan for a new staging cache came back with engine = "valkey" where I'd have expected redis. I asked who'd changed it. Nobody had. The line wasn't in the PR description because it wasn't a change anyone made - it was the module default, and the module had moved upstream. Somewhere upstream, the thing you reach for when you want "a Redis" had quietly stopped being Redis, and nobody on our team had sat in a meeting and decided that. The default moved under us.
That's the part of the Redis-Valkey story the headline leaves out. The headline is true enough - a company relicensed, the community forked, all inside one frantic week in March 2024. But that week was a moment. The part I keep chewing on is the two years since, because Valkey didn't take over with announcements. It took over in the places nobody watches. My apt pulled it in without asking. The managed-service console reordered itself to show it first, at some point I never noticed. And the Helm chart our platform team owns turned out to have pointed at it for a year before that diff finally made me look. Not one of those shifts came with a press release - and they didn't stop when Redis, the company, reversed itself in 2025 and put Redis back under an open-source license.
What follows is about an ecosystem-scale shift that already finished happening while everyone argued about whether it would.
🏗️ Architectural Pattern: how a permissive fork becomes the default
What actually happened, with dates
On March 20, 2024, Redis dropped the BSD-3-Clause license it had carried since 2009 and moved to a dual source-available model: the Redis Source Available License v2 and SSPLv1. The first release under it was Redis 7.4. Neither license is OSI-approved, and that's not a technicality - it's the whole story. Source-available means you can read the code and run it, but the terms carve out exactly the thing the hyperscalers do: offer it as a managed service.
Eight days later, on March 28, the Linux Foundation announced Valkey, forked from Redis 7.2.4 - the last commit under BSD. The founding sponsors were the companies with the most to lose from a source-available Redis: AWS, Google Cloud, Oracle, Ericsson, Snap. Madelyn Olson, a longtime Redis core maintainer from AWS, became one of the project leads. One small correction to a thing I see repeated everywhere, including in my own notes from when I first filed this topic: Valkey is a Linux Foundation project, not a CNCF one. It never went into the Sandbox. I had it wrong for months.
So far this reads like every other license-flip fork - OpenSearch out of Elasticsearch, OpenTofu out of Terraform. The pattern rhymes. But the reason this fork stuck has less to do with community sentiment than with one word in the old license.
Why "permissive" was the load-bearing word
BSD is a permissive license. It lets you take the code, build a billion-dollar managed service on top, and never contribute a line back. That permissiveness is exactly what Redis Inc. was trying to end - and it's exactly what AWS, Google, and Oracle needed to keep their ElastiCache and Memorystore businesses running without paying a toll.
When those three put their weight behind Valkey, they weren't being generous. A BSD fork was the only outcome that preserved their existing business model. SSPL would have forced them to open-source their entire service stack; RSAL would have forced a commercial deal. A fork off the last BSD commit kept the permissive grant alive. The hyperscalers funded the fork because the fork was cheaper than either alternative the new license offered them.
That's why this fork had something OpenTofu and OpenSearch had to fight harder for: three of the largest infrastructure vendors on earth were structurally motivated to make it the default in their own products on day one. And the place a fork becomes a default isn't GitHub stars. It's the package index and the managed-service console.
The defaults fell like dominoes
Watch where Valkey landed, and how fast.
The Linux distributions went first, because a distro maintainer's whole job is "ship the thing with a real open-source license." Fedora 41 shipped in October 2024 with Valkey replacing Redis outright - the package literally carries Obsoletes: redis, so dnf upgrade swaps you over. Debian 13 "trixie" ships valkey-server in main. Arch replaced Redis in its [extra] repo in April 2025. Ubuntu pulled it into the archive the same autumn. If you apt install redis on a current distro, there's a real chance you're getting a compatibility shim that pulls Valkey.
The managed services went next. AWS launched ElastiCache for Valkey in October 2024 and priced it to move - the serverless tier landed about 33% cheaper than the Redis-OSS equivalent, node-based up to 20% cheaper, with a serverless floor around $6 a month. MemoryDB for Valkey came the same day at roughly 30% under the Redis option. Google's Memorystore for Valkey went GA in April 2025 and had Valkey 9.0 by March 2026. Oracle, Aiven, DigitalOcean all shipped Valkey tiers.
One thing the tidy version of this story gets wrong, and I want to be precise because I almost printed it myself: it is not all three big clouds. Azure did not switch. Azure Managed Redis runs Redis Enterprise software under a commercial arrangement with Redis Inc., and Valkey on Azure only exists if you run it yourself on AKS. So the line is "AWS and Google made Valkey the cheap default, Azure stayed with Redis." Anyone who tells you the hyperscalers unanimously defaulted to Valkey is rounding off a third of the market.
But two out of three, plus the distros, plus the price cut, is how a default moves without a decision. That Terraform module didn't pick Valkey because someone believed in open governance. It picked Valkey because the upstream provider made it the cheaper, first-listed option, and defaults are sticky in exactly the direction the vendor points them.
Links
🆚 Showdown: Valkey vs Redis, one year of divergence
For the first six months, "Valkey vs Redis" was a non-question - they were the same codebase with different logos. That's not true anymore. Both projects shipped real, divergent engineering through 2025 and into 2026, and the gap is now wide enough that you're choosing between two products, not two brands on one binary.
Where Valkey spent its year
Valkey 8.0 landed in September 2024 with the work the AWS-heavy contributor base cared about most: I/O threading reworked to push more off the main thread, and a memory layout change in cluster mode that trimmed roughly 24 bytes per key - about a 20% reduction in per-node memory on real workloads. On a c7g.4xlarge that pushed single-node throughput to around 1.19 million requests per second, and the project made "one million RPS" the headline because for a Redis-shaped thing that number used to require sharding.
Then 8.1 in March 2025 added an experimental RDMA transport and a more memory-efficient hash table. Version 9.0 in October 2025 brought atomic slot migration - resharding a cluster without the window where keys could be served by the wrong node - and hash-field TTLs (HEXPIRE), which people had wanted for a decade. The current release, 9.1 from May 2026, redesigned the threading again for another throughput bump and added per-database ACLs.
The module question matters too, because the old Redis Stack modules - JSON, search, probabilistic structures - were never BSD, so the fork couldn't take them. Valkey built replacements: valkey-search went GA in May 2025 with HNSW approximate-nearest-neighbor and exact KNN for vector workloads, valkey-bloom and valkey-json shipped around the same time, and they're bundled together now. Not as mature as Redis's decade of Stack, but no longer a blank space.
Where Redis spent its year, including a plot twist
Here's the part the "Valkey won" narrative tends to skip. On May 1, 2025, Redis 8 shipped with AGPLv3 added as a license option. AGPL is OSI-approved. Redis, the product, is open-source software again - tri-licensed now, but you can take the AGPL grant and you're fully in open-source territory. Salvatore Sanfilippo, antirez, the original author, had rejoined Redis in late 2024 and contributed Vector Sets to that release.
And Redis 8 is a genuinely strong release. It folded the formerly-separate Stack modules - JSON, time series, the query engine with vector and full-text search, the new Vector Sets - into the open-source core. If your reason for using Redis was the rich data-structure surface and the AI-adjacent feature set, Redis still has the deeper, more integrated version of that. The company kept the brand, the docs everyone Googles, the Redis Cloud business, and the most mature module ecosystem.
So who actually won what
They won different things, and pretending otherwise is how you make a bad architecture call.
Valkey owns the substrate. The distro default, the cheap managed tier on AWS and Google, the self-hosted "I just need a fast cache and I don't want to think about licensing" case. If your relationship with Redis was "it's the thing apt installs and ElastiCache runs," that thing is Valkey now, and the migration is free.
Redis owns the product surface. The integrated search and vector and JSON story, the commercial support, the brand recognition that gets it through a procurement review without a fight, the feature velocity from a funded company with the original author back in the building.
The mistake is treating it as one contested codebase where a winner takes all. It's two projects that started identical and are walking apart - same wire protocol, increasingly different ambitions. A year from now "should we use Redis or Valkey" will feel as coherent a question as "should we use MariaDB or MySQL," which is to say: it depends entirely on which lane you're standing in.
Links
🛠️ The practical part: migrating is a non-event, the operator isn't
The good news is almost suspiciously good. Valkey forked from Redis 7.2.4, so for the overwhelming majority of deployments the migration is "change the binary, keep everything else." RESP2 and RESP3 are identical. RDB files load straight across. Replication between a Redis primary and a Valkey replica works, which means you can cut over with the same zero-downtime dance you'd use for a Redis version bump: stand up Valkey as a replica, let it sync, promote it, retire the old primary.
Your client library almost certainly doesn't care either. Jedis, Lettuce, ioredis, redis-py, go-redis, StackExchange.Redis - they speak the wire protocol, and the wire protocol didn't change. I migrated a small internal service as a test before writing this, and the only diff in the application was the connection hostname. There's also Valkey GLIDE now, an officially-backed client with a Rust core and language bindings, if you want something the project itself maintains - but you are under no pressure to switch off the client you have.
So if it's that easy, where's the catch? It's one layer up, in how you run it on Kubernetes.
The operator gap is real
If you run Redis on Kubernetes through an operator, do not assume there's a clean, mature, Valkey-native equivalent waiting. There isn't, quite, yet. The official valkey-operator from the Valkey project is still pre-1.0 and labeled not-for-production, and I'd take that label seriously. The most capable Valkey-native operator today is the third-party hyperspike/valkey-operator, which is solid but also still pre-1.0 with a few hundred stars - fine for a team that reads the code, riskier as a blind dependency.
The pragmatic move, and the one I've seen hold up, is to not chase a Valkey-branded operator at all. The mature Redis operators - the ones from OT-Container-Kit and Spotahome - drive the engine over the same wire protocol, so they run Valkey perfectly well even though they say "redis" on the tin. Point the existing operator at a Valkey image and it works. You get the maturity of a battle-tested operator and the engine you want, and you wait for the Valkey-native operators to grow up before betting a fleet on them.
One more sharp edge from this year: Bitnami changed its container-image and chart terms in August 2025, which broke a lot of "just use the Bitnami chart" muscle memory across both Redis and Valkey. The Valkey project responded with an official Helm chart in January 2026. If your platform inherited a Bitnami Valkey chart and it started behaving strangely late last year, that's why - move to the official chart.
The decision, compressed
New deployment, you control the stack, you want a cache or a data structure server without the licensing question: Valkey, default, no real argument. New deployment that leans hard on Redis's integrated search, vector, or JSON-and-query surface and you'd otherwise be wiring those up by hand: Redis 8 earns its place. Existing Redis older than 7.4 that you're happy with: there's no fire, but the next time you'd do a major version bump anyway, that's your free, low-risk moment to land on Valkey instead - because the managed tier and the distro package are already heading there without you.
Links
🔥 Hot Take: Redis is open source again and it changed nothing
When Redis 8 added AGPL in May 2025, a reasonable person could have called the whole thing over. The original grievance was "Redis stopped being open source." Redis is open source again. Case closed, everyone go home, undo the fork.
That's not what happened, and the reason it didn't is worth sitting with, because it's the actual lesson of the last two years.
First, the technical one: AGPL is copyleft, BSD is permissive, and for the parties that funded Valkey those are not interchangeable. AGPL's network clause is precisely the obligation a hyperscaler building a closed managed service wants to avoid - it's a milder cousin of the SSPL that started the fight. Redis going AGPL gave individual developers their OSI checkbox back, but it gave AWS and Google nothing they could build a business on the way BSD did. The people who made Valkey the default didn't get their problem solved by Redis 8. So they kept their fork, and the fork they'd already wired into ElastiCache and Memorystore kept being the default.
Second, the one that doesn't show up in a license comparison table: trust doesn't round-trip. A project that relicensed once, against the wishes of much of its contributor base, to capture revenue, has demonstrated it will do that. Adding an open license back doesn't restore the thing that broke - it just proves the license is a lever the company is willing to pull. Once a community has watched the rug move, "we put it back" is not the same as "the rug was never moveable." The Linux Foundation's pitch for Valkey is governance you can't relicense on a whim, and that pitch got stronger when Redis demonstrated relicensing-on-a-whim is a thing that happens.
I'll add a caution in the other direction, because the pro-Valkey camp overclaims too. You've probably seen the stat that "83% of large enterprises have adopted or are exploring Valkey." Don't repeat it as a migration rate. It's a vendor survey, it predates Redis going AGPL, and "adopted or exploring" bundles a production cutover with someone running it once in a sandbox. The honest, boring truth is the one I opened with: the defaults moved, so adoption is happening through inertia more than conviction, in the lanes where the upstream made Valkey the cheap first option.
The reframe I'd offer: this stopped being a fight and became a fork in the road, in the literal sense. Two roads, both paved, going to different places. Redis is a well-funded company building a rich data platform with the original author back at the helm. Valkey is an infrastructure commodity governed so it can't be enclosed again, riding inside the clouds and distros that fund it. The "war" framing wants a loser. There isn't one. There's a substrate and there's a product, and most of us are quietly running the substrate without having chosen it - which, when you think about what infrastructure is supposed to be, might be the most complete kind of winning there is.
Until next week
The thing that stuck with me writing this: the most consequential infrastructure decision of the last two years, for a huge number of teams, was made by nobody on those teams. It got made in a module default, a distro Obsoletes line, a managed-service console that listed the cheaper option first. That's worth a paranoid afternoon - go check what your caches actually run right now, because the answer may have changed without a ticket.
Next Tuesday we stay in the land of costs you didn't sign off on: namespaces. They look free. At scale they are extremely not, and one team found 7 TiB of memory hiding in the gap. See you then.
- Ilia