Two years ago everyone was reading license texts. Forums argued over whether SSPL really counted as open source, companies filed questions with their legal departments, and I followed the whole thing with genuine interest in the evenings. Then Redis 8 arrived, the AGPLv3 option was added, and the argument went quiet almost overnight. There was a distinct sense of "right, that's settled."
This morning I ran docker ps on my own server and discovered it was not settled at all.
A confession from my own machine
Three separate projects on VPS3 use an in-memory data store. Here is what they actually run:
bidt-test-redis-1 redis:8.4.4-alpine ā Redis server v=8.4.4
hrmarge-redis redis:7-alpine ā Redis server v=7.4.9
burncpu-redis redis:7-alpine ā Redis server v=7.4.9
All three are Redis. None is Valkey. This was not a choice ā I never once sat down and decided to stay on Redis. I typed redis:7-alpine into docker-compose.yml files because my fingers have written that line the same way for ten years.
Out of curiosity I refreshed the tag on the same server. redis:7-alpine serves 7.4.11 today. So my containers are not where the tag dragged them ā they are frozen where they were pulled months ago: one started in June, the other in July, and nobody has typed docker pull since.
That frozen state comes with two separate bills. The first is licensing. According to Redis's own license page, the 7.4 series is distributed under RSALv2 or SSPLv1, so the "return to open source" that AGPLv3 delivered covers neither machine. The second, and the more urgent one, is security. The release notes for Redis 7.4.11 mark its urgency as SECURITY and close, among other things, an ACL key-permission bypass in SORT and XREAD. I do not have that patch.
That is an instructive picture for someone who writes about his own infrastructure. Later in this article I will explain how your monitoring layer can lie to you about patch level ā and this is precisely how I came to notice it.
The timeline: what happened and when
Getting the history right matters here, because a lot of muddled retellings are circulating.
The Linux Foundation's announcement of 28 March 2024 states that the fork starts from Redis 7.2.4 and continues under the BSD 3-clause license. The names behind it are not small either: AWS, Google Cloud, Oracle, Ericsson and Snap. This was not a weekend project by a handful of annoyed developers; it was a collective reflex from companies that sell hosted database services.
On the Redis side, version 8.0 added AGPLv3 alongside the existing RSALv2 and SSPLv1. Note the wording: added, not replaced. When you download Redis Open Source today, you get to pick one of three licenses.
ā ļø
"Redis went back to open source" is true for Redis 8 and later. It is not true for the 7.4 series ā and a great many production installations still run there. Do not make that claim about your own environment before you have seen the output of
redis-server --version.
What the distributions did, and it is not what you expect
There is a claim I keep reading online: the major distributions dropped Redis entirely. That is easy to verify, so I went and looked at the package archives.
Debian trixie, the current stable release, ships both packages: redis-server 5:8.0.2 and valkey-server 8.1.1. Ubuntu 26.04 LTS tells the same story: redis-server 5:8.0.5 and valkey-server ā 9.0.3 in the release pocket, 9.0.4 once updates are applied.
Fedora went the other way. Fedora's change proposal targeted Fedora 41 and decided to obsolete the redis package in favour of valkey-compat. The rationale was plain: SSPL is not among the licenses Fedora permits.
The reason for that difference is timing. Fedora made its call in 2024, while Redis was still on the SSPL/RSAL pair. Debian and Ubuntu are deciding in a world where they can package the AGPLv3 flavour of Redis 8 ā and they chose to carry both. The ecosystem never reached a point where one side won; it settled into a two-engine arrangement.
You also pay for that arrangement at the package level. Debian's valkey-server package builds its own separate world: configuration at /etc/valkey/valkey.conf, service unit valkey-server.service, binary at /usr/bin/valkey-server. Migration does not end with apt install ā if your Ansible roles, systemd dependencies, backup script paths and log rotation rules all contain the word redis, every one of them needs revisiting. Fedora chose to soften that friction with valkey-compat, a transitional layer that handles configuration and data migration and is meant to be retired later.
For a small setup this is a few hours of work. For someone managing hundreds of machines it is a far more concrete cost line than any license text ā and that is usually where the real weight of the decision sits, not in the legal wording.
My reading is this: distribution maintainers are not taking sides on your behalf. They are handing you the choice.
The real divergence is in the code, not the license
Once the license argument ended, a more durable question was left standing: how far apart are the two codebases drifting?
Let me give an example. HGETDEL is a simple operation that reads a hash field and deletes it in the same step. In Redis's own command documentation its since value is 8.0.0. In Valkey, the same command arrived with release 9.1. One command, two different calendars.
That single example may look minor, but what it signals is not. "Wire-compatible" is no longer a guarantee; it is a version-matching problem. The two projects still speak the same protocol, yes ā but their command sets no longer overlap automatically. A command your client library supports may simply not exist yet on the other side.
Valkey 9.1, released on 19 May 2026 with contributions from more than eighty people, is clearly walking its own path. Highlights include access control defined at the database level, up to 30% higher throughput on GET operations, and up to 20% memory savings for strings under 128 bytes. According to the GitHub release list, the 9.1.1 security patch shipped on 21 July 2026, and five separate branches were patched the same day ā the mark of a disciplined maintenance line that still feeds older releases.
Let me add one more observation about maintenance discipline. Looking at Valkey's release list, 9.1.1, 9.0.5, 8.1.9, 8.0.10 and 7.2.14 all shipped on 21 July 2026 ā the same day. Even the 7.2 branch, two years old now, still receives security patches. If you have an installation stuck on an older release, that is worth more than any promise.
Redis is hardly standing still either; its investment is concentrated in vector types and search. The two projects are no longer solving the same problem. One continues to be a fast, predictable key-value engine in the classical sense, while the other is expanding towards being a data platform.
There is also a door that only opens one way. With Redis 8, RediSearch, RedisJSON, RedisTimeSeries and RedisBloom stopped being separate modules and were pulled into Redis Open Source under the same tri-license. If you use the query engine, the JSON type or the probabilistic structures, then "both engines are equal, choose on governance" simply does not apply to you ā there is no one-to-one equivalent on the Valkey side. The choice is genuinely free only for plain key-value use.
Exactly how far the compatibility promise goes
While writing this, I got curious and started a clean Valkey 9.1.1 container on my server to look at INFO server. What I saw made me stare at the screen for a moment:
redis_version:7.2.4
valkey_version:9.1.1
server_mode:standalone
Valkey carries its fork point ā Redis 7.2.4 ā in the redis_version field forever. Its own command documentation defines it exactly that way: redis_version is "the Redis OSS version this Valkey server is compatible with", while valkey_version is the actual release number.
From an engineering standpoint this is the right call. Dozens of client libraries and operational tools written over the years detect versions through redis_version; if that field suddenly reported "9.1.1", half of them would start behaving incorrectly.
Operationally, though, it is a lovely trap. If your monitoring collects version inventory through redis_version, your dashboard will read 7.2.4 for years after you move to Valkey. You applied security patches, you skipped four major releases, and the panel still says 7.2.4. Someone reviewing that line during a compliance audit will quite reasonably tell you the machine has not been patched in two years.
When you migrate, verify not only that your application still works, but that your monitoring and inventory layers are reading the right thing. If you are not collecting valkey_version, you go blind after the switch.
Managed services
If you run in the cloud, the choice has already been placed in front of you. The Amazon ElastiCache documentation lists the engines as "Valkey, Memcached, and Redis OSS" and states that the serverless tier supports Valkey 7.2 and above. Valkey coming first in that list is no coincidence, of course; AWS is one of the fork's founding backers.
Your provider's default is now your default. When you pick the engine marked "recommended" in the console, you are also picking a license and a roadmap.
The five-year question: who writes the patch
Technical comparisons only get you so far. Both engines are fast, both are stable, both speak the same protocol. Under those conditions the choice becomes a question about whose hands you are placing a ten-year dependency in.
On the Valkey side the answer is institutional: according to the project history, the fork was started by contributors from Alibaba, Amazon, Ericsson, Google, Huawei and Tencent, and the project moves forward under the Linux Foundation with foundation governance. Even if one company's commercial priorities shift, the project's owner does not change.
On the Redis side the answer is commercial: there is a company setting direction, with a product strategy and a revenue model behind it. I am not saying this is bad ā quite the opposite, projects with a clear owner often move faster, and the vector work in Redis 8 shows it. Though there is an asterisk there too: by Redis's own announcement, the vector set type is still beta, and Redis states plainly that it may change or even break the API. But what we lived through in 2024 was precisely the other face of the same coin: a project with an owner can change its license unilaterally.
So what should you do?
These are the questions I asked myself, and the ones I would put to you:
-
What are you running right now? Not a guess, a measurement: collect the output of
redis-server --versionorvalkey-server --versionin every environment. I only learned that two of my three containers were on 7.4.9 by going and looking. -
Are your Docker tags pinned? A moving tag like
redis:7can shift you into a different license range without your knowledge. Pin exact versions. - Does the license actually bind you? If you are not selling your own product as a service on top of this engine, RSALv2 may never come up in practice. But if you have a corporate compliance process, that question belongs to legal, not to you.
- Which commands do you depend on? If your codebase uses newer commands, verify the command set on both sides before migrating. This is no longer a place where you can say "they're the same."
- Who writes the patch in five years? For me this is the heaviest one. Which gives you more confidence: foundation governance, or a single company's commercial priorities?
If you are seriously considering a move, I have already walked through how to test compatibility without touching production, step by step, in migrating to Valkey and testing compatibility without risk. This article is about which one to choose; that one is about how to try it safely.
Conclusion
What will I do with my own setup? First I will move those two containers to 7.4.11; a security patch does not wait for a maintenance window. Then I will pin them to exact versions so I know where I stand next time ā something worth doing whichever engine I settle on. Switching engines is not urgent; both projects are healthy and both are being maintained.
But the thing that stays with me from this story is not technical. The license change looked like an event: a date, an announcement, a few weeks of argument. What we actually got was not an event but an ongoing maintenance burden. You may think you made your choice today and closed the matter; two years from now a Docker tag will have moved you into a different license range without telling you.
What lasts in infrastructure is not the decisions, but the habit of revisiting them regularly. Writing this article turned up three surprises on my own server: no Valkey anywhere, two machines sitting on a non-open-source license, and those same two machines missing a security release. How many will docker ps turn up on yours?
