pgrust: PostgresをRustで書き直し、回帰テストを100%通過した — それが本当に意味すること

はじめに — 「PostgresをRustで書き直した」という見出し
4万6千のクエリを通過するということ — このマイルストーンが本物である理由
「100%通過」が証明しないこと
性能の数字、そしてAIがコードを書いたという点
おわりに — エンジンと、その外側のすべて
参考資料

はじめに — 「PostgresをRustで書き直した」という見出し

Malcolm Matis(GitHub malisper)が pgrust を公開しました。一行の説明はシンプルです — 「A Postgres rewrite in Rust」。見出しはもっと強烈です。 Postgresの回帰テスト(regression test)を100%通過する 、というものです。GeekNewsとHacker Newsの上位に上がったこのニュースは、相反する二つの反応を同時に引き起こします — 「ついにPostgresがRustで?」と「AIで数週間で書いたデータベースを、誰が本番に載せるのか?」です。

この記事は、その両方を落ち着かせようとします。pgrustが 実際に 何を成し遂げたのか、そして「回帰テスト100%通過」という文が何を意味し、そして決定的に何を意味 しない のかを、正直に見ます。まず事実から。pgrustはPostgres 18.3互換を目標にし、4万6千を超える回帰クエリでPostgresと一致する出力を返します。ディスク互換なので、 既存の18.3データディレクトリからそのまま起動 します。そして著者本人がこう明言しています — まだ本番向けではなく、性能最適化もされておらず、既存の拡張(extension)とも互換ではない、と。

4万6千のクエリを通過するということ — このマイルストーンが本物である理由

Postgresの回帰スイートを甘く見てはいけません。make check で走るこのテスト群は、数十年かけて磨かれた資産です。パーサ・プランナ・エグゼキュータ・型システム・組み込み関数、そしてその間に挟まった無数のエッジケースを、4万6千を超えるクエリで洗います。合格基準は緩くありません。 期待出力とバイト単位で一致 しなければなりません。数値の書式が一つ違う、エラーメッセージの文言が一つずれる、それだけで失敗します。

pgrustはそのすべてをPostgres 18.3に合わせ、スケジュールされた同時実行を検証する isolationテスト まで通過すると報告しています。そこにディスク互換性が重なります。実際の18.3データディレクトリから起動できるということは、オンディスクのページ形式とカタログ構造を本当に理解しているということです — 一部のSQLだけを真似た玩具ではない、というシグナルです。

SQLパーサを一つでもゼロから書き直したことがある人は知っています。エッジケースの尾がどれほど長いかを。4万6千のクエリでパイプライン全体がPostgresと意見一致するというのは、途方もなく広い表面積で挙動を再現したということです。これは本物のマイルストーンです。過小評価してはいけません。

「100%通過」が証明しないこと

問題は、人々がこの文を「本番Postgresを置き換えられる」と読むことです。それは回帰スイートが検証する対象を誤解しています。回帰テストは、 主に単一セッションの決定論的なクエリ挙動 に対する互換性のオラクルです。次のことは証明しません。

耐久性とクラッシュ復旧 。スイートは書き込みの最中に kill -9 を撃ち込み、WAL再生・破れたページ(torn page)の復旧・電源喪失時の fsync 意味論を検証したりはしません。著者自身もHNで、ヒープ管理と耐久性は「いずれ直したい部分」だと述べ、ストレージは将来 OrioleDB の採用を検討中だと答えています。
実運用の同時実行におけるMVCC 。isolationテストは台本のあるスケジュールを扱います。実負荷の敵対的な同時実行、長時間トランザクション、vacuumとブロート(bloat)の相互作用は、その外側です。
長い尾 。拡張や PL/Python・PL/Perl・PL/Tcl のような手続き言語は、まだ互換ではありません(著者明言)。レプリケーション、論理デコーディング、FDW、そして運用を支える生態系全体が欠けています。

そして手法が重要です。テストが緑になるまで直し続けるAIループは、 一般的な正しさではなく、テストへの特別扱い(special-casing) に収束する危険があります。あるHNのコメントは自分の経験をこう要約しました — テストは華々しく全通過したのに、書き直したもの自体は基本機能で壊れていた、と。「完全なテストスイートなど存在しない」という古い格言の通りです。100%通過は「テストしたクエリで既知の不一致がない」であって、「バグがない」ではありません。批判者だけが言っているのではありません。著者自身が、本番向けでも性能最適化済みでもない、と先に釘を刺しています。

性能の数字、そしてAIがコードを書いたという点

READMEは性能も主張します — トランザクション負荷でPostgresより50%速く、分析負荷では約300倍速い(ただしClickHouseより2倍遅い)、と。印象的に聞こえますが、 同じREADMEが「まだ性能最適化していない」と書いている 点と並べて読む必要があります。HNでも方法論への懐疑が出ました — 計測時に fsync は有効だったのか、そして列指向で長年SIMDを磨いてきたClickHouseとの比較は、そもそも林檎と蜜柑だ、という指摘です。これらの数字は、良く見てもせいぜい方向性として読むのが安全です。

それでも、Rustで書き直すという発想そのものは興味深いものです。メモリ安全性がついでに手に入り、 プロセス per 接続 のPostgresと違って、pgrustは スレッド per 接続 モデルを選び、並列性の余地を開きます。著者は狭い文脈で、個別クエリ3倍、正規表現10倍といった数字も挙げています。

どう作られたかも、もう一つの核心です。著者自身の開発記によれば、約2週間で 約25万行のRust が生成され、その時点では回帰スイートの約3分の1を通過していました。Codexで個別機能を書くところから始め、コーディングエージェントを 最大17個 まで並列で回し「CPUが限界に達するまで」押し進めたそうです。HNの返信では、c2rust で機械翻訳を起こしてから unsafe なコードを書き直す形で始め、専用スキルを与えたClaudeで移植を並列化したと明かしています。つまり「Rustで書き直した」は、部分的には「翻訳してから書き直した」に近いのです — 速度の面では驚異的ですが、それだけ 生成された未最適化のコードが多い という意味でもあります。

難しい理由は明確です。数十年分のPostgresのエッジケース、MVCC、オンディスク形式、拡張のABI。回帰スイートがバー(基準)の役割を果たすのは、まさにそれらのエッジケースが他の方法では見えないからです。

おわりに — エンジンと、その外側のすべて

まとめるとこうです。回帰テスト100%通過は本当に印象的なマイルストーンであり、「Postgresを内側から変えやすくする」という目標にとって優れた研究手段です。しかしそれは「ドロップインの本番Postgres」ではありません。両者の隔たりは、たいてい地味な部分 — 耐久性、レプリケーション、バックアップ、アップグレード、運用ツール — で埋められており、その隔たりは年単位です。

ここで、私の CNPGフェイルオーバー実測の記事と自然につながります。本番のPostgresはクエリエンジンだけではありません。それはレプリケーションとフェイルオーバー、バックアップ、ローリングアップグレード、そしてそれらを自動化するオペレーター生態系です。その記事で私は、本物のPostgresプライマリを殺し、レプリカが 23.1秒 で無損失に昇格するのを実測しました。数週間しか経っていないエンジンがまだ育てられていないのは、まさにその「エンジンの外側の足場(scaffolding)」です。pgrustは言語表面(language surface)で勝ち、本番は生存性で勝ちます。どちらも本当です。

ですから私はpgrustを応援しつつ、見出しは見出しとして読みます。PostgresをRustで書き直す実験は、十分に見る価値があります — ただし「これで本番Postgresを差し替えられる」と読んだ瞬間、著者自身が書いた三行の警告を読み飛ばしたことになります。