2026 PostgreSQL 14 サポート終了前に、拡張機能の互換性をどう確認する？

PostgreSQL 14のサポート終了が迫る一方、利用中の拡張機能が移行先で動くか判断できない。
最短の確認方法は、移行先の拡張ファイルと更新経路を調べ、隔離環境でアプリの機能まで検証することです。未検証のまま本番を切り替えないでください。

この内容は、PostgreSQL 14の自前インスタンスを管理し、拡張機能を棚卸ししたいDBA向けです。
拡張機能を呼び出すアプリの動作を確かめたいバックエンドエンジニアや、切り替え日を判断するSaaSの技術責任者にも役立ちます。

最終更新日：2026年10月28日。日付はPostgreSQL公式のバージョン別サポート期間と14系のリリース情報で確認しています。

PostgreSQL 14の期限と拡張機能の互換性は別に確認します

PostgreSQL公式のサポート情報では、PostgreSQL 14は2026年11月12日に更新提供の終了を迎える予定です。期限は公式のバージョン管理方針で再確認してください。停止日は移行計画を立てる理由になりますが、拡張機能の互換性を一括で判断する材料にはなりません。

この記事で扱うのは、拡張機能の依存関係と移行先の検査です。PostgreSQL 17と18のどちらを選ぶかという判断や、移行全体の手順とは切り分け、まず「何が本番切り替えを止めているか」を特定します。

互換性の確認では、少なくとも次の条件を分けて考えます。

• 移行先に拡張機能のファイルがあり、その環境で利用できるか。
• 現在の拡張バージョンから、移行先が提供するバージョンへ更新できるか。
• アプリケーションやDBオブジェクトが使う機能が、移行先でも意図どおり動くか。

導入済み一覧と実際の依存関係を分けます

拡張機能はデータベースごとに導入されるため、クラスタ内のすべてのデータベースを確認してください。接続したデータベースで次のSQLを実行すると、導入済みの拡張名、バージョン、スキーマを調べられます。pg_extensionの列の意味は公式カタログ説明を参照してください。

SELECT e.extname, e.extversion, n.nspname AS schema_name
FROM pg_extension AS e
JOIN pg_namespace AS n ON n.oid = e.extnamespace
ORDER BY e.extname;

この結果は「そのデータベースに導入済みの拡張機能」の一覧です。未導入でもアプリのスクリプトが利用を予定しているものや、拡張が提供する関数・型・演算子に依存するオブジェクトまでは、これだけでは分かりません。

一覧を補うため、次の場所も調べます。

• DB作成スクリプト、マイグレーション、初期化用SQLにあるCREATE EXTENSIONや拡張機能名。
• ビュー、関数、インデックス、型などのDBオブジェクトと、アプリのSQLや設定ファイル。
• デプロイ手順、接続プログラム、ORMの設定、バックアップ・リストア手順にある依存関係。

導入済みの一覧と、アプリが実際に呼び出す機能は一致するとは限りません。コードや運用スクリプト側の依存を集めてから、拡張ごとの確認記録にまとめてください。

同じ拡張名があっても利用できるとは限りません

移行先のPostgreSQLで、まず利用可能な拡張機能を確認します。pg_available_extensionsは、その環境で利用可能な拡張と既定バージョンなどを確認するビューです。定義と列は公式リファレンスで確認できます。

SELECT name, default_version, installed_version
FROM pg_available_extensions
ORDER BY name;

確認するのは移行元ではなく、実際に切り替える移行先環境です。拡張機能はファイルやバージョン情報を含むため、同名の拡張が表示されるだけでは、現在のバージョンから更新できることやアプリの使い方に対応することまでは証明できません。拡張機能の仕組みは公式の拡張機能文書と、各拡張の提供元が示す対応情報を照合してください。

拡張ごとに、移行先に必要なファイルがあるか、移行元と移行先のバージョンおよび更新経路を確認できたか、アプリが使う機能を隔離環境で試したかを記録します。対象版にファイルがない、更新経路が分からない、提供元の対応情報が確認できない場合は「未確認」とし、互換とみなさないでください。

pg_upgradeの検査とアプリの受け入れ試験を分けます

pg_upgrade --checkは、実際にクラスタを切り替える前に、移行処理上の問題を確認するために使います。基本形は次のとおりです。実際のパスと起動条件は、利用する移行先のpg_upgrade公式文書に従ってください。

pg_upgrade --check \
  -b <移行元のbinディレクトリ> \
  -B <移行先のbinディレクトリ> \
  -d <移行元データディレクトリ> \
  -D <移行先データディレクトリ>

検査が失敗した場合は、まず次の問題に分けて調べます。

• 拡張のファイルがない：移行先に必要な拡張ファイルが導入されているか確認します。
• 更新経路がない：拡張のバージョン情報と提供元の手順を照合し、更新方法や代替案を検討します。
• 依存オブジェクトが残っている：拡張を削除する前に、その拡張が提供する型、関数、インデックスと業務上の依存を確認します。

pg_upgrade --checkの成功だけで、アプリケーションの機能が正常に動くとは判断できません。出力とログを拡張一覧に照らし、移行処理の問題とアプリ側の動作確認を別々に管理してください。

隔離環境ではアプリが使う機能を確かめます

移行先で拡張を読み込めても、業務で使うクエリやDBオブジェクトまで正しく動くとは限りません。本番と分離した環境で、実際のアプリの処理に沿って検証します。

