Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: EterDB, a Postgres fork that makes it easy to recover from incidents

eterdb.com

Post reply on HN
Print view View original

1–10 of 22 posts

Show HN: EterDB, a Postgres fork that makes it easy to recover from incidents

#1

Post by fdeth »

Hey everyone, a few months ago, after recovering from a Clade-generated bug, I was thinking to myself “wouldn’t it be nice if prod DB writes were easy to roll back”. I’ve put something together: it’s a two-container deploy plus a CLI tool. It’s far from being production ready, so please be gentle. All feedback welcome!

The nitty gritty: https://eterdb.com/tech

GitHub: https://github.com/eterdb/eterdb

Show HN: EterDB, a Postgres fork that makes it easy to recover from incidents
eterdb.com

Re: Show HN: EterDB, a Postgres fork that makes it easy to recover from incidents

#4

Post by micw »

The idea looks interesting. But when I think of "make incident recovery easy", the very last thing I want is a fork that differs from the standard that everyone else is running. I would have a better feeling if that would be an extension, not a fork.

Re: Show HN: EterDB, a Postgres fork that makes it easy to recover from incidents

#5

Post by maxloh »

micw wrote: post #4

The idea looks interesting. But when I think of "make incident recovery easy", the very last thing I want is a fork that differs from the standard that everyone else is running. I would have a better feeling if that would be an extension, not a fork.

From the README,

  It is PostgreSQL 18. One piece, read-dependency capture, has to be in the engine, and it ships as a small upstream-tracked patch. Extensions including pgvector, your ORM, and your SQL dialect all work unchanged.
https://github.com/eterdb/eterdb#how-it-works

Re: Show HN: EterDB, a Postgres fork that makes it easy to recover from incidents

#6

Post by 0c3ca83 »

maxloh wrote: post #5
micw wrote: post #4

The idea looks interesting. But when I think of "make incident recovery easy", the very last thing I want is a fork that differs from the standard that everyone else is running. I would have a better feeling if that would be an extension, not a fork.

From the README, It is PostgreSQL 18. One piece, read-dependency capture, has to be in the engine, and it ships as a small upstream-tracked patch. Extensions including pgvector, your ORM, and your SQL dialect all work unchanged. https://github.com/eterdb/eterdb#how-it-works

Yes, so, in other words it's patching the internals. And the "how it works" is vibeslop.

Re: Show HN: EterDB, a Postgres fork that makes it easy to recover from incidents

#7

Post by traceroute66 »

> after recovering from a Clade-generated bug, I was thinking to myself “wouldn’t it be nice if prod DB writes were easy to roll back”.

Hmmmmmm......

1. "Claude-generated bug". No it was PBCAK (Problem Between Chair And Keyboard) a.k.a "foolish person ran Claude against the production database without testing it elsewhere". There, fixed it for you.

2. This "product" is solving a problem that is already solved. You can for example use a SaaS provider such as Aiven[1] who will provide you with PITR (Point-In-Time Recovery) point and click solutions. Alternatively there is more than one piece of Postgres backup software that lets you do the same on a DIY basis.

3. "Out of the box" you have pg_dump. You could have just done a simple pg_dump before letting Claude loose on your database.

[1] https://aiven.io/

Re: Show HN: EterDB, a Postgres fork that makes it easy to recover from incidents

#9

Post by hasyimibhar »

The homepage shows an example of an agent accidentally dropping a table.

1. This is such an insane example, I don't get why would you give agents write access to your production db in the first place. Are people really doing this? I don't even have production connection urls on my laptop. Any manual statements executed against the db must be treated as a war-room situation with at least another engineer reviewing your SQL before you execute it.

2. Dropping the table could have easily caused writes to fail. Most likely there is no way to recover these writes (especially if it's from user requests), so it could have lead to loss of data. Reversing the table drop doesn't fix this issue.

Post reply on HN