Most Redis alternatives that use disk for persistence struggle with tail latency (P9999) due to background maintenance or OS filesystem overhead. We built EloqKV on a custom storage engine, EloqStore, to solve this.
Key Architectural Choices:
- Custom B-tree Variant: Unlike LSM-trees used in many disk-backed stores, our B-tree variant avoids the "compaction stalls" that typically cause high tail latency during heavy writes.
- Coroutines & io_uring: We leverage io_uring for asynchronous I/O and use coroutines to manage thousands of concurrent I/O requests without the context-switching overhead.
- Object Storage Integration (optional): EloqStore uses object storage as the primary persistent layer, with NVMe acting as a high-speed cache/tier, providing durability without sacrificing speed.
We’ve reached a point where we can provide predictable P99.99 latency even when the working set is primarily on NVMe. We’d love to answer any questions about the storage internals or our benchmarking process.
Yesterday I posted a Show HN introducing our MongoDB-compatible database EloqDoc (https://news.ycombinator.com/item?id=45634638
).
Today’s AWS us-east-1 outage was a strong reminder of why relying on local NVMe as primary database storage is risky—and why OLTP databases should consider object storage as the durable foundation instead.
A recent hacker-news argues: “Redis is fast — I’ll cache in Postgres.” The author benchmarks a simple API and concludes that although Redis is faster, Postgres is “fast enough,” and removing another component can be worth it for many projects.(https://news.ycombinator.com/item?id=45380699)
I agree with two things:
- Postgres is an excellent, reliable database.
- Fewer moving parts is a win—when the workload fits.
But there’s a third path that many teams overlook: a Redis-compatible database that is durable by default. That’s what we built with EloqKV—Redis protocol + redo log, multi-writer, transactions, persistence, durability, store procedure—so you get database + cache in one engine.