Japanese Translation:

PostgreSQL 19 は、ベータフェーズ開始直後に「REPACK CONCURRENTLY」を含む約 8〜10 の主要な機能を撤回しました。この変化は、ベータ期間後半に発見された重大なアーキテクチャ上の欠陥と多数のエッジケースによって引き起こされました。高度な自動化ツール（例：強化されたコードレビューやファージング）が、システムの複雑さや機能間相互作用（例：ドメインの組み合わせ、制約、パーティショニング、トリガーなど）により人手による検出が困難だった問題を浮き彫りにしました。これらの機能の多くは、現在の自動化分析機能が利用可能になる前の段階で開発されておりました。加えて、PostgreSQL 19 は 4 月から 8 月の間に「Vulnpocalypse（脆弱性の暴風）」に見舞われ、シニア開発者たちはベータウィンドウ内でのさらなるレビューやテストを優先することよりも、緊急のセキュリティ修正にリソースを割り当てることを決定しました。いくつかの問題はより長い期間の集中を必要としていた可能性がありますが、チームはリリーススケジュールを守りました。これらの機能は永久に廃棄されるものではなく、将来のリリースで洗練およびコミュニティからのフィードバックを受けた後に再導入される見込みです。PostgreSQL 20 は、未検証の主要な革新を導入するのではなく、すでにほぼ完成していたいくつかの機能を完了することに重点を置いたより慎重な戦略の下、間もなく公開を迎えています。

PostgreSQL 19 ベータ期間における大規模ロールバックの背景と今後の展望

📉 事象の概要

前代未聞の事態：PostgreSQL 19 ベータ期間開始以降、極めて例外的に多くの機能がロールバックされています。
- 通常、サイクルごとに数件程度のロールバックは想定されますが、今回は 8 つから 10 つもの重要な機能 が巻き込まれました。
延期の状況：そのうちいくつかの機能は、ベータ期間の後半まで延期されるケースがありました。
著者の立場：これらの機能を担当した開発者・コミッターとしての経験に基づき、事実を振り返ります。
- ※一部は影響を受けたが直接関与しなかった仕事についても言及しますが、これは 現時点での個人的見解 です。

🔍 ロールバックの要因分析

今回の状況を説明する複合的な要因は以下の通りです。

1. コード品質と対応不足

コード自体の品質が十分ではなかった可能性がありますが、それだけが原因ではありません。
学びを深め、改善していく姿勢が必要です。

2. 偶然性とタスクの難易度

好調な連続期間中に複数の機能を並行して着手しましたが、いずれも難しすぎたか、期限までに完了するレベルではなかったケースがあります。

3. アーキテクチャ上の課題と LLM の影響

重大な欠陥：一部にはベータ期間中に迅速に修正困難なアーキテクチャ上の欠陥がありました。
軽微な不具合の洪水：
- 多数のエッジケース関連の問題が発見されました（過去のプロジェクトでは数年後まで顕在化せず、5 年かけて修復されることも多かった）。
- LLM 支援コードレビュー導入により発見速度が劇的に向上。これにより、過去に「40 件の不具合報告」といったリストに直面しました。
時間不足：
- 各不具合への平均的対応コスト（修正 3 行程度）が積み重なり、総体的な時間が不足してしまいました。
- 影響を受けた機能は、LLM 支援レビューほどの有用性がなかった時代に書かれたコードであるため、コミット時点以降に 実質的な品質基準が引き上げられた と解釈されます。
将来への展望：LLM 支援コードレビューの能力向上が継続すれば、この種の状況は自ずと解決していくと考えられます。

4. 「バイブコーディング」ではない事実関係

今回の問題は「バイブコーディング（AI による素早いコード作成）」に起因するものではありません。
コードはそうした手法が可能になる ずっと以前 に作成されたものです。

5. バグポカリプス（脆弱性情報の集中発表期）の影響

時期: 4 月（機能フリーズ開始）〜 8 月（最新セキュリティリリース）。
背景: 多くの経験豊富な開発者がセキュリティ修正に追われ、通常ベータ期間で行われる追加レビューやテストが縮小されました。
結果:
- 8 月に再開された際に、多数の不具合が発見され、ロールバックが後半で集中しました。
- 「長い尾」の問題：根本的な問題だけでなく、小さな問題の蓄積もあり、より十分な時間（例：2 カ月）があれば対応できた可能性があります。
コミュニティの判断: リリーススケジュール維持を優先し、追加修正のための延期に対して抵抗を示しました。

6. システムの複雑性とテストの限界

機能実装における障壁として、コード上の構造化不足が影響しています。
- 例（SQL レベルのクエリ言語機能）:
  - ドメインとの互換性、複合型上のドメイン、NOT NULL 制約の有無、列の削除・再追加、パーティション化されたテーブルの変更、ビューやトリガーからの参照など。
人手での限界: これら全てのケースを人手でテストしたり、テストケースを列挙するのは不可能です。
解決策:
- LLM 支援によるファジングにより、こうした問題は速やかに発見できます。
- 将来的な機能開発において、この検証手法は 不可欠 となります。
- 同時に、内部インターフェースの堅牢化と、コンテキスト組み合わせによる相互作用の多岐を減らす設計が求められます。

7. 「全てと共存できる」哲学への再考

「PostgreSQL では全ては全てと共存できる」という哲学の一部として、そのようなケースを期待する点は魅力ですが、今回のように 機能開発に大きな制約（ペナルティ） を生じます。
全員がこの点を実質的な制限事項として理解しておく必要があります。

8. 「実験的」ステータスの導入検討

コミュニティはかねてより、機能をメインツリーの中で成熟させる前に「実験的」なステータスとしてコミットする可能性を検討しています。
- これも前記の問題解決の一つの方法となり得ます。
- 有用だったが具体的な実現方法が決まっておらず混乱を招いた機能については、このアプローチが有効でした。

🚀 今後の展望と対応策

1. コミュニティへの感謝と再挑戦

支援や励ましを受けられた皆様に心から感謝します。これが最も重要です。
確信：多くのロールバックされた機能は、修正され再び戻ってくるでしょう。

2. PostgreSQL 19 の評価

素晴らしいリリースであり、「REPACK CONCURRENTLY」「シーケンスの論理レプリケーション（以前ロールバックされた機能）」「pg_plan_advice を用いたプランナヒント機能」など、注目すべき機能が搭載されています。
追加的な監査を経て、より堅牢なシステムになっています。

3. PostgreSQL 20 への期待

当初の予測見直し: 数ヶ月前には「PostgreSQL 20 は新機能を一切含めずバグ修正のみ」と言及しましたが、事態は急速に進みました。
現在の状況:
- PostgreSQL 19 の主要機能数は当初予想された 半分程度 と少なくなりましたが...
- 一方で、完成度 80% に達した魅力的な機能の開発が PostgreSQL 20 へ待機しています。
- 残りの 20% を完了するだけですぐにリリース可能 な状況です！

ロールバック操作は、士気向上まで続きます。