[akshayshah]

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

Also, I’d love to see:

- A benchmark that digs into latency, throughput, and cost for a single workload. Most of the benchmarks I saw are throughput-only.

- Some explanation of the “patented 1PC protocol.” Your website [1] suggests that you treat single EBS volumes as high-durability, replicated storage, which seems unusual to me - apart from io2 volumes, EBS is designed for less than 3 nines of durability [2].

[1]: http://www.eloqdata.com/blog/2025/07/15/data-substrate-detai...

[2]: https://aws.amazon.com/ebs/features/

[iamlintaoz]

These 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 performance often exceed the original database implementation (in the case of EloqDoc, original MongoDB).

As for the durability part, our key innovations is to split state into 3 parts: in memory, in WAL, and in data storage. We use a small EBS volume for WAL, and storage is in S3. So, durability is guaranteed by [Storage AND (WAL OR Mem)). Unless Storage (S3) fails, or Both WAL (i.e. EBS lost) AND Mem fail (i.e. node crash), persistence is guaranteed. You can see the explanation in [1]

[1] https://www.eloqdata.com/blog/2025/07/16/data-substrate-bene...