EterDB forks Postgres to add transaction-level undo for AI agents

EterDB is a fork of PostgreSQL 18 built around one feature: undoing a transaction after it has already committed, instead of restoring the whole database. Shown on Hacker News, it keeps the same drivers, SQL and extensions as stock Postgres, and adds the ability to reverse a single UPDATE, a DELETE, or a whole bad batch of writes.

The revert is surgical: only the rows touched by the reverted transaction change, and every other write made since is left in place. EterDB also tracks reads, not just writes, so it can identify which later transactions read a bad value and built their own writes on top of it; those dependent writes can then be reverted together with the original mistake, or inspected to see exactly how they diverge if they are left alone. The site contrasts this with a conventional backup restore, which can only roll everything back at once.

Beyond individual transactions, EterDB can restore a dropped column or table along with its original values without a full database restore, and it can read a table as it existed at any past point in time, reverting a whole time window with one command. Its history is append-only and never pruned, so a transaction made months earlier is still reversible.

The product is explicitly aimed at AI coding agents that operate on production databases. The landing page promises one command per recovery, with a --json output mode and stable exit codes on every call, under the tagline 'Loved by the agents that break your database'; every recovery demo on the page labels the acting agent as Claude Code. The scenarios shown include undoing a DELETE whose filter caught real vendor rows along with test ones, undoing a migration that dropped a column something still reads, and reverting a chain of writes built on a bad value. A separate demo on the page uses a fictional 'Avengers ERP Procurement' system, illustrated with 42 open purchase orders, $8.4 million of inventory, 17 vendors and 9 invoices due, as an example rather than a real incident.

The material does not say who built EterDB, gives no pricing or licence terms, and does not say whether it is self-hosted or offered as a managed service. A linked page promising to explain the underlying mechanism, described as row versions and read-dependency capture, is not part of the text reviewed here.

Key facts

EterDB is a fork of PostgreSQL 18 that adds transaction-level undo, reversing a single UPDATE, a DELETE, or a whole bad batch of writes after they have already committed.
A revert is surgical, changing only the rows the bad transaction touched, and EterDB also tracks reads, so it can find and revert the later writes that depended on the bad one.
It can bring back a dropped column or table together with its original values without restoring the whole database, and it can read any table exactly as it stood at a past moment.
Its history is append-only and never pruned, so even a transaction from months ago stays reversible, and recovery runs as a single command with --json output and stable exit codes, aimed at coding agents such as Claude Code.
The product's demo scenario, a fictional 'Avengers ERP Procurement' system with 42 open purchase orders, $8.4 million of inventory and 17 vendors, is an illustrative example on the landing page, not a real customer incident.

Why it matters

AI coding agents are increasingly given write access to production databases, and the product's own examples show how quickly that goes wrong: a delete filter that matches too much and removes real rows along with test ones, or a migration that drops a column something still reads. The usual recovery path, restoring from a backup, rewinds every write made since the snapshot was taken, including the legitimate ones. EterDB's pitch is to make that unnecessary for incidents like these: because it tracks transactions and their read dependencies inside a Postgres fork, it can undo just the damage and leave everything else standing, cutting recovery down to a single command.

Who it affects

The product targets teams that let automated coding agents, such as Claude Code, write directly to a production PostgreSQL database, along with the developers and operators who would otherwise have to hand-restore a backup after an agent's mistake. Nothing in the source points to a use case outside the Postgres ecosystem.

How to use it

EterDB is a fork of PostgreSQL 18 and says it keeps the same drivers, SQL and extensions as stock Postgres, so it can be adopted without changing how a team already connects to and queries its database. Recovery runs as a single command per incident, with a --json output mode and stable exit codes so an agent or script can call it directly. The source gives no pricing, no licence terms, and no word on whether it is self-hosted or offered as a managed service, so none of that can be reported here.

How solid is it

Every capability described here, including surgical reverts, dependency-aware tracking, schema recovery, time travel and an unpruned history, comes from EterDB's own landing page rather than from an independent test or benchmark. Its demo scenario, a fictional 'Avengers ERP Procurement' system with 42 open purchase orders, $8.4 million of inventory, 17 vendors and 9 invoices due, is evidently illustrative rather than a real customer's data. The page also points to a further explanation of the underlying mechanism, described as row versions and read-dependency capture, that is not part of the text reviewed here. On Hacker News itself, the Show HN post had drawn 31 points and 12 comments after about four days.

Risks and caveats

The source does not name a company, founder or team behind EterDB, does not state pricing or a licence, and does not say whether it runs self-hosted or as a managed service, so anyone evaluating it has to find those answers elsewhere. It also does not address the storage or performance cost of keeping an append-only, never-pruned history of every transaction, which is the mechanism the undo feature depends on. The demo numbers, 42 open purchase orders, $8.4 million of inventory, 17 vendors and 9 invoices due, belong to a fictional scenario built for the landing page, not a real production incident, and should not be read as evidence of real-world results.

“Loved by the agents that break your database.”

— EterDB's website