[HN Gopher] Valkey Turns One: Community fork of Redis
___________________________________________________________________
Valkey Turns One: Community fork of Redis
Author : cebert
Score : 236 points
Date : 2025-05-30 22:24 UTC (1 days ago)
(HTM) web link (www.gomomento.com)
(TXT) w3m dump (www.gomomento.com)
| bhouston wrote:
| 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 wrote:
| 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 wrote:
| 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.
| kijin wrote:
| 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.
| bbarnett wrote:
| For users? Hardly.
|
| 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.
| kijin wrote:
| 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.
| bbarnett wrote:
| Debian's contrib and non-free are similar, only 'main' is
| rigorously shepherded.
| motorest wrote:
| > 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...
| Kwpolska wrote:
| You can use any Docker container to run your Actions.
| skywhopper wrote:
| Then the Redis that's packaged for those versions of Ubuntu
| will be the BSD version... which is just an older version
| of Valkey.
| LukeShu wrote:
| FWIW, valkey has replaced redis in Arch Linux.
| jdmarble wrote:
| And will in RHEL 10, too!
| hnarn wrote:
| 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.
| bofaGuy wrote:
| 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.
| sampullman wrote:
| 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 wrote:
| Yeah I don't understand how something could be "completely
| offline" and still have health checks passing.
| perfectra1n wrote:
| "Completely offline" and passing health checks don't
| typically go together...
| motorest wrote:
| "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?
| Aeolun wrote:
| 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.
| bofaGuy wrote:
| 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.
| xenator wrote:
| Why you don't just run new instance with your own Valkey?
| samtheprogram wrote:
| 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 wrote:
| The aws managed cache offerings are not just a small
| premium, they're like 10x more expensive than the ec2
| instance types they represent.
| postalrat wrote:
| Its more but I doubt its 10x or even close to that.
| amazingman wrote:
| It's not even 2x. I spot checked 2 instance types and
| they were 36% and 69% more.
| lpa22 wrote:
| What instance types were you using, just for reference?
| neepi wrote:
| 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 wrote:
| 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?
| nwlotz wrote:
| 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.
| apgwoz wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| sofixa wrote:
| > 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.
| apgwoz wrote:
| > 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...
| wyldfire wrote:
| Isn't Valkey endorsed/promoted by LF? Probably at the behest of
| redis customers unhappy about the license change.
| Twirrim wrote:
| 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)
|
| https://valkey.io/participants/
| motorest wrote:
| > 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.
|
| https://valkey.io/participants/
| linotype wrote:
| So glad this happened and is still going strong. RIP Redis
| (hopefully soon).
| echelon wrote:
| 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.
| sneak wrote:
| 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 wrote:
| > 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.
| growse wrote:
| > 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.
| rvnx wrote:
| 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.
| motorest wrote:
| > 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 wrote:
| 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.
| motorest wrote:
| > Are you referring to people who got something
| completely for free as "victims" (...)
|
| Anyone subjected to a bait-and-switch is a victim. It
| means nothing if the bait was free.
| prmoustache wrote:
| > Are you referring to people who got something
| completely for free as "victims" because they didn't keep
| getting more things for free?
|
| What about the third party dev who contributed to the
| code on the basis it was open source?
| paulryanrogers wrote:
| They probably should not have signed a CLA?
| nothrabannosir wrote:
| 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>".
| Aeolun wrote:
| > 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 wrote:
| 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.)
| jillesvangurp wrote:
| 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.
| CamouflagedKiwi wrote:
| 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.
| prmoustache wrote:
| 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 wrote:
| 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.
| BadBadJellyBean wrote:
| 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.
| geerlingguy wrote:
| Didn't antirez announce Redis was going (actual) open source
| again?
|
| 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.
| motorest wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| gkbrk wrote:
| Or better, if installing valkey is both `apt install
| valkey` and also `apt install redis`. Which is exactly
| what some distros are doing.
| fnord123 wrote:
| 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.
| motorest wrote:
| > 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.
| williamstein wrote:
| 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.
| MangoToupe wrote:
| 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 wrote:
| 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 wrote:
| > 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 3x 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 10x
|
| 2. Noncommercial users gain 2x, and businesses gain 2x
|
| 3. Noncommercial users gain 1.1x, and businesses gain
| nothing
|
| 4. Noncommercial users gain nothing, and businesses gain
| nothing
|
| 5. Noncommercial users lose 3x, but businesses lose 10x
|
| Edit: Added option 3 and renumbered the options after.
| lmz wrote:
| 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.
| jillesvangurp wrote:
| 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 wrote:
| Why is it completely unacceptable that those trillion
| dollar corporations pay Redis for a licmense other than
| AGPL?
| Kwpolska wrote:
| 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?
| motorest wrote:
| > 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.
| xorcist wrote:
| 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").
| ekianjo wrote:
| Why would you trust Redis again after what they did?
| y2244 wrote:
| Because if broke bad again, it could just be forked again so
| no risk?
| Aeolun wrote:
| 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)
| WJW wrote:
| How often do you (re)install redis-server for this to be
| a problem? It's just a thing you type once in a build
| script for me.
| CamouflagedKiwi wrote:
| 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 wrote:
| antirez is it you? ;)
| WhyNotHugo wrote:
| 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.
| WJW wrote:
| 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.
| dgfitz wrote:
| It reminds me of MOOS, for the core functionality.
| tyre wrote:
| 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.
| kamikazechaser wrote:
| 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 wrote:
| 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.
| y2244 wrote:
| 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 wrote:
| It's not really a U-turn because they haven't returned to their
| original license. More of a tack by moving to AGPL.
| pipes wrote:
| 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 wrote:
| In the particular case of .NET, that's not a recent thing. .NET
| businesses have always been adjacent to freeware/open-core.
| pipes wrote:
| 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! :)
| antirez wrote:
| 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.
| christophilus wrote:
| Thanks, antirez. Nuance doesn't get clicks.
| ignoramous wrote:
| > _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.
|
| 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.
|
| https://bcantrill.dtrace.org/2018/12/14/open-source-
| confront...
| bgwalter wrote:
| Cantrill is partially wrong:
|
| https://www.theregister.com/2025/05/01/redis_returns_to_ope
| n...
|
| "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 wrote:
| 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.
|
| [0] https://en.wikipedia.org/wiki/Tall_poppy_syndrome
| detail_orient wrote:
| I had heard about Valkey last year and am glad is going strong!
| secondcoming wrote:
| 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.
|
| [0] https://github.com/Nordix/hiredis-cluster
___________________________________________________________________
(page generated 2025-05-31 23:02 UTC)