Top all-time · #13571
EloqData Blog
Company blog · eloqdata.com/blog · on HN as hubertzhangdatasystems
EloqData Blog is the company blog at eloqdata.com, writing about data and systems. Since 2024, 5 different Hacker News readers have linked it 19 times, most often “Don't Split My Data: I Will Use a Database (Not PostgreSQL) for My Data Needs”. It is still writing: the last post was on 2026-07-17, and you can follow it by feed.
Too few sampled comments (1) to say how often HN recommends it.?
Why HN links it
The linked EloqData blog covers EloqDoc, a MongoDB-compatible document database that uses object storage as its primary durability layer, and related EloqKV work.
Summarised by Claude from a sample of 1 HN comments that link here. Each comment is marked recommending, critical or neutral (citing without judging); how this works.
EloqData builds Redis-compatible and multi-model databases that move large stateful workloads from expensive DRAM to NVMe and object storage.
Most-linked posts?
- /blog/2025/07/14/technology2 people · 4 mentions · first linked 2025-08-19
- /blog/2025/07/16/data-substrate-benefit2 people · 3 mentions · first linked 2025-07-31
- Don't Split My Data: I Will Use a Database (Not PostgreSQL) for My Data Needs2 people · 2 mentions · first linked 2025-11-10
What Hacker News says?
I’m the co-founder of EloqData. I recently gave a talk on EloqDoc and Pulsar integration at Data Streaming Summit 2025. It was a great event, and Ursa was definitely one of the hottest topics discussed. I believe object storage is shaping the future architecture of cloud databases. The first big shift happened in the data warehouse space, where we saw the move from Teradata and Greenplum to Snowflake accelerate arou…
Comment linking /blog/2025/07/16/data-substrate-benefit
on “Ursa: A leaderless, object storage–based alternative to Kafka”Submitted Why we develop EloqDB mainly in C++ as a story · 58 points
HN discussionYes, 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.
Comment linking /blog/2025/07/14/technology
on “EloqKV, a distributed database with Redis compatible API (GPLv2 and AGPLv3)”Submitted Show HN: EloqKV – Scalable distributed ACID key-value database with Redis API as a story · 44 points
HN discussionTiKV 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…
Comment linking /blog/2025/07/14/technology
on “EloqKV, a distributed database with Redis compatible API (GPLv2 and AGPLv3)”Submitted Postgres is reliable – I'll persist in EloqKV as a story · 3 points
HN discussionThe 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/…
Comment linking /blog/2025/07/14/technology
on “EloqKV, a distributed database with Redis compatible API (GPLv2 and AGPLv3)”Submitted Why We Develop EloqDB Mainly in C++ as a story · 2 points
HN discussionReally 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 (internal…
Comment linking /
on “EloqKV, a distributed database with Redis compatible API (GPLv2 and AGPLv3)”Submitted EloqKV: Achieving Predictable P99.99 Latency on NVMe with Redis API as a story · 1 points
HN discussionThese are great questions. I appreciate you carefully reading through the documents. For the first question, we have detailed benchmark on EloqKV, with the same architecture (but with Redis API) in our blog, and we will soon publish more about the performance characteristics of EloqDoc. Overall, we achieve about the same performance as using local NVME SSD, even when we use S3 as the primary storage, and the perform…
Comment linking /blog/2025/07/16/data-substrate-benefit
on “Show HN: EloqDoc: MongoDB-compatible doc DB with object storage as first citizen”Submitted Don't Split My Data: I Will Use a Database (Not PostgreSQL) for My Data Needs as a story · 1 points
HN discussionVery cool! Using “object storage for primary durability” seems difficult for any OLTP workload that’s latency-sensitive - there’s a fundamental tradeoff between larger batch sizes to control write costs and smaller batches to reduce latency. This hurts OLTP workloads especially badly because applications often make multiple small writes to serve a single user-facing request. How does EloqKV navigate this tradeoff? A…
Comment linking /blog/2025/07/15/data-substrate-detail
on “Show HN: EloqDoc: MongoDB-compatible doc DB with object storage as first citizen”Submitted I Will Use a Database (Not PostgreSQL) for My Data Needs as a story · 1 points
HN discussionThat's exactly the reason. S3 is better in almost all aspects compared with EBS, except the performance part, and I am glad that our Data Substrate technology solved this issue gracefully [1]. As for the compatibility, we are leveraging some of the code from 4.03 version (the last AGPL version), and we have a very good compatibility (we will show some results in later blog posts). As I mentioned in another reply pos…
Comment linking /blog/2025/07/16/data-substrate-benefit
on “Show HN: EloqDoc: MongoDB-compatible doc DB with object storage as first citizen”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 b…
Comment linking /blog/2025/07/14/technology
on “Show HN: EloqDoc: MongoDB-compatible doc DB with object storage as first citizen”Good question! WAL and TxService(TxMap) are fully decoupled, allowing you to deploy them on the same node or across different machines. If your workload is write-intensive, you might consider a large WAL cluster, which leverages multiple disks to perform fsync operations in parallel. This is particularly important in cloud environments, where local SSDs are ephemeral and cloud-native databases often use EBS for WAL.…
Comment linking /blog/2024/08/25/benchmark-txlog
on “Show HN: EloqKV – Scalable distributed ACID key-value database with Redis API”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 ba…
Comment linking /blog/2024/08/22/benchmark-cluster
on “Show HN: EloqKV – Scalable distributed ACID key-value database with Redis API”