[HN Gopher] Valkey Is Rapidly Overtaking Redis
       ___________________________________________________________________
        
       Valkey Is Rapidly Overtaking Redis
        
       Author : CrankyBear
       Score  : 38 points
       Date   : 2024-04-19 22:08 UTC (52 minutes ago)
        
 (HTM) web link (devops.com)
 (TXT) w3m dump (devops.com)
        
       | paxys wrote:
       | Good. I hope Redis Labs dies a slow death for stealing the
       | project from the community.
        
         | kawsper wrote:
         | There's something wrong at Redislabs, it took them over a year
         | to get RESP3 rolled out into their hosted service, you'd expect
         | a rollout of that to be a bit quicker when they're the owner of
         | Redis.
         | 
         | It affected us when upgrading Sidekiq to version 7, which
         | dropped support for older Redis, and their Envoy proxy setup
         | didn't support HELLO and RESP3:
         | https://github.com/sidekiq/sidekiq/issues/5594
        
       | xmprt wrote:
       | The biggest mistake Redis Labs made was doing a rebrand at the
       | exact same time as a license change. Usually you want rebrands to
       | be loud and well known and license changes to be silent and
       | ignored until it's too late and people have adopted the new
       | license. In this case, they loudly announced that they're making
       | an unpopular change and it gave everyone the will to switch.
        
         | ok_dad wrote:
         | I'm amazed that they thought that they could do this and get
         | away with it. Redis is almost a foundational tool for modern
         | caching architectures. Every company I've ever worked at used
         | redis like candy to cache stuff that wasn't important enough
         | for the reliable but expensive and slow data stores.
         | Additionally, the main features 99% of people want and need
         | have been in redis for a decade. Even a fork that only fixed
         | security bugs will have done better than Redis Labs after this
         | debacle. It's like if the author of nano, the text editor,
         | would try this license change. I suspect this will be much like
         | the {open/libre}office changeover. Maybe soon 'apt get redis'
         | and others will be aliased to Valkey.
        
           | crabmusket wrote:
           | > Even a fork that only fixed security bugs will have done
           | better than Redis Labs after this debacle
           | 
           | This describes Redict, not Valkey. I think it's actually
           | great we have two forks, so they can focus on different
           | things.
        
       | Thaxll wrote:
       | "Rapidly", so most people don't even know the story about Redis
       | changes and I would say 99.99 never heard about Valkey.
        
         | Osiris wrote:
         | I was aware of the license change but not of the forks. Now I
         | am.
        
       | hipadev23 wrote:
       | Is there any reason I don't just stick with redis 7.2.4 instead
       | of trusting redict/valkey to not inject some backdoor trash? I
       | can avoid the corporate pivot and the random fork at the same
       | time.
        
         | wmf wrote:
         | One is maintained and the other isn't. If you don't care about
         | that you could definitely stick with the old version.
        
           | hipadev23 wrote:
           | Redis hasn't materially changed since about 2.8 so tbh
           | unmaintained is more than fine.
        
         | mrd3v0 wrote:
         | This new narrative makes it as if backdoors started existing
         | the moment xz happened. As if that wasn't always a threat, and
         | that xz more than anything did prove that free software is a
         | lot more resilient than to suffer similar attacks that have
         | happened and will continue to happen without public
         | acknowlegement or as much publicity in unfree software/SaaS.
        
       | simonw wrote:
       | One of the challenges Redis labs here have is that there's very
       | little reason for their userbase to stay loyal to them.
       | 
       | antirez retired from Redis development a few years ago.
       | 
       | From https://github.com/redis/redis/graphs/contributors it looks
       | like activity since he left has been mostly from people who
       | didn't overlap with him much.
       | 
       | Redis Labs have not shown themselves to be outstanding stewards
       | of the project as far as I can tell. Why shouldn't people support
       | the fork?
        
       ___________________________________________________________________
       (page generated 2024-04-19 23:00 UTC)