PostgreSQL 19 は LLM コードレビューにより 8〜10 の機能がリバートされ、2026 年 11 月に延期
PostgreSQL 19 は、LLM 支援コードレビューにより、プロジェクトの人間のコミッターが期限までにトリアージして修正できるよりも多くの欠陥が見つかったため、リリースから 8〜10 の重要な機能が削除され、2026 年 11 月 19 日頃に延期されました。PostgreSQL グローバル開発グループは、リバートの原因を AI が書いたコードではなく、サイクル途中で引き上げられた品質基準によるものとしています。
PostgreSQL 19 は 2026 年 9 月下旬/10 月上旬から 2026 年 11 月 19 日頃に延期
PostgreSQL グローバル開発グループは、PostgreSQL 19 を当初の目標である 2026 年 9 月下旬または 10 月上旬から、2026 年 11 月 19 日頃の一般提供開始予定日に延期しました。延期に加えて、開発者はリリースから 8〜10 の重要な機能を削除し、PostgreSQL 20 に先送りしました。
PostgreSQL の主要コミッターであり、EDB（PostgreSQL サポートおよびコンサルティング企業）の副社長である Peter Eisentraut 氏は、異常に多いリバートの原因は、少なくとも一部は開発者が実行していた LLM コードレビューにあると述べました。
LLM 支援レビューにより、機能がコミットされた後に品質基準が引き上げられた
Eisentraut 氏は、2026 年 10 月 9 日のブログ記事 「The reverts will continue until morale improves」 で説明を公開し、リバートされた作業を 2 つのカテゴリに分類しました。
最初のカテゴリは、真のアーキテクチャ上の欠陥です。リバートされた一部の機能には、"ベータ期間中に迅速に"修正するのが難しい重大なアーキテクチャ上の問題がありました。
2 番目のカテゴリは、ロングテールです。LLM 支援コードレビューにより、以前のサイクルでは開発者がずっと後になるまで気付かなかったであろう「さまざまなエッジケースに関する比較的無害な問題」が多数明らかになりました。これらは通常、リリース後 5 年間にバグ修正として表面化します。Eisentraut 氏は、その結果生じる作業負荷について次のように説明しました。
「LLM 支援コードレビューにより、この種の問題ははるかに速く見つかるようになり、40 件の欠陥レポートのリストを前にすることになります。それぞれの修正に平均 3 行しか必要なくても、それぞれに対処するための固定オーバーヘッドがあり、時間が足りなくなります。」
タイミングの問題は、PostgreSQL 19 の主要機能が書かれた時点では、LLM 支援コードレビューの能力が現在ほど高くなかったことです。レビューツールは、コードがすでにコミットされた後、リリース前の数か月間に改善されました。Eisentraut 氏はこれを一回限りのミスマッチと位置付けました。
「実効品質基準は、機能が書かれ、コミットされた時点より後に引き上げられました。LLM 支援コードレビューの能力が現在のペースで向上し続けない限り、この状況は将来の開発サイクルでは自然に解消されるはずです。」
リバートは「バイブコーディング」ではないと PostgreSQL コミッターが主張
Eisentraut 氏は、リバートが AI 生成コードによるものだという解釈を明示的に否定しました。新しい機能のほとんどが書かれた時点ではその技術が利用できなかったため、リバートは開発における「バイブコーディング」によるものではないと述べました。欠陥は、人間が書いたコードを AI がレビューしたことで見つかったものであり、AI が作成したものではありません。
SQL/PGQ は PostgreSQL 19 から削除された機能の 1 つ
PostgreSQL 19 から削除された機能の 1 つは、2023 年に SQL 標準の一部となった SQL プロパティグラフクエリ（SQL/PGQ）のサポートです。SQL/PGQ は、エッジで接続されたノード間の関係を探索するための構文を提供します。PostgreSQL の実装は、未解決の問題のため削除されました。
PostgreSQL の貢献者である Tom Lane 氏は、リバート前にこの機能について警告していました。2026 年 9 月に彼は次のように述べました。
「現時点では、v19 でこれをリリースしたら、v20 まで修正不可能なリリース後のバグが発見されるだろうと、夕食を賭けてもいい。」
PostgreSQL 19 は引き続き REPACK CONCURRENTLY を提供し、堅牢であることが期待される
延期とリバートにもかかわらず、Eisentraut 氏は PostgreSQL 19 は依然として「素晴らしいリリース」になると述べました。確認されたハイライトの 1 つは、ディスク領域を再利用するために使用されるテーブルロックを伴う VACUUM FULL 操作を回避する REPACK CONCURRENTLY です。また、追加の精査には利点があると主張しました。「そして、追加の精査の後、非常に堅牢になるでしょう。」
リバートされた機能は PostgreSQL 20 に搭載される見込み
PostgreSQL 19 からリバートされた機能は、PostgreSQL 20 に搭載される可能性が高いです。これは、わずか数か月前に発表された計画を覆すものです。開発者は PostgreSQL 20 には新機能は含まれず、バグ修正のみが含まれると予想していました。PostgreSQL 20 には、以前のリリースから残された新機能が搭載される可能性が高くなりました。
PostgreSQL の歴史は、プロジェクトがリリースに対して保守的である理由を説明している
PostgreSQL は、1986 年に Michael Stonebraker によって最初に提案されました。1994 年に Andrew Yu と Jolly Chen がクエリ言語 POSTQUEL を SQL に置き換え、1995 年にデータベースはより寛容なライセンスの下で自由に利用および変更できるようになり、PostgreSQL に改名されました。それ以来、大手 3 ハイパースケーラが構築したサービスと、利用可能なワイヤ互換の分散システムの範囲により、プロの開発者の間で最も人気のあるデータベースになりました。
コメンテーターは、AI 時代のボトルネックはコーディングではなく QA であると主張
この延期に関する Hacker News の議論は、単一のテーマに収束しました。AI は欠陥の発見を安価にし、欠陥の解決を高価にするため、品質保証がリリーススケジュールの制約になります。
あるコメンテーターは、AI レビューが表面化するバグは、LLM がボタン一つで修正できる種類のものではなく、設計上のトレードオフを深く検討する必要がある種類のものであると主張しました。
「私の推測ですが、見つかっているバグは LLM でボタンを押せば修正できるような種類のものではなく、レビュアーが設計上のトレードオフを深く考慮する必要がある種類のものであり、DB やプログラミング言語のコードベースにはそのようなものが単純に多いと思います。」
別のコメンテーターは、この変化を「もっともらしい否認可能性」の喪失と表現しました。ツールが包括的にバグや欠落したテストケースを発見できるようになると、チームは最低限の機能をリリースして結果を先送りすることができなくなります。その結果、機能ごとに費やす時間が増え、リリースはより良くなっているにもかかわらず、生産性が低く見えるようになります。
3 人目のコメンテーターは、QA こそが永続的な価値がある場所であると主張しました。
「AI 時代において、QA はプロジェクトのボトルネックになりつつあり、真の価値の源です。AI はテストの良い基盤を築くことができますが、最先端のモデルでもテストに関しては人間と同じように、思いついたことだけをテストする傾向があり、むしろ少し劣る場合もあるため、支援が必要です。」
同じコメンテーターは、これにより SaaS が殺されるのではなく、むしろ強化されると主張しました。なぜなら、フロントオフィスシステムをプロンプトで作成できる中小企業でも、その QA を行いたいとは思わないからです。そして、QA の負荷はコードの量に応じて増加します。PostgreSQL との比較は直接的です。「今日、データベースをプロンプトで作成できるとしても、Postgres のようにテストされ、QA されたものをプロンプトで作成することはできません。」
反論: AI は事実上無限のバグを見つけることができる
議論で繰り返し出た反論は、AI レビューには自然な停止点がないということです。あるコメンテーターが述べたように、「AI は文字通り無限のバグを見つけることができます。実際の現実世界のケースに影響を与えたかどうか、気付かれたかどうかに関係なく、見つけるべきバグは常にあります。」
これにより、別のコメンテーターが提起した明白な疑問が生じます。現在のリリースにこれほど多くの潜在的なバグがあるなら、すでに本番環境にあるバージョンにも同様に多くのバグがあるはずです。「それは、既存のバージョンの Postgres にも人間が修正できるよりも多くのバグがある可能性が高いことを意味するだけではありませんか？ リリースしてください。ソフトウェアは完璧ではなく、常に進行中です。」
反論: AI のバグレポートには依然として人間のトリアージが必要
複数のコメンテーターは、AI の生の出力は欠陥リストではないと警告しました。あるコメンテーターは、AI ツールが Linux カーネルで 82 個のバグを報告したが、実際には 6〜8 個だけが本物であることが判明したという過去のケースを挙げました。残りはすでに修正済みか、最新バージョンで修正済みか、捏造でした。述べられた結論は、人間が山をふるい分けるまで懐疑的であるべきだということです。
他の人々は、同じ線を停止理由ではなくプロセスルールとして引きました。
「バグを見つけるために AI を使う（書くのではなく）のは、私見では素晴らしいユースケースです。熟練したレビュアーがいても、目が多ければ多いほどほぼ常に良いです。ただし、編集されていない AI の「バグレポート」を issue として投稿しないでください。開発者に投げる前に、人間がそれが実際に問題であることを確認する必要があります。」
あるコメンテーターはまた、このフレーミングにおける潜在的な利益相反を指摘し、Eisentraut 氏の雇用主である EDB が AI 指向の Postgres 製品を販売していることを挙げ、AI 以前に PostgreSQL で何も機能したことがないのかと修辞的に問いかけました。
より深い主張: 根本原因は AI ではなく PostgreSQL のテストスイートにある
PostgreSQL の Rust 書き換えに取り組んでいるコメンテーターは、最も技術的に具体的な反対の物語を提供しました。AI はバグを作り出しているのではなく、エッジケースをヒットするように設計されたことがないテストスイートを暴露しているのです。
「ほとんどの場合、Postgres は各機能をテストするために個々の回帰テストに依存しています。回帰テストは機能が壊れないことを確認するのに優れていますが、エッジケースをヒットするのには実際にはあまり優れていません（2MB を超える文字列を特定の関数に渡すとバッファオーバーフローが発生し、DB がクラッシュします）。」
そのコメンテーターは、書き換えの構築中に、AI に先立つ技術（決定論的シミュレーションテスト、差分カバレッジガイド付きファジング、形式検証）をスケールするために AI を使用して、コア PostgreSQL で約 50 個のバグを発見したと報告しました。最も積極的な例は、C および Rust 関数を Lean に変換するコンパイラで、LLM が 2 つの実装が同一であるという証明を書くというものです。執筆時点で、コードベースの 10.5%（640k 行のうち 67k 行）が同等であると検証されており、PostgreSQL が isspace() を使用してスペースをトリミングする一方で、書き換えが ASCII 空白のみをトリミングするという解析関数のような細かい発見がありました。
PostgreSQL 19 の延期が AI 支援エンジニアリングに示すもの
PostgreSQL 19 の延期は、成熟したオープンソースプロジェクトで繰り返される可能性が高いパターンの初期の具体的な例です。AI レビューは、欠陥の解決コストを下げるよりもはるかに速く欠陥の発見コストを下げるため、制約はコードを書くことから発見の裁定に移ります。PostgreSQL の対応、つまり既知の欠陥のある作業をリリースするのではなく、機能を次のメジャーバージョンにリバートすることは、保守的な選択であり、リスクの高い変更を最小限に抑え、徹底的な人間のレビューに依存するというプロジェクトの長年の慣行と一致しています。
Eisentraut 氏自身の予測は、この影響は一時的なものであるというものです。ミスマッチは、コードが書かれた後にレビュー能力が向上したためにのみ存在します。LLM レビュー能力が現在のペースで向上し続ければ、将来の開発サイクルは新しい品質基準の下で最初から書かれ、後から適合させる必要はありません。