Valkey Turns One: Community fork of Redis
106 comments
·May 30, 2025antirez
christophilus
Thanks, antirez. Nuance doesn’t get clicks.
ignoramous
> Nuance
Not any random ensemble of "Valkey contributors" that did async IO but AWS: One of those cloud providers Redis moved away from FOSS for.
One year later, Valkey hasn't just survived – it's thriving! The Async I/O Threading model contribution from AWS unlocked 3x+ throughput by fundamentally changing how I/O threads work inside Redis.
... those open source companies that still harbor magical beliefs ... cloud services providers are emphatically not going to license your proprietary software. I mean, you knew that, right?
... The cloud services providers are currently re-proprietarizing all of computing – they are making their own CPUs for crying out loud! – reimplementing the bits of your software that they need in the name of the service that their customers want (and will pay for!) won't even move the needle in terms of their effort.
bgwalter
Cantrill is partially wrong:
https://www.theregister.com/2025/05/01/redis_returns_to_open...
"Trollope later justified the shift by saying the SSPL license only really "applies to Amazon and Google" – fellow cloud provider Microsoft has agreed commercial terms with Redis."
The latest AGPL shift is great and should have been the default for open source since 2010.
Attummm
A post like this hitting the HN front page feels like a monthly occurrence. Normally I think of commenting in your support but never post it.
While I agree with your technical points, the constant criticism seems less about the specifics and more rooted in either a tendency to go after the incredibly successful, or classic tall poppy syndrome [0].
While we can't control how others react, reframing these kinds of posts as an indirect acknowledgment of your work's significance might be a healthier approach.
P.S. Appreciate the LinkedIn connection.
geerlingguy
Didn't antirez announce Redis was going (actual) open source again?
If so, is it too little, too late, to turn back the tide? I remember Node.js almost fell apart after the short-lived Io.js fork era, but the community patched up.
Is the same possible with Redis? I used to use it a lot, but haven't for the past few years, so I'm not able to get the same perspective on the community around these two projects.
WhyNotHugo
Last I checked, Redis still had a CLA. In other words, they reserve the exclusive right to turn back into closed source. As long as they require that contributor agree to such terms, there’s no reason to trust that they won’t pull the same thing again.
williamstein
Also, Redis is being opened sourced via the AGPL, whereas Valkey is BSD licensed (like Redis used to be). They are both officially open source licenses, but BSD is much, much more permissive.
jillesvangurp
A very real consequence of picking that particular license by Redis Inc. is that it is completely unacceptable to users of Valkey like Google, Microsoft, Amazon, etc. That's probably intentional by Redis Inc. But it also means Valkey is going to continue to exist because its users simply require a more permissive license that allows them to run their cloud based products.
It will be interesting to see where the developer community goes but these forks have a way of becoming permanent. If you look at the Valkey Github, you'll see a lot of activity. Lots of contributors contributing lots of changes. All signs of a healthy open source community. And as the article shows, there have been some non trivial changes made to the code base that, at least temporarily, give it a bit of a lead in terms of performance. That indicates to me that there is a momentum of people maintaining it that seem to know what they are doing.
It will be interesting to see if Redis Inc. will be able to keep up/recover from this. My impression is that the community around that shrunk to basically employees of Redis Inc. when they closed source and that the rest of the community jumped ship to Valkey. Maybe some of them will go back now that they switched to AGPL. But I think Valkey is where the cloud sponsored money and action is. And there is of course more than a bit of broken trust here as well. And while AGPL is open source, I think signing agreements to give Redis Inc. the permission to re-license your contributions as they want is not something any serious open source contributor would consider.
regularjack
Why is it completely unacceptable that those trillion dollar corporations pay Redis for a licmense other than AGPL?
MangoToupe
This will help the alternative far more than redis in the short term. But the long term absolutely belongs to the AGPL.
It's simple: supporting a business without getting paid sucks ass. The second a project excludes commercial work they get 100x my attention.
meitham
Totally agree! If you don’t want AWS turning your project into a paid service without giving you a dime, you’ve got to pick a license that stops that. BSD doesn’t cut it!
networked
> It's simple: supporting a business without getting paid sucks ass. The second a project excludes commercial work they get 100x my attention.
This stance is interesting to me because it reminds me of psychological experiments about utility versus fairness. I'd like to ask you a question in that spirit.
If you could choose one of the following, which would you choose?
1. Noncommercial users gain 3× on some comprehensive metric of useful software with the source available (imagine the metric includes code quality, features, hardware support, choice, etc.), but businesses gain 10×
2. Noncommercial users gain 2×, and businesses gain 2×
3. Noncommercial users gain 1.1×, and businesses gain nothing
4. Noncommercial users gain nothing, and businesses gain nothing
5. Noncommercial users lose 3×, but businesses lose 10×
Edit: Added option 3 and renumbered the options after.
lmz
Your attention as in "your work/contribution" or just "your use"? Because if it's "your work" they'll make you sign a CLA anyway so they can sell it on and you don't get paid.
WJW
TBH I think 99% of users don't care who owns the project as long as they get their free KV store to stick data into.
From a business perspective Redis falls into this really awkward niche where its does like 50 different things but most people only use 5% of that and have no desire to use the fancy stuff like Sentinel and Streams. What's worse: when any software tool wants to start charging money for their product, the options for users are not just "stop using Redis" or "start paying". There are also the options "switch to a competitor", "rewrite it yourself with just the functionality you need" and (for OSS projects) "fork the last open source version then maintain it yourself so you don't have to pay the overhead of the OSS company". It seems to me Redis sits in a super awkward spot where forking or rolling your own is preferable to many business users. Much more so than (say) postgres, because the cheap-and-dirty version of redis is "just" a hashmap with a network interface.
tyre
For which users is it worth forking, adding features, and maintaining it is preferable?
That sounds like a high amount of effort for something that is probably non-core for that business’s users (i.e. the company is not an infra/platform company). Paying money can easily be worth the time and distraction of maintenance.
Similar to AWS. Many companies _could_ rent rackspace or linode or even ec2 instances and run on top. Services built on top like ECS and RDS are so much simpler to manage. That time, money, and focus goes elsewhere: building for users.
dgfitz
It reminds me of MOOS, for the core functionality.
motorest
> If so, is it too little, too late, to turn back the tide?
I think so too. At least to me the Redis rug pull forced Redis to be completely out of the picture, and moving forward valkey is the default option.
Fool me once, shame on you.
matsemann
I honestly think most people don't care. Yes, a HN bubble care, and might influence what a company chooses. But most people will just reach for Redis by default, none the wiser of all the drama in some small circles.
Kwpolska
Linux distros can help pick a winner. If installing Valkey is just `apt install valkey`, but Redis requires compilation/extra repos to get going, people will just choose Valkey. See also: MariaDB.
motorest
> I honestly think most people don't care.
I don't think this opinion is realistic or grounded in reality. Any company goes through license reviews when discussing which project to adopt. You may not care what software you run on a weekend project, but everyone working in a professional setting goes through a long bureaucratic song and dance act with legal representatives to verify if they can or cannot use a dependency.
ekianjo
Why would you trust Redis again after what they did?
y2244
Because if broke bad again, it could just be forked again so no risk?
CamouflagedKiwi
It's AGPL licensed now so forking it is fairly different to how it was when Valkey forked - it'll have to keep that license, and AGPL is one that quite a lot of companies don't want to touch (whether or not you think that judgement is 'correct').
mirkodrummer
antirez is it you? ;)
Aeolun
Momentum is a very scary thing. I don’t want to be trained to install valkey-server instead of redis-server again (or vice versa)
bhouston
We need to get valkey into the default distro package managers. It sucks having to add keys and update the distro get valkey installed in say a GitHub Action runner.
yjftsjthsd-h
What distro doesn't have it that you need? Skimming https://repology.org/project/valkey/versions it seems to be in nixpkgs, Arch, Ubuntu, Fedora, Debian, and EPEL. Of those, the only caveat I immediately see is that Debian only got it in 13 or 12+backports.
Hasnep
GitHub Actions runners are based on Ubuntu, and from the Repology link it seems ValKey is in the "universe" repository which is a community supported repository and therefore might not be enabled by default.
motorest
> GitHub Actions runners are based on Ubuntu (...
That sounds like a GitHub Actions problem. GitHub Actions only offers a very limited set of container images, and for Ubuntu they just go with the LTS version that shipped before Valkey even existed.
https://docs.github.com/en/actions/writing-workflows/workflo...
kijin
Redis has always been in universe as well. Most things in Ubuntu are in universe and practically unmaintained.
Getting your software into the default package managers is not necessarily the best choice for a new and fast-moving project. You'll be stuck answering bug reports for an ancient version and monkey-patching it for the life of the LTS release. It's much more ergonomic, both for maintainers and users, to run your own PPA or repo with the latest version.
skywhopper
Then the Redis that’s packaged for those versions of Ubuntu will be the BSD version... which is just an older version of Valkey.
bhouston
[flagged]
nothrabannosir
Good lesson in when not to use chatgpt.
$ docker run --rm -ti debian:trixie
root@d12c52dcfee8:/# apt-get update && apt-get install -y valkey
Get:1 http://deb.debian.org/debian trixie InRelease [178 kB]
...
root@d12c52dcfee8:/# valkey-server --version
Valkey server v=8.1.1 sha=00000000:0 malloc=jemalloc-5.3.0 bits=64 build=13683752e517a7b6hnarn
If the first thing you do in CI is adding a bunch of stuff to the container image you just pulled, you should probably make your own image.
linotype
So glad this happened and is still going strong. RIP Redis (hopefully soon).
echelon
Yes, making money is bad. Open source is only in service of the monopolies.
Only AWS and the hyperscalers deserve to make millions from Redis. Screw the Redis authors and maintainers.
Lesson to all DB startups: fair source your license. Put in anti-hyperscaler clauses into your licenses to preserve your ability to make money and be sustainable.
You can let your customers have unlimited access to your code, but stamp out the ability for AWS or Google to offer managed versions. They need to pay you.
Don't be Redis or Elasticsearch. For them it's too late. They went uber permissive and now their fate is sealed. They're hundred million dollar cash cows for the giants, and the main committers see none of that.
rvnx
I totally support antirez on this. He managed to exit with money for work that was beneficial to everyone and that stayed in the open, just as a separate fork. This is really fair. Redis had made my SRE life so much easier (in front were these horrors like memcached or Cassandra with ZK).
If that means that the package is now named Valkey this is totally fine.
BadBadJellyBean
I just don't like using a permissive open source license as a booster for your software and then changing it when others make money. Either start as a closed source/source available project or find another way to make money.
This whole "but we wanted to do a cloud offering, it's not fair that AWS/Azure/GCE make one with our software and everyone is using theirs" is just so stupid to me.
You wanted people to adopt your software. You used permissive licenses to convince people. People adopted your software probably because of the free nature of the software. Now you want to change that. Well that is just stupid.
I think that is especially true for Redis. Redis is a good software. Many integrated it but it is not irreplaceble. The idea of a KV store is not that novel.
prmoustache
Your point is a bit moot if you consider that elasticsearch is built on top of an opensource project (lucene) for which they never gave any money. Also Antirez wasn't part of Redis for a significant amount of time.
Bottom line: the company that own the brand of any open source project and receive money from support or features may not be constituted of the original authors nor is necessarily comprised of all the dev who have put a significant amount of work into it.
xorcist
While the general idea is right, maybe it's not the best example. Elastic did contribute quite a bit of code to Lucene to the point where it almost looked like a project of Elastic NV. It seems however the Apache Lucene project managed to stay untainted by it and is by any measure a very healthy and functioning open source project.
Aeolun
> Only AWS and the hyperscalers deserve to make millions from Redis.
No. Everyone deserves to, including AWS and the other hyperscalers. That is exactly what was decided by releasing it under the BSD license.
pas
and then with the new source available license a new decision was made, so for a little while AWS did not deserve to make money!? (after all when the old versions were released Antirez had no idea about how much AWS will make by running his better memcached! but, of course as Redis became a business with every new version they likely pondered this.)
then apparently the community quickly found an Uno reverse card somewhere. (so the question has become moot.)
CamouflagedKiwi
The problem is: likely they would not have been successful (or as successful as they were) if they had chosen some not-free / not-really-open-source licence from the beginning. It's unclear to me what a really good option here is.
sneak
No, nonfree licenses are bad. Nobody has any issue with people making money with free software.
We have issue with people not respecting software freedoms.
You seem to be intentionally conflating the two things.
Why make source available at all if you are just going to release proprietary software? It’s open source cosplay at that point. Just make commercial proprietary software like a normal software company; don’t pretend you are open source just because your source code is readable on GitHub.
aloha2436
> Why make source available at all if you are just going to release proprietary software?
Because there's years between one decision and the other, and in that time it turned out that because the software was open source they were structurally disadvantaged versus large cloud providers in being able to make money from it.
It seems disingenuous to suggest that the open sourcing was in bad faith given it happened years and paradigms apart from the closed sourcing, even though I don't agree with the decision either.
jillesvangurp
You are saying that like it is a bad thing. As far as I'm concerned, Valkey is a very healthy open source project with a wide range of companies and people contributing code to it and sponsoring development. None of these companies wield exclusive control over the project. And we all benefit from their work. And if I want, I can take their work and create a commercial product and try to sell it or make money of it. What's not to like there?
I don't get the anti-capitalist stance here. If you want to contribute to redis, Redis Inc. will require you to sign a contributor license agreement: https://github.com/redis/redis/blob/unstable/CONTRIBUTING.md
They'll be happy to take your work but the right to exploit it commercially is exclusive to them. That agreement (should you choose to sign it) gives them the right to take your contributions and re-license them under a proprietary license, or any license of their choosing. There's also no commitment that the code base will stay AGPL. That agreement gives them the right to do whatever. Agreements like that are very common with AGPL because it doesn't make much commercial sense to use that license without one.
> Put in anti-hyperscaler clauses into your licenses to preserve your ability to make money and be sustainable.
.. and permanently alienate the rest of the open source community from providing contributions to your project. That raises the question why you are open sourcing at all? Why would you cripple a community like that? Permissive licenses are successful because, well, they are permissive. It's why there are a lot of decades old OSS projects where the original developers and companies have long moved on, or in some cases, passed away. It doesn't matter. Because they have diverse communities that survive such things.
motorest
> Yes, making money is bad. Open source is only in service of the monopolies.
What a spin. Extortion following licensing rug pulls goes way beyond earning a living. Trying to blame victims by framing them as "monopolies" is somewhere between laughable and disingenuous. It's bold of you to make these claims in a time where everyone can verify both the licensing changes and how the whole developer community unanimously reacted to it.
> Only AWS and the hyperscalers deserve to make millions from Redis. Screw the Redis authors and maintainers.
If you pay attention, you will realize that all major Linux distros rushed to replace Redis with ValKey. Quite bold of you to claim that this licensing rug pull only affected villains.
Enough with the nonsense. If you try to abuse your users and treat everyone as a fool, don't clutch your pearls when they just drop you without a second thought.
nothrabannosir
Are you referring to people who got something completely for free as "victims" because they didn't keep getting more things for free?
It's an ironic take for a comment that uses words like "disingenuous" and "clutching pearls".
Pick a lane: either emotive arguments are in, or out. Don't accuse someone of speaking nonsense in the same comment where you claim that ceasing to provide free updates to a free product is "abuse". It's one or the other.
pipes
Recently a number of dotnet projects have gone commercial. It feels like a rug pull. I guess it is damaging for other open source dot net libraries because developers are less likely to adopt them, ie it becomes harder to get traction.
debugnik
In the particular case of .NET, that's not a recent thing. .NET businesses have always been adjacent to freeware/open-core.
pipes
I can't remember any libraries that started completely open source and free then suddenly becoming pay only. Though to be fair for some reason early in my career I didn't pay much attention to 3rd party libraries. Maybe because nuget hadn't been invented yet! :)
detail_orient
I had heard about Valkey last year and am glad is going strong!
secondcoming
Does Valkey provide their own client library?
We use Redis all over on GCP both via MemoryStore and on custom machines. We use both classic Redis and Redis Cluster.
The official C library is sadly quite deficient if you want to use Redis Cluster and then TLS. We have to use an unofficial hiredis-cluster client [0]. It's a real pain for us. We're considering moving to Scylla.
GCP's Memorystore is a joke too.
michael_grunder
Yes, there is a combined fork of hiredis and hiredis-cluster called libvalkey.
It is maintained by many of the same people who have maintained hiredis and hiredis-cluster.
y2244
Now that Redis have u-turned, is it not worth Valkey and Redis having a chat and seeing if they can merge and combine their efforts?
paulryanrogers
It's not really a U-turn because they haven't returned to their original license. More of a tack by moving to AGPL.
kamikazechaser
As usual, I expect some GPL FUD. Here is a good explainer on it. https://drewdevault.com/2024/04/19/2024-04-19-Copyleft-is-no...
TheBicPen
The argument in the post that copyleft licenses are freer seems handwavy at best. In a literal sense, obligations are restrictions on freedom, so yes, copyleft licenses are less free than permissive ones. Whether or not the overall benefits of said obligations outweigh their restrictions on freedom is a question worth discussing, but it's irrelevant to the question of which style of license is freer.
bofaGuy
I run Redis across dozens of applications. So when Valkey became available for a discounted price on AWS I was excited. We finally got around to trying it out about 2 months ago and all was going well. No noticeable difference in performance. Until Valkey just died. It died in such a way that AWS still thought it was running happily but it was completely offline. It took 12+ hours for it to come up again and then it happened again... AWS researched the issue for 2 weeks and couldn't figure it out. It will be a long time before we attempt to use Valkey for anything critical in the future. We since have replace that Valkey with Redis under the same workload and have no issues.
neepi
Probably AWS issue. Our production RDS postgres cluster did that a few months back. Just stopped responding on the network. Health checks were fine. AWS support was mostly useless and couldn't work it out in an hour, despite having their top tier enterprise support, so with customers down we had to create a whole new cluster and do a restore from backup which took 4 hours.
RDS is now gone. It's on a couple of EC2 instances with replication, hourly EBS snapshots and daily shipping to S3.
I'm loathed to use AWS's "encapsulated" services for anything since.
Aeolun
I think these are isolated incidents though. We’ve ran several tens of RDS clusters for 6 years running, and nothing has ever gone wrong. Maybe the ap-northeast-1 region is well maintained?
sampullman
Could that be an AWS operational issue, and not related to Valkey?
I only run redis myself but wouldn't immediately place blame on Valkey if that happened.
ummonk
Yeah I don't understand how something could be "completely offline" and still have health checks passing.
motorest
"completely offline" also doesn't sound like a problem with a software project. At best it's a particular managed service experiencing downtime. Would Linux be to blame if my power supply goes up in smoke?
bofaGuy
It’s a bit confusing to me exactly what went wrong. I think that when you have a redis/valkey cluster with multiple nodes and you use the cluster uri, there must be some kind of load balancer or custom routing. When we would attempt to connect to valkey the connection would look good, but when we would submit commands to it they would never execute. We had written our application so that it would operate with no issue (just slower) if the cache goes down. In this case, connections looked good but no work was actually being done. AWS support suggested we restart the nodes but because they were not responding they never shut down … or at least it took a really long time. They were never able to tell us what actually happened. My guess is that valkey command execution got stuck somehow but was still able to create new connections.
Aeolun
Can’t be reached outside the network that the instance and health check are running on? Maybe available in one AZ, but not on the one that’s trying to connect.
perfectra1n
“Completely offline” and passing health checks don’t typically go together…
xenator
Why you don't just run new instance with your own Valkey?
samtheprogram
Because when you’re in production with many users, it’s not worth the risk when you’ve already been burned, especially when the downside is a small discount.
ramraj07
The aws managed cache offerings are not just a small premium, they're like 10x more expensive than the ec2 instance types they represent.
lpa22
What instance types were you using, just for reference?
nwlotz
I'm curious, why hasn't Valkey picked up corporate sponsors to the degree OpenTofu did when HashiCorp changed Terraform's licensing? I just haven't seen a meaningful level of reaction compared to the community outcry when Hashi changed to BSL.
motorest
> I'm curious, why hasn't Valkey picked up corporate sponsors to the degree OpenTofu did when HashiCorp changed Terraform's licensing?
You seem to be completely out of the loop. Valkey is backed by AWS, Google Cloud, Oracle, etc. If I recall correctly, a principal engineer from AWS was spearheading the project.
Twirrim
Valkey has lots of corporate sponsors, including Amazon, Oracle, Google, Percona, and Ericsson. It's a also under the Linux Foundation and will get support and coverage from there (which in turn is sponsored by even more large companies)
apgwoz
Probably because Terraform’s value was always the community of providers and modules, and that was in danger.
Where as, Redis/Valkey’s ecosystem exists mainly as advocacy and happy users. It might be central to an architecture, sure, but using a previously open sourced version was unlikely to cause considerable problems.
Contrast to potential huge changes to the BUSL’d terraform that create incompatibility with existing providers would lock you in to HashiCorp’s new, unfavorable, terms.
sofixa
> Probably because Terraform’s value was always the community of providers and modules, and that was in danger.
It was never in danger, the providers remained under MPL and were explicitly excluded from the licensing change, with a good associated explanation (most of them were developed by and with partners and the community, unlike Terraform core which was almost entirely HashiCorp).
apgwoz
The providers need a “driver.” Without that, they aren’t very useful as is. That’s the danger. (Yes, pulumi, etc)
Additionally, HashiCorp changed the terms of service on the registry, making it only acceptable to use the official terraform binaries to download modules or providers.
Now, the providers are mostly open source, so, it was never impossible to recreate the thing—just work. But the point here is that Hashicorp took steps that caused the community of terraform users to recognize that closing off the ecosystem would have a tremendous impact on devops.
That’s why there was so much outrage and immediate action taken.
wyldfire
Isn't Valkey endorsed/promoted by LF? Probably at the behest of redis customers unhappy about the license change.
I'm happy ValKey did great work in the area of I/O threading, and we started to incorporate the most interesting changes recently: a big thank you to all the ValKey contributors that did great work.
However, this article is a bit misleading:
>Antirez’s emphasis on a shared nothing architecture has been foundational for Redis. Nevertheless, as early as 2020, Redis added support for I/O threads. Unfortunately, they did not offer drastic improvement until recently. If you have previously tried and discarded I/O threads, it is time to evaluate again!
Please note that is that same Antirez that implemented I/O threading in 2020, exactly because it does not violate the same reasons why I believe in shared nothing.
<technical background>
What I/O threading does, is, when we return from the event loop, to recognized that write(2) / read(2) syscalls are very slow, and in that moment we have zero contention, so what about parallelizing in N threads just that I/O, and returning single threaded immediately after? So I implemented this system, and the ValKey folks did the awesome job of making it better (thanks again).
</technical background>
But it is not true that the system didn't work back then, even if now it was improved, as you can see from the graph in the article itself... I wonder if those posts are payed by somebody or what. There are similar non-sensical posts in the Redis side as well, and they suck likewise, blabling about random things. WTF... What a disservice is this kind of journalism.
Anyway, one reason why these stuff are interesting mostly for Redis the company itself, Amazon, Google, and only marginally for normal Redis users, that is in turn the reason why the feature is not so used, is that if you don't have many users in the same machine or you don't see extremely high loads in specific circumstances, you usually don't need to enable it. Many users of Redis, even big users (I remember the numbers of a few very popular social networks) have their Redis CPU usages low enough to don't bother.
Btw about threads, there are times when they simply fit. If you see my latest work at Redis, the new vector set data type, well, queries are threaded by default, and you can even use VADD (so writing to a vector set) in a threaded way. Why I changed my mind? Because HNSWs are the first data structures with huge constant times, Redis never had something like that, and this changed the design space that was worth considering. So in 2020 I was already positive about threads, in the past I already had implemented the threaded support for moduels operation, and now vector sets are threaded. It is not about being pro or against, it depends.