I cannot pull images from docker hub.
Readit Newshubertzhang commented on AWS multiple services outage in us-east-1 health.aws.amazon.com/hea... · Posted by u/kondro
hubertzhang commented on Ask HN: Genesis DB: Thoughts on fine-grained access control · Posted by u/patriceckhart
Like AWS, json is OK for me
hubertzhang commented on Postgres is reliable – I'll persist in EloqKV eloqdata.com/blog/2024/08... · Posted by u/hubertzhang
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.
Any thoughts?
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.
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.
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.
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 same shard.
EloqKV takes a different approach. It’s a natively distributed database with direct interconnects between nodes. You can connect to any node with a standard Redis client, and still read or write data that physically resides on other nodes. This architecture enables true distributed transactions across shards, fully supporting MULTI/EXEC and Lua scripts without special client logic or manual sharding workarounds.
A person who wants transactions and a relational layer isn't going to use KVRocks, but sure, if you only care about the key-value part. I gave tikv/tidb as an example; there are others.
Writing your own Redis-like interface is trivial, so tidis et al don't matter to me. Even with Redis you should write an interface so you can swap it out.
Some Redis variants focus on persistence—KVrocks, for example, or MemoryDB, which emphasizes durability through redo logs to minimize data loss. However, they are not truly transactional, since they lack fundamental rollback semantics and distributed transaction.
EloqKV, by contrast, is fully transactional. It supports distributed Lua, MULTI/EXEC, and even SQL-style BEGIN/COMMIT/ROLLBACK syntax. This means you get the transactional guarantees of a database with Redis-level read performance. Writes are slightly slower since EloqKV ensures durability, but in return you gain full ACID safety. Most importantly, you no longer need to worry about cache coherence issues between a Redis cache and a separate SQL database—EloqKV unifies them into a single, reliable system.
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.