Pgrustの構築：AIでPostgresをRustに書き換える4回の試み

過去3か月間、私は友人Jason Seibelと共にpgrustを開発してきました。目標はAIを活用してより優れたPostgresを構築することです。PostgresはC言語で書かれており、AIはまだ多くの誤りを犯すため、まずRustに書き換えることで、AIが新機能を安全に追加できるようにしました。この仮説は実証されつつあり、開発中の第5版はトランザクション負荷でPostgresより高速で、分析クエリではClickhouseに匹敵します（Clickhouseは通常Postgresより数百倍高速）。

私たちは4回の試行を行い、総額約10万ドルを費やしました。最初の試行pgrust-ogは機能単位の移植を採用しました。まずコアサブシステム（パーサー、プランナー、エクゼキュータなど）を構築し、その後複数のCodexエージェントを並行して数百の機能を実装しました。テストの96％を通過しましたが、プランナーの内部表現がPostgresと微妙に異なりました。例えば、単純なSELECTクエリはPostgresでは単一のノード（SeqScan）として表現されるのに対し、Rustでは3つのノード（Projection、Filter、SeqScan）として表現され、テーブルの参照方法も異なります。このような「臓器移植の失敗」により、修正は不可能となりました。この試行では8つのCodexアカウントを1か月使用し、約1600ドルを費やしました。

2回目の試行ではc2rustを使用してPostgresのCコードを530万行のunsafe Rustに変換しました。変換後のコードはテストスイートを完全に通過し、Postgres拡張とのABI互換性も維持しました。しかし、これを安全なRustにリファクタリングするのは極めて困難でした。すべての値がポインタで表現されており、1つの関数を変換するには、その呼び出し元と呼び出し先の型とロジックをすべて変更する必要があり、結果として数百の関数を変更することになりました。インクリメンタルなアプローチ（各関数に安全版と非安全版を用意するなど）も試みましたが、うまくいきませんでした。

3回目の試行pgrust-idiomaticは、c2rustの出力（約1000のクレート）をクレート単位で書き換えることを目指しました。Jarred SumnerがBunをZigからRustにファイル単位で書き換えたことに触発されましたが、すべてのクレートを書き換えなければ動作しないためリスクが高く、効率の問題も残りました。

最終的に4回目の試行では、最大40の並行サブエージェントを実行し、ファイル単位での書き換えに成功し、180万行の慣用的なRustコードを生成しました。重要な教訓として、レガシーシステムの書き換えでは機能単位ではなくファイル単位で並列化すべきこと、CIでビルド負荷を処理すること、中間表現を元のシステムと等価に保つことが挙げられます。最終版pgrustは、AI支援による書き換えの実現可能性を示すとともに、将来のAIによるPostgresの安全な拡張の基盤を築きました。