[NEW] support redis 7

The problem/use-case that the feature addresses

multiple feature of redis 7 like :

Cluster: Support for hostnames, instead of IP addresses only -> redis/redis#9530

are not yet part of keyDB , is there a roadmap to support redis 7 features ? thanks

Yes, we want to do this for early Q3. It takes about a month to complete the merge so it's a large time investment.

@JohnSully

@JohnSully, any ETA on when this could be expected?

@JohnSully

So... on KeyDB website it states:

KeyDB works to maintain parity with features and updates in the upstream Redis codebase. In general we attempt to perform these upstream merges quarterly.

On April it's going to be a year since Redis 7.0 is out. And still no info on whether this is even planned

@JohnSully what happened to Q3 ?

Yes, we want to do this for early Q3. It takes about a month to complete the merge so it's a large time investment.

@JohnSully

It looks like @JohnSully has been busy working on some other component for Snap.
#494 (comment)

I'd be interested in an update about whether this might be coming in the next 6 months?

Hi,
Is there any update when this merge is expected?
Thanks,

any update？

Any updates?

Any news?

@JohnSully

@JohnSully just wondering if the Redis 7.0 merge is going to happen this year 2023. We are interested in some of the Redis 7.0 ACL features.

We are running Debian 12 which brings Redis 7.0 by default. We would like to migrate to KeyDB. However, due to the lack of compatibility we are unable to migrate without losing all data from Redis. Unfortunately starting with a clean DB is not acceptable. Please advise.

Reading dump.rdb or connecting as replica to Redis both lead to crash of KeyDB with error message "Can't handle RDB format version 10 / Fatal error loading the DB: Invalid argument. Exiting." Such restriction is not mentioned in https://docs.keydb.dev/docs/migration

We would love to switch to KeyDB but need option support on the EXPIRE command (NX, XX, GT & LT). Any news on this would be amazing. Thank you.

@JohnSully

@JohnSully - any update on this?

@JohnSully

There have not been any major upgrades for more then 2 years now.
@JohnSully can you please confirm (or deny and if whats the timeline) KeyDB is dead?

@ddevault

The project would of course welcome outside help and we can certainly name additional maintainers if there is community interest in helping.

There's another project that has sprung up recently. It seems like the best of all worlds if redict and keydb could ultimately work together on this: https://codeberg.org/redict/redict

Perhaps @ddevault would be a good candidate for this, given his contributions to redict? Maybe redict could become the new upstream for KeyDB, if an outright merger isn't in the cards?

Hi,

I understood until now that keydb is not going anywhere, but the release of v7(that have nice feature like be able to monitor streams lag of consumer) may not be here any time soon as there is not ETA for it.

i come across with the following article:
https://techcrunch.com/2024/03/31/why-aws-google-and-oracle-are-backing-the-valkey-redis-fork/?guccounter=1

"The Linux Foundation last week announced that it will host Valkey, a fork of the Redis in-memory data store. Valkey is backed by Amazon Web Services, Google Cloud, Oracle, Ericsson and Snap."

Is this Snap the same Snap that is now behind/hosting KeyDB? And assuming yes, is this changing the plans for keydb?

pretty sure it is the same Snap Inc and read somewhere that features & efforts might influence and potentially make it into ValKey 🥳

yes it's snap inc

https://www.linuxfoundation.org/press/linux-foundation-launches-open-source-valkey-community

ok, but in that case what can we expect from KeyDB, i mean, Snap is now backing up 2 key store DBs that are a fork from redis?

And if Valkey is also backed up by big players as AWS or google, what can we expect to happen to keyDB in the middle/long run?

There was another ticket open where I mentioned that KeyDB isn't staffed to be the "new Redis" and so we are not trying to compete in that space. This is where Valkey is competing.

However KeyDB has never existed in a vacuum there have always been bigger scoped projects to draw on. We are focussed on a few core features not in either Valkey or the previously open source Redis:

Better vertical scaling with multithreading
Support for FLASH and tiered storage

