Rendered at 07:56:11 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
traceroute66 3 minutes 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”.
Hmmmmmm......
1. "Claude-generated bug". No "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.
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.
maxloh 24 minutes ago [-]
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.
Hmmmmmm......
1. "Claude-generated bug". No "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/
https://pgbarman.org/