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.
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.
Bryan Cantrill on this:
... 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.
"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.
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.
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.
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.
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.
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.
Good question and one that bears repeating. Because if you desire the aspect of free software or open source that is a level playing field, where no vendor has any special status or secret sauce, which in turn is what enables vendors to submit new features to a multi vendor codebase instead of maintaining private branches.
We learned this from X11 and the Unix wars, and history repeats itself in the countless free-core-but-proprietary-enterprise-features projects that never really expand beyond their parent corporation.
This is why trillion dollar corporations must not have special rules and the playing field must be even to any use, despite how unintuitive it may feel. Someone tried to codify it early as the first of the four software freedoms (the keyword being "anyone").
> Why is it completely unacceptable that those trillion dollar corporations (...)
The Redis licensing rug pull affects the whole community, not just strawmen villains. Random weekend warriors who occasionally spin up a container might not care. Anyone who trusted a FLOSS project to play a key role in their company's infrastructure will unavoidable have risk mitigation meetings where the name Redis is brought up.
Those corporations are direct competitors of Redis Inc. in the "managed Redis in the cloud" space. Would Redis be willing to sell licenses to them? Would they be reasonably priced?
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!
> 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.
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.
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.
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.
I mean exactly companies like AWS and Azure, who are basically in the business of renting out hardware with custom software pre-installed. Paying licensing fees for hundreds of thousands of Elasticache users might very well be more expensive than having a 3-4 people team maintaining their own Redis fork.
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.
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.
Is there a useful metric to see if that's really the case? Using the distos package manager means you're at the mercy of the packager for getting new versions. Docker is just as easy and doesn't suffer from this. And building from source gives you full control.
Even when using test services, using docker works best since all the Devs will be on the same version instead of splitting between Debian, fedora, and brew versions.
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.
All of the cloud providers are already in on BSD-licensed Valkey, so which community is realistically going to take over AGPL Redis next time around? The much smaller group of Redict proponents?
There's only so much manpower to go around and much of it is otherwise preoccupied now.
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').
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.
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.
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.
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.
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.
If you want stable, you want a non-changing branch with security fixes only. No surprises, no api changes, no config file changes.
And you don't want to be stuck on a non-security fix version. You cannot sit on the same version without tracking security, while you slowly retool and recode for breaking api/behaviour changes.
Debian stable has redis, and others, and will see backported security updates for the life of the support window.
This isn't just about redis. If you're doing this with anything, you must track secuirty updates, must stay up to date, or you are negligent. And tracking changes for infra stuff like redis, and other backend stuff is a waste of resources with typically zero benefit.
I won't touch core daemons like redis, if it isn't distro maintained. I have better things to do. More important things to worry about.
You're right about Debian. Ubuntu is a different story. You're probably better off using an alternative repository for anything important that you find in the "universe" repo. That stuff is not "distro-maintained" at all.
Case in point: there are known vulnerabilities in the version of Redis shipped with Ubuntu 22.04 LTS, which a lot of people would assume is still maintained. But Redis is in universe, so patches are only available for those with an Ubuntu Pro subscription.
Only a small number of packages in Debian belong in contrib and non-free. Redis is safely in main.
Ubuntu throws 90% of its packages in universe and doesn't even bother to pull security fixes from Debian. It's absolutely irresponsible and not comparable to Debian at all.
It seems like it went over your head that the package name is valkey, not valkey-server, so the instructions won't work. Why paste a long faulty AI response instead of linking to the concise official documentation?
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.
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.
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.
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.
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.
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.)
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.
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.
> 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.
> 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.
The problem here is that their actions are indistinguishable from an entity that is acting in bad faith. "Get loads of free labour, then claim ownership of it and try to monetize" is a business strategy.
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?
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.
> 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.
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.
My point isn’t “there is no perspective from which you can call anyone here a victim”. It is: “If it’s fair for you to use language like ‘victim’, then it’s fair for others to use sarcasm to make their point, and you can’t complain about it being ‘spin.’”
Original GPs comment was justifiable if you allow emotive hyperbole. “Spin”. Op disagreed with the point made by GP but addressed the form in which it was made, over the actual content, while themselves using the same style. That’s not fair. Be consistent: are we being hyperbolic or are we being literal?
I’m not even taking sides on the actual redis issue. “Trust was breached”? Can’t argue with that: licenses don’t cover trust and implicit agreements. But then say that, don’t say “you’re wrong for spinning things, but also <spin>”.
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.
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! :)
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.
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.
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.
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.
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?
"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?
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.
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.
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.
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.
> 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.
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)
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.
> 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).
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.
> 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.
Why would HashiCorp provide free hosting of providers and modules for projects competing, using HashiCorp's own code at that? Multiple entire companies exist doing little more than providing wrappers around stuff HashiCorp develops. HashiCorp has no obligation to give them everything so they have an easier time at undercutting them (because they don't have to actually develop the main stuff).
> 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.
The community of people using alternative products off HashiCorp's efforts, code, and money. Terraform Community Edition is still free and usable for anyone as long as you don't sell it to compete with HashiCorp.
> Why would HashiCorp provide free hosting of providers and modules for projects competing, using HashiCorp's own code at that?
If you recall, my point is that “providers were in danger,” and this is a reason in support of that. HashiCorp, of course, has no obligation to host providers for competitors. But, this is one more reason OpenTofu succeeded!
> Terraform Community Edition is still free and usable for anyone as long as you don't sell it to compete with HashiCorp.
Except, it’s rather unclear what “compete with HashiCorp” means, and there’s very little assurance that if you stick with terraform community edition you won’t get screwed over and be forced to pay in 6 months.
You can make all the arguments about “needing to make money”, “free loaders”, etc. HashiCorp is not unique in changing licenses and getting backlash.
But, as someone who joined HashiCorp, in part, because of our open source strategy, and hearing over and over, for years, how it was the reason we were so successful…
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.
Not any random ensemble of "Valkey contributors" that did async IO but AWS: One of those cloud providers Redis moved away from FOSS for.
Bryan Cantrill on this: https://bcantrill.dtrace.org/2018/12/14/open-source-confront...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.
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.
[0] https://en.wikipedia.org/wiki/Tall_poppy_syndrome
https://antirez.com/news/151
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.
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.
We learned this from X11 and the Unix wars, and history repeats itself in the countless free-core-but-proprietary-enterprise-features projects that never really expand beyond their parent corporation.
This is why trillion dollar corporations must not have special rules and the playing field must be even to any use, despite how unintuitive it may feel. Someone tried to codify it early as the first of the four software freedoms (the keyword being "anyone").
The Redis licensing rug pull affects the whole community, not just strawmen villains. Random weekend warriors who occasionally spin up a container might not care. Anyone who trusted a FLOSS project to play a key role in their company's infrastructure will unavoidable have risk mitigation meetings where the name Redis is brought up.
Why is it so unacceptable that they choose to collaborate on something completely Open Source instead (Valkey)?
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.
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.
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.
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.
Even when using test services, using docker works best since all the Devs will be on the same version instead of splitting between Debian, fedora, and brew versions.
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.
There's only so much manpower to go around and much of it is otherwise preoccupied now.
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...
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.
If you want stable, you want a non-changing branch with security fixes only. No surprises, no api changes, no config file changes.
And you don't want to be stuck on a non-security fix version. You cannot sit on the same version without tracking security, while you slowly retool and recode for breaking api/behaviour changes.
Debian stable has redis, and others, and will see backported security updates for the life of the support window.
This isn't just about redis. If you're doing this with anything, you must track secuirty updates, must stay up to date, or you are negligent. And tracking changes for infra stuff like redis, and other backend stuff is a waste of resources with typically zero benefit.
I won't touch core daemons like redis, if it isn't distro maintained. I have better things to do. More important things to worry about.
Case in point: there are known vulnerabilities in the version of Redis shipped with Ubuntu 22.04 LTS, which a lot of people would assume is still maintained. But Redis is in universe, so patches are only available for those with an Ubuntu Pro subscription.
Ubuntu throws 90% of its packages in universe and doesn't even bother to pull security fixes from Debian. It's absolutely irresponsible and not comparable to Debian at all.
https://claude.ai/share/ba9ecc54-5f21-4ec5-ab36-88e8eac38d1a
https://valkey.io/topics/installation/
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.
If that means that the package is now named Valkey this is totally fine.
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.
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.
No. Everyone deserves to, including AWS and the other hyperscalers. That is exactly what was decided by releasing it under the BSD license.
then apparently the community quickly found an Uno reverse card somewhere. (so the question has become moot.)
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.
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.
The problem here is that their actions are indistinguishable from an entity that is acting in bad faith. "Get loads of free labour, then claim ownership of it and try to monetize" is a business strategy.
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.
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.
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.
What about the third party dev who contributed to the code on the basis it was open source?
Original GPs comment was justifiable if you allow emotive hyperbole. “Spin”. Op disagreed with the point made by GP but addressed the form in which it was made, over the actual content, while themselves using the same style. That’s not fair. Be consistent: are we being hyperbolic or are we being literal?
I’m not even taking sides on the actual redis issue. “Trust was breached”? Can’t argue with that: licenses don’t cover trust and implicit agreements. But then say that, don’t say “you’re wrong for spinning things, but also <spin>”.
Anyone subjected to a bait-and-switch is a victim. It means nothing if the bait was free.
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.
[0] https://github.com/Nordix/hiredis-cluster
It is maintained by many of the same people who have maintained hiredis and hiredis-cluster.
https://github.com/valkey-io/libvalkey
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.
I only run redis myself but wouldn't immediately place blame on Valkey if that happened.
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.
https://valkey.io/participants/
https://valkey.io/participants/
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.
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).
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.
Why would HashiCorp provide free hosting of providers and modules for projects competing, using HashiCorp's own code at that? Multiple entire companies exist doing little more than providing wrappers around stuff HashiCorp develops. HashiCorp has no obligation to give them everything so they have an easier time at undercutting them (because they don't have to actually develop the main stuff).
> 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.
The community of people using alternative products off HashiCorp's efforts, code, and money. Terraform Community Edition is still free and usable for anyone as long as you don't sell it to compete with HashiCorp.
If you recall, my point is that “providers were in danger,” and this is a reason in support of that. HashiCorp, of course, has no obligation to host providers for competitors. But, this is one more reason OpenTofu succeeded!
> Terraform Community Edition is still free and usable for anyone as long as you don't sell it to compete with HashiCorp.
Except, it’s rather unclear what “compete with HashiCorp” means, and there’s very little assurance that if you stick with terraform community edition you won’t get screwed over and be forced to pay in 6 months.
You can make all the arguments about “needing to make money”, “free loaders”, etc. HashiCorp is not unique in changing licenses and getting backlash.
But, as someone who joined HashiCorp, in part, because of our open source strategy, and hearing over and over, for years, how it was the reason we were so successful…