Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

EloqKV, a distributed database with Redis compatible API (GPLv2 and AGPLv3)

github.com

Post reply on HN
Print view View original

31–40 of 46 posts

Re: EloqKV, a distributed database with Redis compatible API (GPLv2 and AGPLv3)

#31

Post by iamlintaoz »

fluxkernel wrote: post #27
srameshc wrote: post #10

I 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?

Thank you. Indeed we do already have several large multi-national companies using EloqKV in their production environments. Please contact us if you have any further questions. Moreover, we would be really interested to hear more details about your usage scenario. Metadata store for JuiceFS is a very interesting use case for us.

Re: EloqKV, a distributed database with Redis compatible API (GPLv2 and AGPLv3)

#32

Post by hodr_super »

hubertzhang wrote: post #30
hodr_super wrote: post #29

Isn’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 sam…

Distributed Lua is cool. Is your implementation similar to DragonflyDB, which doesn’t allow handling undeclared keys in Lua? For example, if I want to generate a new key dynamically inside a script like: `local queue_key = "queue:user:" .. uid` How does your system handle such cases?

Re: EloqKV, a distributed database with Redis compatible API (GPLv2 and AGPLv3)

#33

Post by hubertzhang »

hodr_super wrote: post #32
hubertzhang wrote: post #30

Earlier quoted context omitted.

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 sam…

Distributed Lua is cool. Is your implementation similar to DragonflyDB, which doesn’t allow handling undeclared keys in Lua? For example, if I want to generate a new key dynamically inside a script like: `local queue_key = "queue:user:" .. uid` How does your system handle such cases?

Yes, Lua in EloqKV has no such limitations. You can freely read data, generate new keys, and even query those keys within Lua scripts. Underneath, EloqKV’s transaction layer is powered by our data substrate, which provides full ACID guarantees. FYI https://www.eloqdata.com/blog/2025/07/14/technology

Could you share a bit more about your specific use case? That will help me explain how EloqKV can best support it.

Re: EloqKV, a distributed database with Redis compatible API (GPLv2 and AGPLv3)

#34

Post by hodr_super »

hubertzhang wrote: post #33
hodr_super wrote: post #32

Earlier quoted context omitted.

Distributed Lua is cool. Is your implementation similar to DragonflyDB, which doesn’t allow handling undeclared keys in Lua? For example, if I want to generate a new key dynamically inside a script like: `local queue_key = "queue:user:" .. uid` How does your system handle such cases?

Yes, Lua in EloqKV has no such limitations. You can freely read data, generate new keys, and even query those keys within Lua scripts. Underneath, EloqKV’s transaction layer is powered by our data substrate, which provides full ACID guarantees. FYI https://www.eloqdata.com/blog/2025/07/14/technology Could you share a bit more about your specific use case? That will help me explain how EloqKV can best support it.

I built a SaaS app with per-tenant caches. Initially I used Redis but ran into scale-up issues, so I tried DragonflyDB. It works well in general, but my Lua script use case isn’t supported by default.

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.

Re: EloqKV, a distributed database with Redis compatible API (GPLv2 and AGPLv3)

#35

Post by netpaladinx »

fluxkernel wrote: post #27
srameshc wrote: post #10

I 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?

We’ve been using EloqKV to replace one of our largest Redis node (we didn’t want to run Redis Cluster, just a single big node). One pain point we had with Redis was the RDB fork causing latency jitter during persistence. EloqKV handles this much better — the fork-related stalls are gone, and so far it’s been a smooth drop-in replacement for our workload.

Re: EloqKV, a distributed database with Redis compatible API (GPLv2 and AGPLv3)

#36

Post by hubertzhang »

hodr_super wrote: post #34
hubertzhang wrote: post #33

Earlier quoted context omitted.

Yes, Lua in EloqKV has no such limitations. You can freely read data, generate new keys, and even query those keys within Lua scripts. Underneath, EloqKV’s transaction layer is powered by our data substrate, which provides full ACID guarantees. FYI https://www.eloqdata.com/blog/2025/07/14/technology Could you share a bit more about your specific use case? That will help me explain how EloqKV can best support it.

I built a SaaS app with per-tenant caches. Initially I used Redis but ran into scale-up issues, so I tried DragonflyDB. It works well in general, but my Lua script use case isn’t supported by default. 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 o…

That use case aligns perfectly with EloqKV’s capabilities. In pure cache mode, batching multi-key deletions within Lua scripts can significantly reduce latency by minimizing client–server round trips.

Re: EloqKV, a distributed database with Redis compatible API (GPLv2 and AGPLv3)

#37

Post by coolspot »

iamlintaoz wrote: post #19
yjftsjthsd-h wrote: post #2

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). You may use, copy, modify, and distribute this software under the terms of either license, at your option. The full text of both licenses is included below for reference. IANAL, but isn't GPLv2 strictly more p…

The reason is because we use a layer (our main innovation) called DataSubstrate to build modular databases that support distributed transactions [1]. Because we use some MariaDB code (GPLv2) and some MongoDB code (AGPLv3) in our other projects [2] [3], so we license our DataSubstrate code to be compatible with both, and therefore, we also license EloqKV under both licenses. [1] https://www.eloqdata.com/blog/2025/07/1…

I don’t think end users can pick a license because you have pieces licensed under GPLv2 and AGPLv3 . They will have to obey by both, which is tricky if they are conflicting.

Re: EloqKV, a distributed database with Redis compatible API (GPLv2 and AGPLv3)

#38

Post by wavemode »

coolspot wrote: post #37
iamlintaoz wrote: post #19

Earlier quoted context omitted.

The reason is because we use a layer (our main innovation) called DataSubstrate to build modular databases that support distributed transactions [1]. Because we use some MariaDB code (GPLv2) and some MongoDB code (AGPLv3) in our other projects [2] [3], so we license our DataSubstrate code to be compatible with both, and therefore, we also license EloqKV under both licenses. [1] https://www.eloqdata.com/blog/2025/07/1…

I don’t think end users can pick a license because you have pieces licensed under GPLv2 and AGPLv3 . They will have to obey by both, which is tricky if they are conflicting.

I don't think he's saying that eloqdata itself contains AGPL code from Mongo. Rather, their other project, eloqdoc, contains AGPL code from Mongo, and a user might want to integrate the two, so for simplicity eloqdata is offered under both licenses.

In that case, a user wanting to distribute eloqdata and eloqdoc together need only adhere to the AGPL, not both licenses.

Re: EloqKV, a distributed database with Redis compatible API (GPLv2 and AGPLv3)

#40

Post by sitkack »

iamlintaoz wrote: post #22
sneak wrote: post #11

Earlier quoted context omitted.

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 i…

Would you accept AGPL licensed pull requests?

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).

Post reply on HN