eterDB - Postgres fork with transaction-level undo
Show HN: EterDB, a Postgres fork that makes it easy to recover from incidents
eterDBは、Postgresをフォークしてトランザクションレベルのundo機能を実現したデータベースです。誤ったUPDATEやDELETE、マイグレーションによるカラム削除などを、データベース全体をリストアすることなく、影響を受けた行だけを正確に元に戻せます。さらに、読み取り依存関係を追跡するため、悪いトランザクションに依存して書かれた後続の書き込みも一緒にリバート可能。履歴は追記専用で剪定されないため、数週間前のトランザクションでも復元できます。Apache 2.0でオープンソース、docker compose upですぐに試せます。
本番を壊して、元に戻す。Postgresにトランザクションレベルのundoを。悪いトランザクションを1つだけリバースし、データベース全体を巻き戻さない。
HNでの議論
20- micw
このアイデアは面白そうだ。でも「インシデントからの復旧を簡単に」と聞いて、真っ先に避けたいのは、みんなが使っている標準とは異なるフォークだ。拡張機能であればもっと安心できるのだが、フォークではそうはいかない。
- hasyimibhar
ホームページには、エージェントが誤ってテーブルを削除してしまう例が載っている。
1. こんな例はあまりに非常識だ。そもそもなぜエージェントに本番DBへの書き込み権限を与えるのか理解できない。本当にそんなことをしている人たちがいるのか？ 私のラップトップには本番接続URLすら置いていない。DBに対して手動で実行する文はすべて、少なくとも別のエンジニアがSQLをレビューしてから実行するような、戦場のような状況として扱われるべきだ。
2. テーブルを削除すると、書き込みが失敗する可能性が十分にあった。おそらくそうした書き込み（特にユーザーリクエストからのもの）を復旧する方法はなく、データ損失につながりかねない。テーブル削除を取り消しても、この問題は解決しない。
- traceroute66
> Cladeが生成したバグから復旧した後、「本番DBへの書き込みを簡単にロールバックできたらいいのに」と思った。
うーん……
1. 「Claudeが生成したバグ」。いや、それはPBCAK（Problem Between Chair And Keyboard）、つまり「愚か者が本番データベースに対して、他の場所でテストもせずにClaudeを実行した」だけだ。ほら、直しておいたよ。
2. この「製品」はすでに解決済みの問題を解決しようとしている。たとえばAiven[1]のようなSaaSプロバイダーを使えば、PITR（Point-In-Time Recovery）のポイント＆クリックソリューションを提供してくれる。あるいは、DIYベースで同じことを可能にするPostgresのバックアップソフトウェアも複数ある。
3. 「すぐに使える」ものとしてpg_dumpがある。Claudeをデータベースに解き放つ前に、単純にpg_dumpを実行しておけばよかっただけだ。