[benwilber0]

Your company invested hundreds of engineering hours switching from Redis to a clean fork of Redis?

[cogman10]

I can easily see this for a midsize company.

While it's likely an easy process to drop in valkey, creating the new instances, migrating apps to those new instances, and making sure there's not some hidden regression (even though it's "drop in") all takes time.

At a minimum, 1 or 2 hours per app optimistically.

My company has hundreds of apps (hurray microservices). That's where "hundreds of hours" seems pretty reasonable to me.

We don't have a lot of redis use in the company, but if we did it'd have taken a bit of time to switch over.

Edit: Dead before I could respond but I figured it was worthwhile to respond.

> It's literally just redis with a different name, what is there to test?

I've seen this happen quite a bit in opensource where a "x just named y" also happens to include tiny changes that actually conflict with the way we use it. For example, maybe some api doesn't guarantee order but our app (in a silly manor) relied on the order anyways. A bug on us, for sure, but not something that would surface until an update of redis or this switch over.

It can also be the case that we were relying on an older version of redis, the switchover to valkey necessitates that we now bring in the new changes to redis that we may not have tested.

These things certainly are unlikely (which is why 1 or 2 hours as an estimate, it'd take more if these are more common problems). Yet, they do and have happened to me with other dependency updates.

At a minimum, simply making sure someone didn't fat finger the new valkey addresses or mess up the terraform for the deployment will take time to test and verify.

[rlpb]

> My company has hundreds of apps (hurray microservices). That's where "hundreds of hours" seems pretty reasonable to me.

Sounds like a huge disadvantage in your company’s choice of software architecture to me.

[JamesSwift]

My understanding is that Valkey was forked directly from redis. So assuming you migrate at the forks point-in-time, then it literally is the same code.

[txcwg002]

I believe it. There are companies that invested hundreds of engineering hours to rename master to main.

[xandrius]

That is even more ridiculous, at least switching to a clean fork of Redis has business reasons. Following the latest cultural fads, less so.

[patates]

One would find it hard to believe how often we hardcoded "master" to every corner of the software that ever touches any VCS.

[brookst]

At the very least you have to validate everything that touches redis, which means finding everything that touches redis. Internal tools and docs need to be updated.

And who knows if someone adopted post-fork features?

If this is a production system that supports the core business, hundreds of hours seems pretty reasonable. For a small operation that can afford to YOLO it, sure, it should be pretty easy.

[benwilber0]

But why are they spending any time switching away from Redis at all unless they are a hosting provider offering Redis-as-a-service?

I wasn't aware the license had any negative affect on private internal use.

[md3911027514]

By switch I mean that all new projects use Valkey instead of Redis, and we've invested hundreds of hours into those new projects.

[mperham]

There are companies using many thousands of Redis instances storing petabytes of data with millions of users.

Now consider a no-down-time migration. How long do you think that'll take to engineer and execute?

[dbacar]

Even the infrastructure switch and testing should take a lot of time, yet the application level tests etc.