PostgreSQL 14のサポート終了まで残り2か月：アップグレードより先にリカバリを練習する
データベースのバージョンアップのスケジュールは決めたものの、失敗した際のロールバックにかかる時間を把握していないチームがあります。PostgreSQL 14を運用している場合、今必要な成果物は新しいバージョンの名前1つではなく、復旧が可能な移行計画です。2026年9月14日時点で、公式サポート終了日まで残り約2か月となっています。
確認された事実：コミュニティサポートとホスティング契約は異なります
PostgreSQLの公式バージョンポリシーではメジャーバージョンを5年間サポートすることになっており、14の最終リリース日は2026年11月12日と案内されています。これはコミュニティのサポート日程です。マネージドサービスのアップグレード期間、個別の延長サポート、料金については、各事業者のドキュメントや契約で個別に確認する必要があります。
同じメジャーバージョン内のマイナーアップデートとメジャーアップグレードも区別しなければなりません。14の最新マイナー修正バージョンを適用することは、15以降への移行の代わりにはなりません。逆に、メジャー移行の計画があるからといって、現行バージョンに必要な修正の適用を先延ばしにし続けるのも適切ではありません。
最初の成果物：データサイズよりも依存関係のリスト
ここからは公式サポートポリシーそのものではなく、実務運用の提案です。まずはサービスごとのDBバージョン、拡張モジュールとそのバージョン、接続ドライバー、バッチジョブ、バックアップ保管場所、レプリケーション構成を1枚のシートにまとめます。移行対象のバージョンは最新であるという理由だけで決めるのではなく、実際のホスティング環境や拡張モジュールのサポート範囲も合わせて確認します。
小規模なDBだから短時間で済むだろうという仮定は十分ではありません。ログイン後の初回照会や決済ステータスの更新など、ビジネス上重要なクリティカルパスで使用されている拡張モジュールやクエリが変われば、データコピーが短時間で終わっても移行は失敗する可能性があります。担当責任者が不在の依存関係を見つけ出すことが、このリストの目的です。
2つ目の成果物：バックアップ成功メッセージではなくリストア結果
隔離された環境に直近のバックアップをリストアし、アプリケーションの代表的な読み取り・書き込みフローを実行します。このリハーサルでは本番DBに書き込みを行わないよう、接続先をあらかじめ確認しておく必要があります。実データが含まれるリストア環境は、既存のアクセス制御の範囲内で取り扱います。
バックアップ開始時刻、リストア完了時刻、検証完了時刻を切り分ければ、ファイルを取得する時間とサービスが再び書き込み可能になる時間を混同せずに済みます。不自然に軽量な小規模サンプルだけを通すのではなく、本番環境の規模に近いリストアデータで時間を計測し、コストやストレージ容量の制約も記録します。
pg_upgradeのチェック通過はサービス検証の代わりになりません
公式のpg_upgradeドキュメントでは、--checkオプションを使用することで実際のアップグレード前に互換性チェックを実行できると説明されています。外部モジュールの互換性は個別に確認する必要があり、新しいサーバーに適した共有ライブラリも必要です。チェックコマンドの成功だけで、アプリケーションのクエリやパフォーマンスがすべて検証されたと解釈してはいけません。
特に--link方式には、新しいクラスタを起動した後に元のクラスタをそのまま使用できなくなるという制約があります。速度だけを見てこの方式を選択すると、想定していたロールバック経路が失われる恐れがあります。実際の移行方式と同一の条件でリハーサルを行い、リストアによるロールバックが必要となるデッドラインを明記しておく必要があります。
書き込み再開前に決めておくべき基準
移行当日にその場で合意を図る事態を避けるため、成功基準をあらかじめ文書化しておきます。たとえば、中核APIの読み取り・書き込みの完了、重複処理のないバッチ再開、主要テーブルの業務集計の一致、レプリケーション状態の確認などを各担当者に紐付けることができます。これはすべてのサービスに画一的な基準値を強制する例ではありません。
新しいDBで書き込みを開始した後に以前のバックアップへロールバックする場合、その間の変更データをどのように保持するかも問題となります。単に以前のサーバーを起動する手順と、データ損失なしに復旧させる手順を同一視してはいけません。許容可能なデータ損失とダウンタイムの範囲は、サービスの責任者があらかじめ合意しておく必要があります。
今週取り組むべきことと予想される反論
一度にすべてのDBを移行するのが困難な場合は、最も依存関係の少ないサービスを1つ選んでリストア・検証・ロールバックの時間を測定し、その結果を他のサービスの計画策定に活用してください。担当者、移行候補日、検証失敗時の移行中止基準を1つのドキュメントにまとめることで、単に日程があるだけのプロジェクトから実行可能なタスクへと変化します。
目先のプロダクト開発の方が優先度が高いという反論は理解できます。しかし、期限直前まで復旧方法が分からない状態のまま放置すれば、選択できる検証期間は限られていきます。本記事は特定バージョンの性能向上やコミュニティ全体の意見を主張するものではありません。最新機能を導入するスピードよりも、移行失敗に対処する備えに焦点を当てた運用上の提案です。