Break production.
Undo it.
Postgres with transaction-level undo. Reverse one bad transaction, not the whole database.
purchase_orderslivePostgres, plus undo.
UPDATE, a DELETE, or a whole bad batch after it commits.
--json and stable exit codes on every one.
A restore rewinds everything.
A migration zeroes 1,200 invoice amounts at 14:00. You catch it at 14:40. Restoring to 13:59 brings the amounts back and discards forty minutes of orders, payments and signups that had nothing to do with the migration. eterDB reverses the 1,200 rows and keeps the forty minutes.
| Backup or PITR restore | eterDB undo | |
|---|---|---|
| Recovers | the whole database as of a past moment | the rows one transaction touched |
| Discards | every write after that moment | nothing else |
| The database | comes back from a copy | stays live throughout |
| Writes that read the bad value | indistinguishable from the rest | listed before you decide |
Point-in-time recovery is inside eterDB as the storage tier: base
backups plus archived-WAL replay, in unprivileged containers. It brings a dropped table
back, because a DROP leaves no row to reverse. Row-level undo is the layer
above it.
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.
vendorsliveUndo 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.
rosterliveUndo 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.
txn logliveLoved 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.
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.
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.