Forking Postgres and patching the transaction engine to aid granular recovery is one obvious way to achieve this, but the more robust solution is to fork the Linux kernel and apply a surgical patch to the TCP/IP stack. A kernel level regex check on port 5432 traffic prevents Claude from dropping your prod DB tables in the first place.
Show HN: EterDB, a Postgres fork that makes it easy to recover from incidents
11–20 of 22 posts
Re: Show HN: EterDB, a Postgres fork that makes it easy to recover from incidents
#12> 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…
I have no relation to the project, but calling this problem solved and then offering a vastly inferior solution to the proposal (PITR) is a bit unfair
Re: Show HN: EterDB, a Postgres fork that makes it easy to recover from incidents
#13Slop.
Re: Show HN: EterDB, a Postgres fork that makes it easy to recover from incidents
#14Forking Postgres and patching the transaction engine to aid granular recovery is one obvious way to achieve this, but the more robust solution is to fork the Linux kernel and apply a surgical patch to the TCP/IP stack. A kernel level regex check on port 5432 traffic prevents Claude from dropping your prod DB tables in the first place.
Wouldn't it be easier to patch gnu c compiler that compiles the kernel? That way anyone compiling kernels will auto include the enhancement by default across all OS, unix or linux.
Re: Show HN: EterDB, a Postgres fork that makes it easy to recover from incidents
#15> 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…
I have no relation to the project, but calling this problem solved and then offering a vastly inferior solution to the proposal (PITR) is a bit unfair
Point one remains. The "solution" appears to come from somebody who thinks its OK to run Claude against a production database.... “wouldn’t it be nice if prod DB writes were easy to roll back”
The point remains that if they ran Claude against a test database they would have found the bug without killing their production database, and therefore also not need to come up with an over-engineered "solution".
Sometimes also the less over-engineered the better. Stuff like PITR and pg_dump is battle-tested and easy to reason about.
Re: Show HN: EterDB, a Postgres fork that makes it easy to recover from incidents
#16Uh, pitr is a thing in many many postgresql management layers. https://pgbarman.org/
I think the think they're aiming for here isn't to rewind to a particular point in time, but to remove a transaction from the history and while keeping the transactions after it.
Re: Show HN: EterDB, a Postgres fork that makes it easy to recover from incidents
#17The 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 you…
> Reversing the table drop doesn't fix this issue.
Also reversing a table drop doesn't solve extra corruption routes such as cross-table dependencies.
Re: Show HN: EterDB, a Postgres fork that makes it easy to recover from incidents
#18Little known fact is that POSTGRES used to have built-in Time Travel [1].
It was deprecated as the performance hurdle was significant.
This seems to utilize logical WAL replication and some form of dependency generation based on proxying a transaction's reads.
Managed Neon (Acquired by Databricks) also offers time travel [2].
One of the biggest challenges with this kind of solutions is handling ACID, OCC and/or HW failures correctly, Sometimes it requires an whole new language! [3]
[1] https://www.postgresql.org/docs/6.3/c0503.htm
[2] https://neon.com/docs/postgres/backup-restore/time-travel-as...
Re: Show HN: EterDB, a Postgres fork that makes it easy to recover from incidents
#19Earlier quoted context omitted.
I have no relation to the project, but calling this problem solved and then offering a vastly inferior solution to the proposal (PITR) is a bit unfair
Point one remains. The "solution" appears to come from somebody who thinks its OK to run Claude against a production database.... “wouldn’t it be nice if prod DB writes were easy to roll back” The point remains that if they ran Claude against a test database they would have found the bug without killing their production database, and therefore also not need to come up with an over-engineered "solution". Sometimes als…
Fair enough, but I think there is utility beyond this. Sometimes humans do stupid shit too.
Re: Show HN: EterDB, a Postgres fork that makes it easy to recover from incidents
#20Slop.
Seems like.