eloqdata

Thank you so much for reporting this! My local testing on Chrome privacy mode was fine, but we will definitely prioritize checking and fixing the issue in Firefox's Strict Privacy Mode.

That is right. We leverage some of the AGPL MongoDB code for the parser, as indicated by the License. Our own code can be licensed differently, see a previous discussion on Hacker News [1]. The Mongo API are reasonably stable over the last few years, only seeing very minor changes. Most of the later versions improved upon performance and transactions, which we support natively with our underlying technologies. Still, if you have any specific API that you feel is needed, we'd be happy to implement and we welcome community contributions.

[1] https://news.ycombinator.com/item?id=44937978

That’s correct. FerretDB and DocumentDB both pursue PostgreSQL-based document models.

EloqDoc follows a fundamentally different architectural path. Instead of executing in Postgres, we leverage the existing MongoDB parser and executor to ensure maximum compatibility. Our main contribution is to replace the single-writer WiredTiger storage engine entirely with Data Substrate.

The Data Substrate is an abstract layer built specifically to handle distributed database fundamentals: scalable buffer pooling, concurrency control, durability, elasticity, and fault tolerance. You can read more: https://www.eloqdata.com/blog/2025/07/14/technology

This architectural choice is what enables EloqDoc to deliver features that Postgres-based solutions cannot easily match, including: full compatibility, native Multi-Writer capability, Object Storage First and extremely low-latency distributed transactions.

Yes, this is exactly the typical use case where EloqDoc shines.

Our auto-tiering feature allows you to manage a massive database (e.g., 5TB+) primarily on cheap, durable object storage (like S3), which is already built for cross-AZ replication and is up to 3x cheaper than traditional cloud block storage (EBS).

We use local NVMe SSDs (200K+ IOPS) purely as a high-performance cache layer to accelerate read access. Hot and cold data are automatically swapped across memory, SSD, and object storage tiers based on access frequency, ensuring high performance (up to 100x faster than archive solutions)

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.

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.

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

[2] https://github.com/eloqdata/eloqsql

[3] https://github.com/eloqdata/eloqdoc

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.

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/14/technology

[2] https://github.com/eloqdata/eloqsql

[3] https://github.com/eloqdata/eloqdoc

Really 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 (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

[2] https://www.eloqdata.com/blog/2025/07/14/technology

[3] https://eloqdata.com

Why? Honestly, there are already tons of Model-as-a-Service (MaaS) platforms out there—big names like AWS Bedrock and Azure AI Foundry, plus a bunch of startups like Groq and fireflies.ai. I’m just not seeing what makes Cerebrium stand out from the crowd.

Thank you for the insightful reply. I agree, Redis's transaction API ("MULTI/EXEC/DISCARD/WATCH") is challenging compared to SQL's familiar "START/COMMIT/ROLLBACK," and it has key limitations:

1. No rollback on failure: If a command in EXEC fails, Redis can't roll back the transaction. EloqKV resolves this by starting real transactions on the TxServer node during EXEC. If any command fails, the changes are rolled back, maintaining atomicity. Additionally, EloqKV allows specifying isolation levels when using Redis transactions.

2. Lack of interactivity: This is where Lua shines. Users can embed business logic in Lua, functioning similarly to stored procedures in SQL.

3. No cross-shard transactions: Redis clusters can't redirect requests across shards, forcing clients to manage topology awareness. EloqKV addresses this with a fully distributed transactional design, eliminating these cross-shard complexities. For more on this, see our blog.

https://www.eloqdata.com/blog/2024/08/22/benchmark-cluster#w...

As for your point on Lua's risks in multi-tenant environments, I completely agree. Lua lacks robust ACLs or resource limitations, and managing SHA keys is cumbersome. We're considering enhancements to address these issues in the future. Finally, we are indeed working on a "real" transaction API for Redis. Like SQL, users will be able to begin transactions, read keys, apply transformations, and generate new keys, with the ability to commit or abort. EloqKV will also support configurable isolation levels and transaction protocols (OCC/Locking).

Do you have any additional API preferences beyond "START/COMMIT/ROLLBACK" for Redis transactions?

Thank you, Andy! This is Jeff, CEO and Chief Architect of EloqData. It's a great honor for us to have THE Andy Pavlo join the discussion on our first HN submission.

If I remember correctly, NuoDB uses a shared cache with a cache coherence protocol, whereas EloqKV uses a shared nothing (partitioned) cache. The former is a local read but needs to broadcast each write to all nodes. The latter has no broadcast for writes but may be a remote read. The tradeoff is evident and we are actively exploring opportunities to strike a balance, e.g., for frequently-read, rarely-write data items, use the shared cache mode.

We appreciate you pointing us to the CIDR paper. I had the pleasure of working with Phil for some time and fondly remember many discussions with Phil on various topics many years ago. To address your question, yes, we've been trying to solve the research challenges presented in the CIDR paper. The devil is in the details. We've developed numerous new algorithms and invested significant engineering effort into the design and implementation of our products. The benefits are as follows:

- Optimality: We believe we have an overall design that optimizes synchronous disk writes and network round-trips. For instance, when the design is reduced to a single node, its performance matches or exceeds that of single-node servers. As you might expect, a lot of innovation has gone into making distributed transactions as efficient as non-distributed ones, comparable to those in MySQL or PostgreSQL.

- Modularity: Our architecture allows us to easily replace the Parser/Compute layer and Storage/Persistence layer with the best existing solutions. This means we can create new databases by leveraging existing parsers and compute engines from current database implementations to achieve API-compatibility, as well as leveraging existing high-performance KV stores for the persistence layer. This allows us to avoid reinventing the wheels and to take advantage of decades of innovations in the database community.

- Scalability: The entire system operates without a single synchronization point—not even a global sequencer. We drew many inspirations from the Hekaton and your TicToc paper. All four types of resources (CPU, Memory, Storage, Logging) can be scaled independently, as we mentioned earlier. More importantly, they can scale dynamically to accommodate workload changes without service disruptions.

We look forward to sharing more technical details as we move out of stealth mode. I hope to continue this conversation with you in person in the near future.