Postgres Is Reliable – I'll Persist in Eloqkv
Posted3 months agoActive3 months ago
eloqdata.comTechstory
calmpositive
Debate
20/100
PostgresDatabase ReliabilityEloqkvKey-Value Stores
Key topics
Postgres
Database Reliability
Eloqkv
Key-Value Stores
The author presents a benchmark demonstrating Postgres' reliability and discusses their persistence in using it for EloqKV, a key-value store, sparking a discussion on database choices and performance.
Snapshot generated from the HN discussion
Discussion Activity
Light discussionFirst comment
N/A
Peak period
2
0-1h
Avg / period
2
Key moments
- 01Story posted
Sep 27, 2025 at 11:52 AM EDT
3 months ago
Step 01 - 02First comment
Sep 27, 2025 at 11:52 AM EDT
0s after posting
Step 02 - 03Peak activity
2 comments in 0-1h
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 27, 2025 at 12:30 PM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45396824Type: storyLast synced: 11/17/2025, 12:03:29 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
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.
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?