Show HN: EterDB, a Postgres fork that makes it easy to recover from incidents
summary
eterDB introduces a transaction-level undo system for PostgreSQL that allows developers to reverse specific bad transactions without resetting the entire database. Unlike traditional point-in-time recovery, this tool targets only the rows affected by a mistake, preserving all other valid data written after the error. It uses read-dependency tracking to identify and reverse consequential writes, ensuring data integrity during surgical recoveries.
key points
- The system enables the reversal of individual UPDATE, DELETE, or schema changes like dropped columns and tables without requiring a full database restore or downtime.
- By tracking which transactions read bad values, eterDB can identify and reverse downstream writes that depended on the erroneous data.
- The tool integrates point-in-time recovery as a storage tier, combining base backups and WAL replay to recover structural losses while maintaining row-level precision.
who should read it
Database administrators and software engineers, particularly those using AI coding agents that may accidentally execute destructive commands in production environments.
discussion hostile
consensus
Commenters generally view the product as an over-engineered solution to a problem that should be solved via basic security hygiene, such as using read-only roles and test environments. There is significant skepticism regarding the decision to fork and patch the PostgreSQL engine rather than using existing tools like Point-In-Time Recovery. The overall sentiment is dismissive, with several users labeling the marketing materials as 'slop' or 'vibeslop'.
top insight
The core value proposition is not simple point-in-time recovery, but the ability to surgically remove a specific faulty transaction from history while preserving subsequent valid transactions. This distinguishes the approach from standard PITR, which requires rewinding the entire database to a previous state and losing all intervening data. However, critics argue that this complexity is unjustified given the risks of patching core database internals.
Generated by an LLM from the article and thread. Check the sources before relying on it.