KVRocks (which _is_ mentioned) does, as does valkey (also not mentioned, but probably only because it's not that different from redis at this point IIUC).
Writing your own Redis-like interface is trivial, so tidis et al don't matter to me. Even with Redis you should write an interface so you can swap it out.
EloqKV, by contrast, is fully transactional. It supports distributed Lua, MULTI/EXEC, and even SQL-style BEGIN/COMMIT/ROLLBACK syntax. This means you get the transactional guarantees of a database with Redis-level read performance. Writes are slightly slower since EloqKV ensures durability, but in return you gain full ACID safety. Most importantly, you no longer need to worry about cache coherence issues between a Redis cache and a separate SQL database—EloqKV unifies them into a single, reliable system.
[1] https://www.eloqdata.com/blog/2025/07/14/technology
1) Open Source (GPL and AGPL) (thanks PeterZaitsev).
2) Session based transaction in Redis API. (thanks fizx)
3) Better explanation of the architecture [2] (thanks apavlo).
4) Testing with Jepsen (internally, we will do it officially when we have the resource) (thanks jacobn, among others).
Again, thanks, really appreciate the community support. Please go to our website [3] or join our discord channel to provide more feedback.
[1] https://news.ycombinator.com/item?id=41590905
* What is the back story here? Why create this in the first place?
* Seems like it's less performant than Dragonfly. Why not consolidate effort and help Dragonfly instead?
* To ride the AI wave, y'all need to gain Vector related features, similarity search, etc.
EloqKV is only slightly slower than Dragonfly—about 10–20%—but for good reason. Dragonfly is a pure in-memory database with a highly optimized network layer and a very specialized design. EloqKV, on the other hand, is a full-featured database with all the checkboxes you can think of: fully consistent, durable, distributed transactions, fault-tolerant, tiered storage, and more. Despite this, we incur very little overhead compared with state-of-the-art, purpose-built databases when we have the same workload guarantee. Our thesis is that we may not need dedicated specialized solutions if we can achieve comparable performance (and cost) with general-purpose systems.
We will also add vector support very soon. Please stay tuned.
Redis Cluster is often thought of as a distributed database, but in reality it’s not truly distributed. It relies on a smart client to route queries to the correct shard—similar to how mongos works in MongoDB. This design means Redis Cluster cannot perform distributed transactions, and developers often need to use hashtags to manually place related data on the same shard.
EloqKV takes a different approach. It’s a natively distributed database with direct interconnects between nodes. You can connect to any node with a standard Redis client, and still read or write data that physically resides on other nodes. This architecture enables true distributed transactions across shards, fully supporting MULTI/EXEC and Lua scripts without special client logic or manual sharding workarounds.
Could you share a bit more about your specific use case? That will help me explain how EloqKV can best support it.
The use case is straightforward: each tenant has cached objects like: `cache:{tenant_id}:{object_id} → cached JSON/doc`
I also maintain a tag index to find all object IDs with a given tag: `tag:{tenant_id}:{tag} → set of object_ids (tag example: “pricing”, “profile”)`
When a tag changes (say “pricing”), I use a single Lua script to look up all object IDs in the tag set and then delete their cache entries in one atomic operation.
yjftsjthsd-h•5mo ago
gpm•5mo ago
I don't know that's the plan, but it's the best reason I see to dual license like this.
wahnfrieden•5mo ago
gpm•5mo ago
[1] Quoting the license file:
This software is provided under a dual license. You may choose to use it under the terms of either:
1. GNU General Public License, Version 2 (GPLv2), or
2. GNU Affero General Public License, Version 3 (AGPLv3).
sneak•5mo ago
I am not a lawyer; this is not legal advice.
gpm•5mo ago
Presumably they aren't going to merge any changes that drop the AGPL license...
Also not a lawyer.
actionfromafar•5mo ago
iamlintaoz•5mo ago
sitkack•5mo ago
EloqKV deployed on cloud is the same version hosted on github (the AGPL requires that users of EloqKV in your cloud service be available.
If you are taking AGPL licensed pull requests you can incorporate source from Aerospike and ScyllaDB (pre-relicense).
traceroute66•5mo ago
IANAL, but dual licensing with two conflicting syles of license just stinks of something that will come back and bite them in the backside big-time in the future.
From a purely practical perspective it is also not clear what the point is ? Because quite clearly the people you want to be subject to AGPL (i.e. the big-evil cloud providers) will simply take you at your word and run under GPL.
iamlintaoz•5mo ago
[1] https://www.eloqdata.com/blog/2025/07/14/technology
[2] https://github.com/eloqdata/eloqsql
[3] https://github.com/eloqdata/eloqdoc
coolspot•5mo ago
wavemode•5mo ago
In that case, a user wanting to distribute eloqdata and eloqdoc together need only adhere to the AGPL, not both licenses.
the_precipitate•5mo ago
I doubt they would accept any code that cannot be re-licensed, because the common layer essentially “transmits the infection,” for lack of a better way to describe it.