LASSIC Media らしくメディア
PostgreSQL 13は2025年11月にEOL、移行を外注
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- PostgreSQL 13は2025年11月13日にコミュニティのサポートを終え、セキュリティ修正が提供されなくなりました。
- 移行手段にはpg_upgradeと論理レプリケーションがあり、前提条件やダウンタイムの傾向が異なります。
- 非互換の洗い出しから検証・切替設計までを担うには専門知識と工数が必要で、外部委託も選択肢になります。
目次
2025年11月13日、PostgreSQL13がコミュニティサポート終了
PostgreSQL（ポスグレ）は、オープンソースで開発されているリレーショナルデータベース管理システムです。そのメジャーバージョンの一つであるPostgreSQL 13は、2025年11月13日に最終マイナーバージョン13.23が公開されました*1。これをもって、PostgreSQL開発コミュニティのサポート期間を終えています。EOL（End of Life、サポート終了）とは、コミュニティが定めるバージョニングポリシーに基づき、更新提供の期限が到来した状態を指します*1。期限を過ぎたバージョンには、セキュリティ修正・不具合修正を含む更新が提供されません。稼働を続けるには、上位メジャーバージョンへの移行を計画する必要があります。
PostgreSQL 13は2020年9月24日に初回リリースされ、約5年間の提供期間を経てEOLを迎えました*1。この5年という期間は13だけの特例ではなく、PostgreSQLの全メジャーバージョンに共通するサポートポリシーです。次章でその全体像を整理します。
主要バージョンの初回リリースとEOL予定は次の通りです*1。
| バージョン | 初回リリース | サポート終了(EOL)予定 | 状態 |
|---|---|---|---|
| 13 | 2020年9月 | 2025年11月13日 | サポート終了 |
| 14 | 2021年9月 | 2026年11月12日 | サポート中 |
| 15 | 2022年10月 | 2027年11月11日 | サポート中 |
| 16 | 2023年9月 | 2028年11月9日 | サポート中 |
| 17 | 2024年9月 | 2029年11月8日 | サポート中 |
| 18 | 2025年9月 | 2030年11月14日 | サポート中 |
年1回リリース・5年サポート — PostgreSQLのバージョニングポリシー
PostgreSQLは年1回程度のペースでメジャーバージョンをリリースし、各メジャーバージョンは初回リリースから5年間サポートされます*1。5年が経過すると最終マイナーバージョンが公開され、それ以降は新たな修正が提供されません。
マイナーバージョンは3か月ごとに最低1回のペースで更新されます*1。マイナー更新は不具合修正が中心で、アプリケーション側への影響はほとんどありません。一方でメジャーバージョン更新は内部のシステムテーブル構成が変わるため、事前の検証が欠かせません*2。
このサイクルを踏まえると、稼働中のバージョンがEOLを迎える前に、次のメジャーバージョンへ移行する計画を運用に組み込むことが現実的です。システム企画の段階から次回のメジャーバージョンアップ時期を見込んでおくと、対応の遅れを防ぎやすくなります。放置した場合に生じるリスクを、次章で具体的に見ていきます。
移行を先送りするリスク — 脆弱性放置と非互換の蓄積
PostgreSQL 13をEOL後も稼働させ続けると、コミュニティからのセキュリティ修正が提供されません*1。そのため、新たに見つかった脆弱性への公式対応を受けられなくなります。個人情報や取引データを扱うシステムでは、この状態自体が監査や取引先からの指摘対象になりかねません。
移行を先送りするほど、稼働バージョンと最新バージョンのあいだで積み重なる仕様変更・非互換の量が増えます。1バージョン分の差分を検証する場合と、複数バージョン分をまとめて検証する場合とでは、洗い出す変更点の数そのものが異なります。着手が遅れるほど、確認作業の範囲が広がりやすくなる点に注意が必要です。
OS・接続ドライバ・拡張機能といった周辺ソフトウェアの側も、古いPostgreSQLバージョンへの対応を順次終えていきます。データベース単体の判断ではなく、周辺コンポーネントの対応状況もあわせて確認しておくことが欠かせません。
pg_upgradeと論理レプリケーション、2つの移行手段
PostgreSQL 13から上位バージョンへの移行では、pg_upgradeによる方式と論理レプリケーションによる方式が代表的な選択肢です*2*3。どちらを選ぶかによって、必要な準備期間や許容できる停止時間の考え方が変わります。
pg_upgradeは、PostgreSQL公式が提供するメジャーバージョン間アップグレードツールです*2。既存のデータファイルを再利用してアップグレードする方式で、ダンプ・リストア方式とは異なる仕組みです。–linkオプションでハードリンクを使う場合はデータのコピーが発生せず短時間で完了しますが、旧クラスタと新クラスタが同一ストレージ上にある必要があります*2。
論理レプリケーション（主キー等の識別子に基づき変更を段階的に反映するレプリケーション方式*3）は、PostgreSQLの標準機能の一つです。この方式は、異なるメジャーバージョン間でのレプリケーションに対応しています*3。新バージョンの環境をサブスクライバーとして稼働させながらデータを同期し、準備が整った時点で切り替える進め方のため、切替時間そのものを縮めやすい方式です。
pg_upgradeはオプティマイザの統計情報を新クラスタへ引き継ぎません。実行後はvacuumdbコマンドで統計情報を再生成する作業が必要です*2。この工程を省くと、アップグレード直後は実行計画の精度が下がり、クエリの応答が一時的に不安定になる恐れがあります。ディスク容量についても、リンクモードを使わない場合は旧クラスタと同等以上の容量を新クラスタ用に確保しておく必要があります*2。
両者は前提条件と運用の複雑さが異なるため、比較して選ぶことが大切です。
| 比較軸 | pg_upgrade | 論理レプリケーション |
|---|---|---|
| ダウンタイムの傾向 | リンクモードなら短時間で完了しますが、切替中はデータベースを停止します*2。 | 同期しながら稼働を続けられるため、切替時間を縮めやすい方式です*3。 |
| 前提条件 | リンクモード利用には旧新クラスタが同一ストレージ上にある必要があります*2。 | パブリケーション・サブスクリプションの設定と十分な同期期間が必要です*3。 |
| 切り戻しのしやすさ | 実行後の切り戻しは旧クラスタの保全状況に左右されます。 | 旧環境を稼働させたまま並行運用できるため、切り戻しの選択肢を残しやすい方式です。 |
| 運用の複雑さ | 手順自体は比較的定型的です*2。 | パブリケーション設計や初期同期の監視など、考慮点が増えます*3。 |
移行で直面する非互換 — 廃止パラメータと拡張機能
pg_upgradeには、実際の移行前に非互換を検出する–checkオプションが用意されています*2。データを変更せず検証だけを実行できるため、移行計画の初期段階で対象システムの互換性を洗い出す用途に使えます。
メジャーバージョン間では、設定パラメータの廃止やデフォルト値の変更が生じないとは言い切れません。拡張機能（PostgreSQLの機能を追加するモジュール）についても、対応バージョン範囲が変わることがあります。自社で導入している拡張機能が新バージョンに対応しているかどうかは、拡張機能の提供元ドキュメントで個別に確認する必要があります。
拡張機能を利用している場合は、新バージョン側にもあらかじめ共有オブジェクトファイル（.so）のインストールが必要です。拡張機能のスキーマ定義（CREATE EXTENSIONの実行）は不要で、旧クラスタの定義はpg_upgradeによって新クラスタに複製されます*2。この手順を誤ると、拡張機能の重複や移行失敗の原因になります。
アプリケーション側がPostgreSQLの内部仕様に依存した実装をしている場合は、SQLの挙動差や接続ドライバの対応バージョンも確認対象です。ORM（Object-Relational Mapping、プログラムのオブジェクトとデータベースを対応付ける仕組み）を利用している場合は特に注意が必要です。接続ドライバのバージョン対応表を事前に確認しておくと、想定外の不具合を防ぎやすくなります。検証範囲を「データベース単体」ではなく「接続するアプリケーション全体」で捉える必要があります。
内製と外部委託の分岐点 — 検証体制と工数
PostgreSQL 13を内製で移行する場合、pg_upgrade・論理レプリケーションいずれの方式でも専門知識が必要です。具体的には、バージョン差分の把握、拡張機能・接続ドライバの互換性調査、検証環境の構築、切替手順の設計が求められます。これらを1名が兼務で担当する体制では、通常業務と並行しての対応が負荷になりやすい傾向があります。
切替のダウンタイム設計も内製対応の負荷が大きい領域です。切替時間を縮めるほど、事前のリハーサル回数や監視体制の準備は増えます。検証環境での移行リハーサルと、本番切替時の立ち会い・監視、両方に人員を割り当てる必要があります。
外部パートナーに委託する場合は、非互換の洗い出しから検証環境の構築、切替時の立ち会い、切替後の監視までを一括して依頼できるかどうかが選定の分かれ目です。内製は既存体制をそのまま活用できる一方、外部委託は専門知識を持つ体制に短期間で対応を任せやすいという違いがあります。自社の運用体制とスケジュールの余裕を踏まえて判断することが欠かせません。
まとめ：PostgreSQL13移行で押さえる3つの判断軸
本稿ではPostgreSQL 13のサポート終了(EOL)を起点に、バージョニングポリシー・移行手段・非互換対応を整理しました。要点は3つに集約できます。第一に、PostgreSQL 13は2025年11月13日にコミュニティサポートを終え、以降はセキュリティ修正が提供されません。第二に、移行手段にはpg_upgradeと論理レプリケーションがあり、前提条件とダウンタイムの縮め方が異なります。第三に、非互換の洗い出しから検証・切替までを内製で担うには専門知識と工数が必要であり、社内リソースとの兼ね合いで外部委託の選択肢を検討する価値があります。
よくある質問
PostgreSQL 13を今のまま使い続けるとどうなりますか。
PostgreSQL 13は2025年11月13日でコミュニティのサポートが終了しています*1。そのため、新たに脆弱性が見つかっても公式のセキュリティ修正を受けられません。稼働を続けるほど周辺ソフトウェアの対応終了も重なりやすく、早めの移行計画が望まれます。
マイナーバージョン更新とメジャーバージョン更新は何が違いますか。
マイナーバージョン更新は不具合修正が中心で、互換性への影響はほとんどありません*1。メジャーバージョン更新は内部のシステムテーブル構成が変わるため、pg_upgradeや論理レプリケーションを使った事前の検証が欠かせません*2。
ダウンタイムはどの程度に縮められますか。
採用する移行方式や検証範囲によって変わります。pg_upgradeのリンクモードや論理レプリケーションは、ダンプ・リストア方式に比べて切替時間を縮めやすい方式です*2*3。ただし、事前の性能検証と体制準備が必要です。
移行を外部委託する場合、何を確認すればよいですか。
検証環境の構築範囲、非互換の洗い出し方法、切替時の立ち会い体制、障害時の切り戻し手順を委託先とすり合わせることが大切です。契約前に成果物と検証項目を明確にしておくと、後工程の手戻りを防ぎやすくなります。
移行先はPostgreSQLの最新バージョンを選ぶべきですか。
移行先の選定では、自社のOS・ミドルウェア・接続ドライバの対応状況とあわせて検討することが大切です。新しいメジャーバージョンほどサポート終了までの期間を長く確保できるため、次の移行までの運用期間に余裕を持たせやすくなります*1。利用中の拡張機能が移行先バージョンに対応しているかも、あわせて確認が必要です*2。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：PostgreSQL Global Development Group「Versioning Policy」（https://www.postgresql.org/support/versioning/）
- *2 出典：PostgreSQL公式ドキュメント「pg_upgrade」（https://www.postgresql.org/docs/current/pgupgrade.html）
- *3 出典：PostgreSQL公式ドキュメント「Logical Replication」（https://www.postgresql.org/docs/current/logical-replication.html）
