PostgreSQLの各メジャーバージョンについて、リリース日・5年間のサポート期間・EOL（サポート終了）の意味を、現行バージョンをまだ運用しているチーム向けにまとめた完全リファレンス。
PostgreSQLは業界で最も愛されているリレーショナルデータベースの一つであり、最も広く使われているデータベースでもあります。単一テナントのSaaSバックエンドから、Apple・Instagram・Spotifyのようなペタバイト級の分析基盤まで、幅広く採用されています。またPostgreSQLは厳格で予測可能なライフサイクルを持ち、新しいメジャーバージョンはおよそ年1回リリースされ、各メジャーバージョンはリリースから正確に5年間サポートされた後にEOL（End of Life：サポート終了）を迎えます。
エンジニアリングチームやプラットフォームチームにとって、この予測可能性には2つの側面があります。スケジュールは計画しやすい一方で、メジャーバージョンのアップグレードはほとんどの場合、簡単な作業ではありません。pg_upgradeや論理レプリケーションによる切り替え、拡張機能の互換性チェック、プランナーの回帰テスト、そして本番データを保持するステートフルなシステムに対するメンテナンスウィンドウの確保が必要になります。その結果、稼働中のPostgreSQLインスタンスの多くが、すでにEOLを迎えているか、EOLまで1年を切ったバージョンで運用され続けているのが実情です。
本記事は、PostgreSQLの全メジャーバージョンについて、リリース日、EOL日、古いリリースに影響するCVE、そしてコミュニティによるパッチ提供が終了した後の選択肢をまとめた決定版リファレンスです。
PostgreSQLのサポートポリシーの仕組み
PostgreSQL Global Development Group（PGDG）は、オープンソースの中でも特に明確なサポートポリシーの一つを採用しています。
- メジャーバージョンのリリース周期: 新機能を含むメジャーバージョンはおよそ年1回リリースされます。PostgreSQL 10以降はメジャーバージョンが最初の数字1つで表されます（例: 14から15）。10より前は最初の2つの数字で表されていました（例: 9.5から9.6）。
- マイナーリリース: サポート対象の各メジャーバージョンには、少なくとも3か月に1回、バグ修正とセキュリティ修正を含むマイナーリリースが提供されます。マイナーリリースには新機能は含まれず、ディスク上の互換性を壊すこともないため、適用のリスクは低いとされています。緊急の修正が必要な場合は、定期スケジュール外のリリースが行われることもあります。
- 5年間のサポート期間: PGDGは各メジャーバージョンを初回リリースから5年間サポートします。5年目の節目を迎えると、残っている修正をまとめた最終マイナーリリースが1回提供され、その後EOL（サポート対象外）となります。
PostgreSQLには「LTS」というティアは存在しません。すべてのメジャーバージョンが同じ5年間のサポートを受け、その後はコミュニティから何も提供されなくなります。セキュリティパッチもバグ修正も互換性アップデートもありません。PGDG自身のガイダンスでも、使用中のメジャーバージョンについては常に最新のマイナーリリースを実行することが推奨されています。
PostgreSQLバージョン完全タイムライン
現在サポート中のバージョンは「サポート中」、5年間のサポート期間を過ぎたバージョンは「EOL」として、元記事内の一覧表にまとめられています。正確な日付を含む一覧表は分量が多いため、本翻訳では割愛しています。詳細は元記事の該当表を直接ご確認ください。
PostgreSQL 9.3以前のバージョンは、すでに7年以上前にEOLを迎えており、深刻なリスクにさらされている状態として扱うべきです。
次にEOLを迎えるバージョン：注視すべきポイント
PostgreSQL 14のEOL：2026年11月12日
PostgreSQL 14は2021年9月30日にリリースされたため、5年後のEOL日は2026年11月12日となります。この日以降、バージョン14は最終マイナーリリース（現時点の最新は14.23）を受け取った後、コミュニティからのパッチ提供が一切なくなります。
PostgreSQL 14は、現時点でプラットフォームチームが最も注視すべきバージョンです。特にメジャーバージョンアップグレードが先送りにされてきたマネージドサービス環境では依然として非常に多く使われており、そのEOL時期はすでに「次のマイナーリリースが来るかどうか」という射程圏内に入っています。もし2026年11月12日以降に重大な脆弱性が公表された場合、PostgreSQLコミュニティはバージョン14向けの修正を提供しません。
PostgreSQL 13のEOL：2025年11月13日
PostgreSQL 13は2025年11月13日にEOLを迎えました。最終マイナーリリースの13.23は2025年11月10日にリリースされています。それ以降にバージョン13に対して公表された脆弱性は、コミュニティ配布版では永久に未修正のままとなります。バージョン13を使い続けているチームは、現在サポート対象外のデータベースエンジンを運用していることになります。
PostgreSQL 12のEOL：2024年11月21日
PostgreSQL 12は2024年11月21日にEOLを迎え、12.22が最終のコミュニティリリースとなりました。バージョン12はすでに1年半以上サポート対象外の状態が続いており、マネージドプロバイダーの中には、いまだにバージョン12を使い続けているインスタンスに対して強制アップグレードや延長サポート料金の請求を始めているところもあります。
PostgreSQL 14以前に影響するCVE
PostgreSQLのセキュリティ実績は優れていますが、「優れている」ことは「CVEが存在しない」ことを意味しません。最近、いくつかの深刻度の高い脆弱性が公表されており、そのパターンには注目すべき特徴があります。同じ欠陥が、14や13を含むサポート対象の全ブランチに一度に影響することが常態化しているのです。あるブランチがEOLを迎えると、このパターンに沿った次の脆弱性公表は、そのブランチに対しては単純に未修正のまま放置されることになります。
CVE-2025-1094（CVSS 8.1）：psqlのSQLインジェクション
最近のPostgreSQL関連の脆弱性の中でも特に重大なものです。CVE-2025-1094は、libpqのエスケープ関数（PQescapeLiteral()、PQescapeIdentifier()、PQescapeString()、PQescapeStringConn()）およびpsql対話型ターミナルにおける、クォート構文の不適切な無害化処理に起因する深刻度の高いSQLインジェクション脆弱性です。特定のエンコーディング条件下では、攻撃者がエスケープ処理を回避してSQLを注入でき、さらにpsqlのメタコマンド（*!*など）を利用してOSコマンドの任意実行にまでエスカレーションできる可能性があります。
この脆弱性はRapid7が、CVE-2024-12356に関連するBeyondTrust侵害事案の分析中に発見したもので、パッチ適用前には著名な標的に対する実際の悪用にも関与していたとされています。
- 影響を受けるバージョン: 17.3、16.7、15.11、14.16、13.19より前のすべてのバージョン
- 修正バージョン: 17.3、16.7、15.11、14.16、13.19（2025年2月13日リリース）
CVE-2025-8714（CVSS 8.8）：pg_dumpのリストア時コードインジェクション
オリジンサーバー上の悪意あるスーパーユーザーが、psqlのメタコマンドを含むオブジェクト名を細工することで、リストアを実行しているOSアカウントとしてコードを実行させることが可能な脆弱性です。この問題はpg_dump、pg_dumpall、pg_restoreがプレーン形式のダンプを生成する際に及びます。
- 影響を受けるバージョン: 17.6、16.10、15.14、14.19、13.22より前のすべてのバージョン
- 修正バージョン: 17.6、16.10、15.14、14.19、13.22（2025年8月14日リリース）
CVE-2025-8715（CVSS 8.8）：pg_dumpの改行インジェクションとリストア先へのSQLインジェクション
2025年8月14日に同時公表された、密接に関連する脆弱性です。オブジェクト名内の改行に対する不適切な無害化処理により、オリジンサーバーのユーザーが、リストア時にpsqlを実行しているOSアカウントとして任意のコードを注入できる可能性があります。同じ攻撃手法により、リストア先サーバーでスーパーユーザーとしてSQLインジェクションを達成することも可能です。pg_dumpall、pg_restore、pg_upgradeも影響を受けます。
- 影響を受けるバージョン: 17.6、16.10、15.14、14.19、13.22より前のすべてのバージョン（11.20より前のバージョンは影響を受けません）
- 修正バージョン: 17.6、16.10、15.14、14.19、13.22（2025年8月14日リリース）
CVE-2025-8713（CVSS 3.1）：オプティマイザ統計情報の漏えい
深刻度は低いものの、示唆に富む脆弱性です。細工された「漏えい」オペレーターを使うことで、オプティマイザ統計システム経由でビューのACLや行レベルセキュリティポリシーを回避し、本来クエリを実行するユーザーが閲覧できないはずのヒストグラムや最頻値データを露出させることが可能です。これは、CVE-2017-7484やCVE-2019-10130で対処されたはずの問題のクラスが再発したものです。
- 影響を受けるバージョン: 17.6、16.10、15.14、14.19、13.22より前のすべてのバージョン
- 修正バージョン: 17.6、16.10、15.14、14.19、13.22（2025年8月14日リリース）
CVE-2025-4207（CVSS 5.9）：GB18030バッファオーバーリード
GB18030エンコーディングの検証処理におけるバッファオーバーリードにより、データベースへの入力を提供する主体が、一時的なサービス拒否（DoS）を引き起こせる可能性があります。1バイトのオーバーリードでプロセスがクラッシュするプラットフォームでは特に影響が大きく、サーバー側とlibpqの両方に及びます。
- 影響を受けるバージョン: 17.5、16.9、15.13、14.18、13.21より前のすべてのバージョン
- 修正バージョン: 17.5、16.9、15.13、14.18、13.21
PostgreSQL 14を使っているすべてのチームにとっての教訓は次の通りです。上記のCVEはいずれも、修正には14.xのマイナーアップグレードが必要でした。この仕組みは2026年11月12日をもって使えなくなります。EOL後に同じパターンの脆弱性が発生すれば、バージョン14はコミュニティによる修正手段がないまま脅威にさらされることになります。
EOL後に起こること
PostgreSQLのメジャーバージョンがEOLを迎えると、次の3つが起こります。
-
セキュリティパッチの提供が止まる。 エンジン、libpq、クライアントユーティリティに対して新たに公表されたCVEは、そのブランチに対しては修正されません。最近のSQLインジェクションやコードインジェクション系CVEが全ブランチに同時に影響してきたパターンを踏まえると、これは理論上のリスクではなく、具体的かつ繰り返し発生するリスクです。
-
プラットフォームおよびエコシステムとの互換性が低下する。 マネージドプロバイダーは、新規インスタンスへのEOLエンジンバージョンの提供を停止し、強制アップグレードや延長サポート料金の請求を始めます。Amazon RDS、Google Cloud SQL、Azure Database for PostgreSQLはいずれも、コミュニティでEOLとなったバージョンからの移行を課金対象にするか、強制的に促します。新しい拡張機能、クライアントドライバー、OSパッケージもEOLサーバーバージョンに対するテストを打ち切るため、スタック内の他部分をアップグレードした際に、互換性の問題が徐々に表面化していきます。
-
コンプライアンス監査で指摘される。 SOC 2、PCI DSS、HIPAA、FedRAMP、EUサイバーレジリエンス法はいずれも、保守・パッチ適用がなされたソフトウェアの使用を求めています。EOLを迎えたデータベースエンジンは、スキャナーが「EOL/サポート対象外ソフトウェア検出」として指摘する典型例であり、監査人の指摘を回避するのは年々難しくなっています。
データベース特有の厄介な点は、アップグレードがステートフルであることです。ステートレスなアプリケーション依存関係とは異なり、PostgreSQLのメジャーバージョン移行では、pg_upgradeや論理レプリケーションによる本番データの移行、拡張機能の互換性検証（PostGIS、TimescaleDB、pg_partmanなどの拡張機能は移行元・移行先の両方に対応している必要があり、しばしば障害となります）、プランナーや挙動の回帰チェック、切り替えウィンドウのスケジューリングが必要になります。だからこそ、多くのインスタンスがEOLバージョンのまま残されているのです。アップグレードは、破損させるわけにはいかないシステムに対する、実質的な作業負荷を伴います。
EOLを迎えたPostgreSQLバージョンへの対応策
PostgreSQL 14（EOLが近づいている）、13、12のいずれかを運用している場合、現実的な選択肢は3つあります。
1. サポート対象のメジャーバージョンへアップグレードする。 ほとんどのチームにとって、長期的に正しい選択です。インプレースでの移行にはpg_upgradeを、ダウンタイムを抑えた切り替えには論理レプリケーションを使い、拡張機能の互換性テストとプランナーの回帰検証の予算も確保しましょう。コストはエンジニアリング時間、メンテナンスウィンドウ、そしてステートフルなシステムを移行することに伴う固有のリスクです。だからこそ、これは決して「今四半期中に決められる」ような話ではありません。
2. マネージドの延長サポートに対価を払う。 RDS、Cloud SQL、Azureを利用している場合、プロバイダーが有料でEOLバージョンにパッチを提供し続けてくれます。時間は稼げますが、従量課金で費用が上がっていくことが多く、自社の裁量ではなくプロバイダーのパッチ範囲やスケジュールに縛られることになります。
3. 商用のNever-Ending Supportを採用する。 HeroDevsのPostgreSQL向けNever-Ending Support（NES）は、EOLを迎えたPostgreSQLに対する安全なドロップイン代替であり、コミュニティサポート終了当日からセキュリティパッチを提供し、カバレッジに空白期間が生じません。NESは現在PostgreSQL 12.x、13.x、14.xに対応しており、データ移行もエンジンの入れ替えも不要です。現在使用しているバージョンをそのまま維持したまま、ドロップイン代替をインストールするだけです。SOC 2、FedRAMP、PCI DSS、HIPAAに対応するエンタープライズSLAに裏付けられており、セキュリティやデータ破損に関する問題には即日対応します。これは、タイトなスケジュールでメジャーバージョン移行を強行することなく、コンプライアンスとパッチ適用を維持し続けたいチームに向いた選択肢です。
クイックリファレンス：使用中のPostgreSQLバージョンはサポート対象か
各バージョンのサポート状況を一覧化した表が元記事に掲載されています。詳細は元記事をご確認ください。
よくある質問
PostgreSQL 14はいつEOLを迎えますか？
PostgreSQL 14は、2021年9月30日のリリースから5年後にあたる2026年11月12日にEOLを迎えます。それ以降、PostgreSQLコミュニティは14.xの最終マイナーリリースを提供した後、バージョン14に対するセキュリティパッチ、バグ修正、アップデートの提供を停止します。
PostgreSQL 13はまだサポートされていますか？
いいえ。PostgreSQL 13は2025年11月13日にEOLを迎えました。最終のコミュニティマイナーリリースは13.23です。それ以降にバージョン13に対して公表された脆弱性は、PostgreSQLコミュニティによって修正されることはありません。
各PostgreSQLバージョンのサポート期間はどれくらいですか？
各PostgreSQLメジャーバージョンは、初回リリースから5年間サポートされます。この期間中、少なくとも3か月に1回、バグ修正とセキュリティパッチを含むマイナーリリースが提供されます。コミュニティによる延長LTSティアはありません。
EOLを迎えたPostgreSQLバージョンを運用するリスクは何ですか？
EOLバージョンを運用するということは、新たに公表されるCVEに対するセキュリティパッチが提供されないこと、マネージドプロバイダーや広いエコシステムとの互換性が低下していくこと、そしてSOC 2、PCI DSS、HIPAA、FedRAMP、EUサイバーレジリエンス法などのフレームワークに対するコンプライアンス指摘を受けることを意味します。最近のPostgreSQL関連CVE（CVSS 8.1のpsql SQLインジェクションであるCVE-2025-1094を含む）はサポート対象の全ブランチに同時に影響したため、EOLブランチは同様のパターンの脆弱性が次に出現した際、無防備にさらされることになります。
PostgreSQL 12、13、14のEOL後もセキュリティパッチを入手できますか？
はい。HeroDevsのPostgreSQL向けNever-Ending Support（NES）は、PostgreSQL 12.x、13.x、14.xに対して、コミュニティサポート終了当日から、移行不要のドロップイン代替として継続的なセキュリティパッチを提供します。SOC 2、FedRAMP、PCI DSS、HIPAAに準拠したエンタープライズSLAも備えています。
今すぐ取るべき行動
PostgreSQLの5年サイクルは、スタックの中で最も予測しやすいソフトウェアライフサイクルであると同時に、本番データに直接影響するアップグレードであるがゆえに、最も対応が難しいものの一つでもあります。バージョン12と13はすでにEOLを迎えており、バージョン14も2026年11月12日にそれに続きます。稼働中の全ブランチに対してCVEが公表され続けており、マネージドプロバイダーは延長サポート条件を厳しくしつつあり、コンプライアンスフレームワークはサポート対象外のソフトウェアを明確に指摘するようになっています。
アップグレードするにせよ、クラウドプロバイダーに延長サポート料金を払うにせよ、NESを採用するにせよ、本当にリスクを伴う唯一の選択肢は、パッチ適用手段のないままEOLバージョンを使い続けることです。PostgreSQL 12、13、14を運用していて、緊急移行なしでセキュリティとコンプライアンスを維持したい場合は、PostgreSQL向けNESの詳細を確認するか、HeroDevsにお問い合わせください。
お問い合わせ
本記事の内容やHeroDevsのソリューション（NES等）について、日本語でのお問い合わせに対応しています。お気軽にHeroDevsお問い合わせページからご連絡ください。
原文: https://www.herodevs.com/blog-posts/postgresql-eol-dates-every-versions-release-end-of-life-timeline （出典: herodevs.com）