sled VS KeyDB

How do you compare this to sled? https://github.com/spacejam/sled

Sled uses bw-tree actually https://github.com/spacejam/sled/wiki/sled-architectural-outlook

There is a valid argument to be made for threads over async in a large percentage of use cases where async is considered the default. If this is what you are referring to however, I don't think they ever referred to async as completely useless: https://github.com/spacejam/sled/issues/1123.

Have you looked into other pure-Rust databases as well, such as sled or GlueSQL which has an SQL interface on top of sled? I wonder how those would compare to Persy.

I'm not sure what you need. Are these of any use? https://github.com/meilisearch/heed https://github.com/spacejam/sled

There is also Sled but as I understand it that is being reworked to use the author's new DB core Marble

There are some databases like sled/FlashDB designed to be embedded to other applications even bare metal microcontrollers. But I do doubt the potential bussiness value of a pure embedded database.

I think this is relevant... These are 3 OSS databases that can be an alternative to Redis:

- KeyDB: https://github.com/snapchat/keydb

- Dragonfly: https://github.com/dragonflydb/dragonfly

- Skytable: https://github.com/skytable/skytable

I have used keyDB before. The raft consensus makes building an HA Redis easy.

To me it's still not clear if 6.3.x is stable (https://github.com/Snapchat/KeyDB/issues/494) and performant (https://github.com/Snapchat/KeyDB/issues/470).

- KeyDB: https://github.com/snapchat/keydb

KeyDB is a fork of (everyone's favourite cache store) Redis, and it's messaging protocol and API is 100% compatible with Redis. What that means is you can just point any Redis client (like Hiredis or redis-rb) at a KeyDB instance, and it'll Just Work™️, with no changes required. The KeyDB selling points are: 1) multi-threading by default, and a lot of work was ploughed in to high performance around multi-threading in KeyDB, 2) compatible with all the features of regular Redis, 3) some advanced features which Redis only offers in it's paid/enterprise version are included for free in KeyDB, and the big one for me is multi-active replication, which is what I'm playing with here.

KeyDB is a multithreading, drop-in alternative to Redis. Keydb-operator easily creates a standalone (1 replica) or a multimaster (3 replicas) KeyDB in-memory database. When KeyDB is in multimaster mode, it is possible to have more than one master, allowing read/write operations to all them. That helps for high availability and fault tolerance.

Have you checked https://keydb.dev/

p.s. another share-worthy Redis alternative is KeyDB https://github.com/EQ-Alpha/KeyDB

I went through the wiki, certainly it was interesting. I believe the implementation is at fastlock.cpp [0], I will go through it. You said earlier:

> If we spin too long the thread will sleep although we wait much longer than any other lock you’ll find.

Did you do any tweaks to mitigate this?

> Generally speaking you don't want to be dealing with this stuff unless you really have to.

Ofcourse. I am just way too curious and excited to learn about these!

[0] - https://github.com/EQ-Alpha/KeyDB/blob/v6.0.16/src/fastlock....