PostgreSQL 19 の正式版（GA）が、予定の10月29日から11月19日へ3週間延びました。開発者の Robert Haas 氏（Databricks 所属のコミッター）は、遅れの原因を AI だと書いています。LLM（Large Language Model、大規模言語モデル）を使ってバグを探す人が増え、報告が一気に増えました。その修正に開発者の時間が取られ、新しい版の確認が後回しになったという説明です。PostgreSQL を使う側では、11月12日に PostgreSQL 14 のサポートも終わるため、この秋の更新の計画に関わってきます。
背景と文脈
PostgreSQL は毎年1回、新しいメジャー版を出しています。ここ10年は、9月半ばから10月半ばの間に出すのがふつうでした。新機能を受け付けるのは毎年4月8日ごろまでで、そのあとはベータ版で不具合をつぶしていきます。
今年は、この流れがくずれました。リリースチームの Jonathan Katz 氏が9月28日に出した予定では、候補版の RC1 が10月15日、正式版が10月29日でした。10月10日に 開発者向けメーリングリストで予定を改め、2つ目の候補版 RC2 を11月12日に足し、正式版を11月19日に動かしています。理由は、古い版に入った修正の数がとても多く、それを RC2 にも入れてから出したいというものでした。メールでは今回を「いつもと違うリリースの年」と呼んでいます。
ベータの途中では、大きな機能が3つ取り下げられました。期間を指定して行を更新・削除する UPDATE/DELETE FOR PORTION OF、SQL でグラフ構造をたどる SQL/PGQ、パーティションを結合・分割する ALTER TABLE の MERGE/SPLIT PARTITION です。8月27日から9月15日の間に、まとめて元に戻されました。
技術/ビジネス面
Haas 氏は Postgres 19 is late, and it’s AI’s fault という記事で、4月8日から9月25日までのコミット数を前の年と比べています。
| ブランチ | 2025年 | 2026年 | 増え方 |
|---|---|---|---|
| master（開発の本線） | 1,037件 | 1,443件 | 約39%増 |
| 出たばかりの版のブランチ（2025年は18、2026年は19） | 724件 | 1,169件 | 約61%増 |
| 1つ前の版のブランチ（2025年は17、2026年は18） | 248件 | 433件 | 約75%増 |
master のコミットのうち、古い版にも入れた修正を除いた件数は、313件から274件に少し減っています。新しい開発はむしろ減り、増えたのは古い版にまで入れる必要のあるバグ修正でした。Haas 氏は、LLM のおかげでバグを見つけるのはとても楽になったが、直すのは少ししか楽になっていないと書いています。LLM が修正案を書いても、正しくなかったりプロジェクトの決まりに合わなかったりするため、最後は人がレビューしてコミットする必要があります。
PostgreSQL のコードは、CVS から移したものも含めると30年以上の履歴があります。Haas 氏は、自分が触った中でもきれいなコードだと評価したうえで、それでも何十年分のバグが LLM で見つかるようになったと述べています。セキュリティの問題と古い版のバグ対応に時間が取られ、19 で何を取り下げるかを決めるのも遅れました。
開発者として試すなら
アプリを PostgreSQL の上で動かしている人が気にするのは、今年の秋の日付です。公式のサポート期間の表と RC1 の案内をもとにまとめると、次のようになります。
| 日付 | できごと |
|---|---|
| 10月15日 | PostgreSQL 19 RC1 公開（済み） |
| 11月12日 | 14〜18 の定期更新、19 RC2 公開、PostgreSQL 14 のサポート終了 |
| 11月19日 | PostgreSQL 19 正式版（問題がなければ） |
14 をまだ使っているなら、11月12日のあとは修正が出ません。19 の正式版を待つより、サポートが2030年11月まで続く 18 へ先に上げるほうが確実です。18 の最新は 18.6 です。19 は RC2 がもう1回入る予定なので、本番で使うのは正式版を見てからにしておくと安心できます。
手元で 19 を試すなら、今のデータで pg_upgrade の事前チェックだけ流しておくと、移行で困る点が先にわかります。
pg_upgrade --check \
-b /usr/lib/postgresql/18/bin -B /usr/lib/postgresql/19/bin \
-d /var/lib/postgresql/18/main -D /var/lib/postgresql/19/main--check を付けると、データは変えずに、移行できるかどうかだけを確かめます。パスは環境に合わせて変えてください。
つまずきそうなのは、ベータで試した機能がなくなっていることです。ベータの間に FOR PORTION OF や SQL/PGQ、MERGE/SPLIT PARTITION を使うコードを書いていたなら、19 では動きません。RC1 では、COPY (query) TO ... (FORMAT json) の出力のキーに、別名も含めてクエリの列名を使うように変わっています。ベータの JSON 出力をもとにテストを書いていたら、キー名を確かめ直してください。
自分のプロジェクトでも、同じことが起きる可能性があります。LLM を使ったバグ報告や修正の pull request が増えると、レビューする人の時間が先に足りなくなります。Haas 氏の数字は、その負担がリリースの日付にまで出てきた例です。
これからどうなるか
次の節目は11月12日の RC2 と、11月19日の正式版です。RC1 の案内も、問題があれば正式版をさらに延ばすか候補版を足すと書いています。11月19日も確定ではありません。
長い目で見ると、Haas 氏は今回の遅れよりも、そのあとのほうを心配しています。何十年分のバグが LLM で見つかり続けるなら、修正に追われて新機能の開発が進まなくなるかもしれません。Haas 氏は、これからの新機能は AI に細かく調べられる前提で、開発者が質を上げるしかないと書いています。
使う側から見ると、古い版の定期更新に入る修正は、今後も多いままになりそうです。マイナー版の更新を年に数回まとめて当てているチームは、適用までの間をもう少し短くしておくと、見つかったバグの修正が早く手元に届きます。
まとめ
PostgreSQL 19 の正式版は11月19日の予定です。LLM で見つかったバグの修正が古い版にまで広がり、出たばかりの版のブランチへのコミットは前年の724件から1,169件に増えました。14 を使っているなら11月12日でサポートが終わるので、19 を待たずに 18 への移行を進めてください。
参考リンク
- Postgres 19 is late, and it’s AI’s fault（Robert Haas）
- Updated PostgreSQL RC / GA dates（pgsql-hackers）
- PostgreSQL 19 RC 1 Released!（PostgreSQL）
- Versioning Policy（PostgreSQL）
- PostgreSQL 19 Running Behind Schedule Due to AI/LLM Burden（Phoronix）
アイキャッチ画像: Photo by Glen Carrie on Unsplash
