Hi!

On Fri, 2024-03-22 at 12:35:47 +0000, Chris Lamb wrote:
> > I'm CCing Chris, who might perhaps be interested in replacing Redis with
> > KeyDB as its spiritual successor and taking this on? Or if not, at least
> > to perhaps potentially coordinate some kind of transition, even though
> > we've had issues migrating persistent DBs from newer Redis to KeyDB, so
> > that might be tricky or not feasible at all.
> 
> Thanks for including me here. I had not yet looked into potential
> Redis replacements nor the exact and precise details of the new
> license etc. and this activity around KeyDB feels like a good start.
> I thought I'd let the dust settle for a bit before making any
> decisions — perhaps the change even gets reversed (!), and no doubt
> there might be new alternatives that will fork the code immediately
> prior to the license change.

Yeah, fair enough.

> My personal and professional usage of Redis has dropped off in the
> past few years, so it would make more sense for me to help out in a
> team maintainership role, at least with respect to KeyDB.

Ack.

> However, I'd be interested in coordinating around some kind of
> Redis→KeyDB/something transition if need be.

For KeyDB, that would also depend on whether KeyDB adds Redis 7 support
or not I guess.

  https://github.com/Snapchat/KeyDB/issues/420

and if that does not materialize, a potential migration path via:

  https://github.com/Snapchat/KeyDB/issues/527#issuecomment-1370606311

In our, case we migrated from Redis 6 to KeyDB, so the above did not
really affect us.

> (Incidentally, why did your work switch to KeyDB?)

We did this several years ago, AFAIR mainly for its active-active
replication mode for our HA setup. The multi-threading was a nice
improvement too. And I cannot recall exactly, but I think at that
time Redis Inc was already going into a weird licensing path with
its other adjacent projects, so we might have taken that too as a
nice side effect to get away from.

Thanks,
Guillem

Reply via email to