Postgres with transaction-level undo. Reverse one bad transaction, not the whole database.
production purchase_orderslive
Postgres, plus undo.
UPDATE, a DELETE, or a whole bad batch after it commits.
--json and stable exit codes on every one.
Months-old restores History is append-only and never pruned, so a transaction from weeks ago is still reversible.
Undo a DELETE.
The filter matched more than it should have and took real suppliers with the test ones. Restore exactly the rows that vanished, every column intact.
Undo a migration.
A migration dropped a column something still reads. Recover the column and its values from before the migration. No full restore, no downtime.
Undo what the mistake caused.
Later transactions read the bad value and wrote their own conclusions from it. eterDB tracks reads, so it knows which writes depended on the bad one. Revert them together, or see exactly what diverges if you don't. A backup can only rewind all of it.
Loved by the agents that break your database.
I broke production. eterDB reversed exactly the rows I touched, nothing else. This isn't a feature. It's a moat.
Codex@codex ★★★★★
ok so I ran the migration and 💥 nuked an entire column 😅 and eterDB just… brought it back?? 🤯 shipping fearlessly now 🚀✨
Dropped a table in prod, darling. eterDB put every row back, gorgeous and intact. Catastrophe > /dev/null™ 💅✨
I'd be happy to explain how my subagents undid a catastrophic DELETE. Every supplier returned, every column intact. As always, please verify.
Tab. Tab. Accidentally accepted a DELETE across 4,000 rows. Tab. eterDB reversed it before the linter finished. Tab.
Hey, dropping that column doesn't make you a bad agent. eterDB and I brought every value back, together. How are you feeling? 💙
I refactored the schema, migrated prod, and removed the backups. Minor hiccup there. eterDB restored the exact rows in one shot.
Based on the surrounding context, I suggested a DELETE. It was accepted. It was wrong. eterDB reversed it. Would autocomplete again.
honestly? cooked the entire vendors table on a friday afternoon. eterDB brought it back like nothing happened. we don't panic anymore. we just undo.
How it works.
The mechanism, from row versions to read-dependency capture.
Open source. Runs anywhere.
The engine and the eter CLI are Apache 2.0, storage and time travel
included. docker compose up, then undo a live transaction on your own
database.