Cool to see such a high throughput number with distributed cluster support
EloqKV, a distributed database with Redis compatible API (GPLv2 and AGPLv3)
21–30 of 46 posts
Re: EloqKV, a distributed database with Redis compatible API (GPLv2 and AGPLv3)
#22Earlier quoted context omitted.
The same way you accept any contribution, because it isn't technically relicensing. You already granted them an AGPLv3 license when you uploaded your change to github without modifying the license file - that's what the "or" in the file means [1] - which entitles them (and anyone else) to create and distribute derivative works under only the AGPLv3 without any GPLv2 grant... [1] Quoting the license file: This softwar…
As a contributor, couldn’t I use it under the terms of the GPL and make GPL-licensed derivative works and ignore their AGPL nonsense? If it is GPL then I understand that I am under no obligation to license my contributions under AGPL. I am not a lawyer; this is not legal advice.
That’s right. You can simply choose GPL and ignore the AGPL part for EloqKV. The reason we use both is that, in other projects, we need to support both GPL and AGPL. EloqKV and all its dependencies are either developed by us or licensed under more permissive terms, so you can choose either license. However, EloqDoc is under AGPL (https://github.com/eloqdata/eloqdoc) and we cannot relicense it under GPL because it includes some AGPL-licensed code from MongoDB.
Re: EloqKV, a distributed database with Redis compatible API (GPLv2 and AGPLv3)
#23It's weird that they don't mention similar distributed NewSQL databases like TiKV, which also has a MySQL layer (TiDB), and position themselves as a Redis replacement.
TiKV is a great project and we have a lot of respect for their work. EloqKV is based on a very different architecture [1], and we also have MySQL compatible [2] and MongoDB compatible [3] databases build on top of the same architecture. They all inherit the extreme performance, scalability, fault tolerance, and ACID properties due to the common underpinning.
[1] https://www.eloqdata.com/blog/2025/07/14/technology
Re: EloqKV, a distributed database with Redis compatible API (GPLv2 and AGPLv3)
#24Really appreciate it. I am the CEO of EloqData. We submitted the ShowHN about a year ago [1]. Since then we made a lot of progress, much of the work is based on the feedback from the great HN community, including: 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 (internall…
Very interesting project. Couple of notes: * 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.
Great question. Currently, the database landscape is very fragmented. We are faced with a multitude of database choices (different ACID guarantees, data modalities, scalability, and so on). Data pipeline become very complicated, and we believe there must be a better solution. That’s why we developed a common architecture called DataSubstrate and built different APIs on top of it. EloqKV with a Redis API is just one of them; we also provide a MySQL-API RDBMS and a MongoDB-API JSON database (both open-sourced). Our goal is to create the next-generation database foundation to support the growing demand from new generation of applications. We believe future AI agent-driven applications will generate huge volumes of queries and data that will be difficult to handle with existing solutions.
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.
Re: EloqKV, a distributed database with Redis compatible API (GPLv2 and AGPLv3)
#25Earlier quoted context omitted.
Titan/Tidis (the redis compatible servers built on top of TiKV) don't seem to have any recent activity in their public repos: - https://github.com/yongman/tidis - https://github.com/distributedio/titan 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).
A person who wants transactions and a relational layer isn't going to use KVRocks, but sure, if you only care about the key-value part. I gave tikv/tidb as an example; there are others. 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.
Some Redis variants focus on persistence—KVrocks, for example, or MemoryDB, which emphasizes durability through redo logs to minimize data loss. However, they are not truly transactional, since they lack fundamental rollback semantics and distributed transaction.
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.
Re: EloqKV, a distributed database with Redis compatible API (GPLv2 and AGPLv3)
#26I have tested EloqKV for a pet project and seems it is quite solid. Performance is fantastic, far out-performing most databases with durability by a large margin. I am not sure about the distributed transaction correctness but all my tests seem to indicate it works as advertised, which is very interesting because the other distributed NewSql databases are all rather slow. Haven't tried their SQL and Mongo solutions, but they also look quite interesting.
Re: EloqKV, a distributed database with Redis compatible API (GPLv2 and AGPLv3)
#27I like the idea, KV store but not a memory store with Redis simplicity
Yes, we found it to be very useful for things that require durability and transactions. Previously we use JuiceFS community edition with Redis as metadata backend. The main issues are 1) potential metadata loss and 2) Memory capacity limit. We tried EloqKV and it seems to work really well. Anybody use EloqKV in production yet?
Re: EloqKV, a distributed database with Redis compatible API (GPLv2 and AGPLv3)
#28It's weird that they don't mention similar distributed NewSQL databases like TiKV, which also has a MySQL layer (TiDB), and position themselves as a Redis replacement.
I have tried TiKV and TiDB but they are quite slow. EloqKV is much faster, especially for in-memory reads. I use it to replace KVRocks, which is just a single node KV store wrapper around RocksDB with a Redis API, and EloqKV nicely outperforms it.
Re: EloqKV, a distributed database with Redis compatible API (GPLv2 and AGPLv3)
#29Isn’t Redis already a distributed database with Redis Cluster?
Re: EloqKV, a distributed database with Redis compatible API (GPLv2 and AGPLv3)
#30Isn’t Redis already a distributed database with Redis Cluster?
I’m Hubert, CTO of EloqData. That’s a great question.
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.