• 拡張が提供する関数、型、演算子を使う重要な処理を実行します。
• 拡張に依存するインデックスを使った検索や更新を確認します。
• マイグレーション、接続プログラム、ORMからの接続を確認します。
• バックアップから復元した環境でも、同じ処理と拡張の状態を確認します。

結果には、移行元と移行先のバージョン、実行手順、エラー内容、回避策、戻す方法を残します。性能測定をしていないなら、互換性が確認できたことと性能が同等であることを混同しないでください。

拡張機能の確認状況から切り替え可否を決めます

次のチェックリストを拡張ごとに記入してください。未確認の項目が残る場合は、本番へ進まず、その項目を検証環境で解消します。

• [ ] 各データベースの導入済み拡張とバージョンを記録した。
• [ ] アプリ、DBオブジェクト、マイグレーションにある拡張依存を確認した。
• [ ] 移行先に必要な拡張ファイルがあり、対象バージョンが利用できることを確認した。
• [ ] 現在のバージョンから移行先のバージョンへの更新経路を確認した。
• [ ] pg_upgrade --checkの結果とログを確認し、問題を分類した。
• [ ] 隔離環境で主要な関数、クエリ、インデックス、アプリ接続を試した。
• [ ] バックアップから復元できることと、失敗時の切り戻し手順を確認した。

すべてにチェックが入り、機能試験も成功している場合は、切り戻し手順を準備したうえで本番切り替えを計画できます。検査は通ったがアプリ試験が未完了の場合は、アプリが使う機能を隔離環境で確認するまで延期してください。拡張ファイルや更新経路を確認できない場合は、未確認のまま互換と判断せず、提供元の情報や代替案を調べます。依存関係が不明な拡張を削除すれば検査を通せそうな場合も、削除せず、業務への影響をテスト環境で確かめてから判断してください。

停止期限が近いことだけを理由に、未確認の拡張を削除したり、検査結果を読み飛ばしたりしないでください。拡張の更新や変更を行う場合は、検証環境で動作を確かめ、失敗時に戻せる手順を用意します。

バックアップと移行先のサーバー条件を合わせます

切り替え前には、バックアップから実際に復元できることを確認し、機外にもバックアップを保管します。独立サーバーを使っても自動的に冗長化されるわけではありません。ハードウェアRAIDがない構成なら、必要に応じてソフトウェアRAIDやレプリケーションを設計し、バックアップとは別の障害対策として運用してください。PostgreSQL公式のバックアップとリストアの説明も参照できます。

移行先を選ぶ際は、拡張機能が必要とするOSやファイルを導入できるか、データとログの容量を確保できるか、検証用と本番用の構成に無理がないかを先に確認します。OSの選択肢やリソースの見方は、サーバーのメモリーとディスク構成を考える案内も参考にしてください。

OSFP Cloudの物理サーバーでは、128GBまたは256GBのDDR4-3200 ECCメモリー、直結NVMe、AlmaLinuxやDebian、Ubuntuなどの選択肢があります。実際に選べる構成とOSはOSFP Cloudの案内で照合してください。拡張機能の導入やPostgreSQLの移行作業を代行するサービスではないため、必要なファイルと作業手順は利用者側で確認する必要があります。Linuxへの接続方法はSSH接続の案内で確認できます。

マネージドデータベースでは、拡張機能の提供範囲やOS側の変更に制約がある場合があります。共有クラウド構成では、CPUやストレージの条件がサービス仕様に左右され、ディスク配置を自由に決められないこともあります。こうした制約が移行検証の妨げになるなら、専有CPUと直結NVMeを使い、拡張やデータ配置を自分で管理できるOSFP CloudのAMD物理サーバーが候補になります。

ただし、専有サーバーを選んでもバックアップ、冗長化、拡張機能の互換性確認は別途必要です。実際のワークロードと必要なOS・ディスク構成を照合し、復元演習と切り替え手順を整えてから本番移行を判断してください。

よくある質問

PostgreSQL 14から移行する前に、インストール済み拡張機能はどう調べますか？

各データベースへ接続して、pg_extensionから拡張名とインストール済みバージョンを確認します。ただし、これは導入済みの一覧であり、アプリが利用する機能の完全な一覧ではありません。マイグレーションスクリプト、DBオブジェクト、アプリのSQLや設定も合わせて調べてください。

拡張機能が移行先のPostgreSQLでも使えるか、何を確認すればよいですか？

移行先のPostgreSQL環境で拡張機能の制御ファイルや関連ファイルが利用できること、現在の拡張バージョンから更新できる経路があることを個別に確認します。同じ拡張名が一覧にあるだけでは互換性の証明になりません。提供元の対応情報も照合し、隔離環境で実際の機能を検証してください。

pg_upgradeで拡張機能の互換性をどこまで検査できますか？

pg_upgrade --checkは、クラスタを切り替える前に検出できる移行上の問題を確認するための検査です。対象環境に必要な拡張ファイルがあるかなど、実行結果とログを確認できますが、アプリケーションが使う関数や検索結果まで保証するものではありません。アプリの検証を別途行ってください。

PostgreSQLをアップグレードした後、拡張機能も別に更新する必要がありますか？

必要かどうかは拡張機能ごとに異なります。移行先に用意された拡張バージョン、提供されている更新経路、提供元の手順を確認し、必要ならALTER EXTENSION ... UPDATEを検討します。更新経路がない場合は、拡張の置き換えや別の移行方法を検証し、未確認の変更をそのまま本番へ適用しないでください。