I've been testing EloqKV against TiKV, and it's much faster, specially for in-memory reads. I was seeking an alternative solution to replace KVRocks, which is essentially just a single node RocksDB wraped with a Redis API, EloqKV easily outperforms it by a large margin. Moreover, EloqKV can scale to multiple nodes.
I personally think that using the Redis API as a real database interface is quite useful. It saves me from dealing with the complexity of SQL, and it’s very natural to map my needs into Redis data structures. Coming from a programming background rather than a traditional DB background, I find imperative programming far more intuitive than declarative SQL, which I cannot "compile in my head" as easily.
Overall, kudos to the team for building such a solid solution and making it open source under a proper GPL license, which is becoming rare for new databases these days.
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.
I've been testing EloqKV against TiKV, and it's much faster, specially for in-memory reads. I was seeking an alternative solution to replace KVRocks, which is essentially just a single node RocksDB wraped with a Redis API, EloqKV easily outperforms it by a large margin. Moreover, EloqKV can scale to multiple nodes.
I personally think that using the Redis API as a real database interface is quite useful. It saves me from dealing with the complexity of SQL, and it’s very natural to map my needs into Redis data structures. Coming from a programming background rather than a traditional DB background, I find imperative programming far more intuitive than declarative SQL, which I cannot "compile in my head" as easily.
Overall, kudos to the team for building such a solid solution and making it open source under a proper GPL license, which is becoming rare for new databases these days.
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?