Right now Valkey doesn't have those features and Snap needs those - we have many 500+ node clusters and its simply impractical to x8 them using single threaded instances. FLASH is still not quite prod ready due to its performance but is getting close in the async_flash branch and we are continuing to guide that through. Once we have use cases running well on it we will do a new KeyDB release including this technology.

As for Snap supporting both Valkey and KeyDB, in the early days Redis never allowed us to upstream either of the two technologies because it competed with their commercial business. Valkey will hopefully be more pragmatic and I would love to see some of our efforts merged. There is a lot of work to do before that can happen and KeyDB development will continue in the meantime.

While I expect the code bases of KeyDB and Valkey to get closer together with time I still hope for KeyDB to be the place where experiments and new features can happen and get proven out. The refusal to merge needed features really held Redis back and this is an important relief valve for innovation to happen.

If there is a key feature in Redis 7 you are missing I am happy to merge it so you can get it sooner.

@JohnSully

Thanks for the reply @JohnSully

Btw keyDB multithreading is still a x8 performance improvement compared to redis 7 ?

@JohnSully

Hi @JohnSully,

Thanks for your time and efforts, on my side:

Capability to measure consumer lag on a stream, as is we can not monitoring streams, if messages are being lost for example if we have slow clients, this is important to understand, is our stream the right size to accommodate spikes? arae the clients reading fast enough? in redis 7 XINFO GROUPS added a new lag parameter, something that i personally think essential.
The BUG i opened [BUG] keydb gets extremely slow when master is not available #613, there was no feedback, so i dont know if it was solved in more recent versions, but assuming its a bug and not bad config, it jeopardize HA 2 nodes with replication when 1 goes down.

The answers to this would make me very happy :)

@JohnSully

Hi @JohnSully,

Do you have an idea if what i "requested" is possible? more important the first point related with streams monitoring?
The second sadly i m not able to reproduce anymore :(

Thanks,

It would be nice to be redis 7 "compatible", now is replacing it also a lot harder ;)

It would be nice to have this information front-and-center on the KeyDB documentation. I spent a lot of time learning about, installing, and attempting to migrate to KeyDB only to find that bridging RDB 10 to RDB 9 is a PITA and KeyDB does not have the developer resources to keep up with Redis.

I created a PR to add this to the KeyDB documentation page for migrating from Redis to KeyDB:

Snapchat/KeyDB-docs#71

If Snap does not have financing for KeyDB, what about launching a hosted service by the project creators? Dragonfly has a Cloud service, and it seems to be able to finance that project quite well. Given the very similar nature of the two project (Redis-compatible, multithreaded), I think that it would be a viable financing option for KeyDB too.

@notramo

@notramo yes Dragonfly as the 2 main features of KeyDB ( multithreading and Data Tiering )

( even if redis since version 7 is way more efficient since there is Multiplexing )

#895

Navigation Menu

Repository navigation

[NEW] support redis 7 #420

3 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[NEW] support redis 7 #420

Description

Activity

JohnSully commented on May 13, 2022

MagicKriss commented on Nov 7, 2022

MagicKriss commented on Jan 24, 2023

TomHellier commented on Feb 22, 2023

cjabrantes commented on Mar 21, 2023

wacdev commented on Apr 19, 2023

vainkop commented on May 23, 2023

the-wondersmith commented on Jun 9, 2023

iabramov commented on Jun 15, 2023

javedsha commented on Sep 26, 2023

neonknight commented on Jan 11, 2024

violuke commented on Jan 27, 2024

Jarod1662 commented on Feb 1, 2024

chibisuke commented on Mar 20, 2024

3 remaining items

vwbusguy commented on Mar 21, 2024

cjabrantes commented on Apr 5, 2024

CanRau commented on Apr 14, 2024

raphaelauv commented on Apr 15, 2024

cjabrantes commented on Apr 16, 2024

JohnSully commented on Apr 16, 2024

raphaelauv commented on Apr 16, 2024

cjabrantes commented on Apr 17, 2024

cjabrantes commented on May 20, 2024

jogoossens commented on Sep 24, 2024

jspinella commented on Oct 10, 2024

notramo commented on Nov 6, 2024

raphaelauv commented on Nov 6, 2024

raphaelauv commented on Feb 17, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions