PostgreSQLのバージョン確認方法｜サーバ・クライアント別コマンドとEOL判定・更新計画

バージョン確認でつまずく原因は、コマンドを知らないことではありません。返ってきた数字が「どこの版」なのかを取り違えるところにあります。手元のpsqlが18でも、繋いだ先のサーバが14ということは普通に起きますし、マネージドサービスではエンジンの版とサービス側の版が別々に振られています。この記事では確認対象をサーバ・クライアント・ライブラリ・拡張・OSパッケージの5層へ分け、それぞれに割り当てるコマンドを整理したうえで、読み取った版から残りのサポート期間を出し、更新の手順を選ぶところまでを扱いました。導入そのものの手順はPostgreSQLのインストール手順、製品としての位置づけはデータベースとは？種類・DBMS・RDBとNoSQLの選び方を先に押さえてください。

まとめ：版の確認で最初に押さえる4点

• 返る値の意味が違う。SELECT version()はサーバ、psql -Vはクライアント。両者は一致しなくても異常ではありません。
• 条件分岐にはserver_version_numを使う。18.6は180006という6桁の整数で返り、文字列比較の事故を避けられます。
• サポート期限はコミュニティとクラウドで別に動く。14系のコミュニティ最終リリースは2026年11月12日、RDSの標準サポート終了は2027年2月28日です。
• 更新方式は残り期間で決まる。半年を切っているならダンプ復元ではなくpg_upgradeか論理レプリケーションを前提に組みます。

サーバ側で動いている版を確かめる3つのSQLと使い分けの判断軸

SELECT version()とSHOW server_versionで返る値の違い

まず押さえるのはこの2つです。SELECT version()はビルド情報を含む1行の文字列を返し、SHOW server_versionは版だけを短く返します。人が目視するなら前者、機械で読むなら後者という住み分けになります。

SELECT version();
SHOW server_version;
SHOW server_version_num;

1行目が返すのは「PostgreSQL 18.6 on x86_64-pc-linux-gnu, compiled by gcc」に続くビルド情報つきの文字列で、CPUアーキテクチャとコンパイラまで含みます。移植や拡張のビルドで詰まったときに効いてくるのはこちらの情報です。2行目は18.6だけを返します。

psqlの対話画面を開かずに済ませたい場面もあります。シェルから1回だけ読むなら、接続文字列と-cを組み合わせるのが手早い書き方です。監視スクリプトへ埋め込むときは-tと-Aを足して余計な装飾を落としてください。

psql -h db.example.internal -U appuser -d appdb -tAc "SHOW server_version_num;"

server_version_numの6桁表現と条件分岐で使うときの注意

スクリプトで版を判定するならserver_version_numが正解です。18.6なら180006、17.11なら170011という整数で返ります。メジャー版を1万倍し、マイナー版を下4桁へ収める作りだと考えてください。

ここに落とし穴があります。PostgreSQL 10より前は「9.6」の2つでメジャー版を表していたため、9.6.24は90624になりました。メジャー部分が2桁、マイナー部分が2桁ずつという別の詰め方です。10以降だけを相手にするなら気にせず済みますが、9系が残る環境を含めて判定するコードでは境界を明示しておくほうが安全でしょう。

SELECT current_setting('server_version_num')::int as num;

文字列で比較すると「9.6」が「18.6」より大きいと判定される事故が起きます。整数へ寄せておけば、この種の並び順の崩れは起きません。SQLの外で判定するなら、接続直後にこの値を1回だけ取得して保持する作りにしてください。

マネージドではaurora_versionのような別関数も併せて見る

Amazon Aurora PostgreSQLでは版が2階建てになっています。エンジンの版はSELECT version()で読めますが、Aurora自身の版は別関数です。AWSのドキュメントは、Auroraのリリースがデータベースエンジンの版番号とAuroraの版番号という2つの版番号を持つのが通例だと説明しています。

SELECT aurora_version();

13.3や12.8以降ではエンジン版に寄せた13.3.1のような値が返りますが、それより前の世代では2.7.3のようにまったく別の体系でした。障害調査でAWSサポートへ問い合わせるときはこの値まで揃えて出すと往復が減ります。サーバーレス構成での版の見え方についてはNeonとは？サーバーレスPostgresの構成・料金と採用判断も併読すると比較の軸が増えるはずです。

クライアントとライブラリの版がサーバの版とずれる場面の見分け方

psql -Vが返すのはクライアント側の版だという前提を押さえる

もっとも多い誤解がここです。psql -Vはドキュメントの記述どおり「psqlの版を表示して終了する」だけで、接続先には一切触れません。DBサーバへ入らずローカルの端末で叩いた結果を、サーバの版だと思い込む取り違えが起きます。

psql -V
pg_config --version

公式ドキュメントは、psqlは同じか古いメジャー版のサーバとの組み合わせでもっともよく動くと述べています。サーバのほうがpsqlより新しい場合はバックスラッシュコマンドが失敗しやすく、テーブル定義を表示する系統は7.4まで遡って動く一方、psqlより新しいサーバでは保証されないという書き方です。複数の版のサーバへ繋ぐ端末では、いちばん新しいpsqlを1本置くか、版ごとのpsqlを揃えて使い分けるかのどちらかを選んでください。

接続ライブラリとドライバの版は接続情報から取り出して突き合わせる

アプリケーションから見た版は、psqlともサーバとも別の経路で決まります。C言語のlibpqならPQserverVersion()が接続先の版を、PQlibVersion()がライブラリ自身の版を返す仕様です。この2つが揃って初めて、機能が使えない原因がサーバ側なのかクライアント側なのかを切り分けられます。

Pythonのpsycopgは接続オブジェクトの属性として同じ値を持ちます。ドライバの版はパッケージ側の属性から読めるので、両方を起動ログへ吐いておくと調査が早くなるでしょう。ドライバまわりの詳細はPsycopg3の概要と主要な特徴で扱いました。

python -c "import psycopg; c=psycopg.connect(); print(psycopg.__version__, c.info.server_version)"

拡張の版はpg_extensionと利用できる版の差分で判断する

本体を上げても拡張が古いままという状態は珍しくありません。導入済みの版と、そのサーバで利用できる版は別に管理されているためです。両方を突き合わせて初めて、更新の余地があるかどうかが分かります。

SELECT extname, extversion FROM pg_extension;
SELECT name, default_version, installed_version FROM pg_available_extensions
 WHERE installed_version IS NOT NULL;

default_versionとinstalled_versionがずれていれば、拡張の更新文で追随できます。ベクトル検索のように更新の頻度が高い拡張ほど差が開きやすく、機能が見当たらない原因が本体ではなく拡張の版だったという例は珍しくありません。この領域はpgvectorの基本概要とベクトル検索の側も合わせて見ておくと判断が早まります。

OSに同居する複数クラスタの版とポートを取り違えない確かめ方

Ubuntuはpg_lsclustersでクラスタごとの版を一覧する

Debian系のパッケージで入れた環境では、同じホストに複数のメジャー版が並びます。17系が動いているホストへ18系を足すと、18系は空いている次のポートへ回ります。接続先を5432で固定したままなら、古いほうへ繋ぎ続けることになるでしょう。版だけを見ても足りず、ポートと対で確認してください。

pg_lsclusters
sudo -u postgres psql --cluster 18/main -c "SHOW server_version;"

出力には版、クラスタ名、ポート、状態、データ領域の位置が並びます。--clusterを付ければ、どのクラスタへ問い合わせたかが明示されるので、報告書へ貼っても解釈がぶれません。設定ファイルの置き場や自動生成されるクラスタの扱いはPostgreSQLのインストール手順の側で詳しく扱っています。

Windowsはbin配下の実行ファイルへversionを渡して読む

Windowsではサービスとして常駐しているため、コマンドラインから版を読むには実行ファイルの位置を指定します。複数版を入れている場合はディレクトリ名がそのまま版を表すので、まずそこを見るのが早い判断です。

"C:\Program Files\PostgreSQL\18\bin\postgres.exe" --version
"C:\Program Files\PostgreSQL\18\bin\psql.exe" -U postgres -tAc "SHOW server_version;"

1行目はサービスとして動いていない版でも読めてしまう点に注意してください。実際に走っているプロセスの版を知りたいなら、2行目のようにポートを指定して接続した結果で判断します。サービス一覧に複数の登録が残っているホストでは、止まっている版のバイナリを読んで安心してしまう取り違えが起きがちです。

5年サポートポリシーから自分の版の残りサポート期間を判定する

対応中の5系統と最終リリース日を確認した日付つきで押さえておく

コミュニティの方針は明快です。公式のバージョニングポリシーは、メジャー版を初回リリースから5年間サポートし、その後は最後のマイナー版を出して以降はサポート対象外になると定めています。マイナー版はバグ修正と必要に応じたセキュリティ修正を含み、少なくとも3か月に1度リリースされるという書き方です。

2026年8月25日時点で対応中とされていたのは次の5系統でした。判定に使うのは最終リリース日の列です。

13系は2025年11月13日で終わっています。読み取った版が13以下だったなら、残り期間の計算ではなく更新計画の着手が先です。14系も残りは3か月を切っており、年内に動かす前提で予算と停止時間を押さえる段階へ入りました。

クラウドの標準サポート終了日はコミュニティのEOLと別に動く

ここが実務でいちばん誤解される箇所です。Amazon RDS for PostgreSQLのメジャー版は、対応するコミュニティ版のEOLまでは標準サポートの下で使えるという建て付けで、実際の終了日はコミュニティのEOLより後ろへずれます。14系ならコミュニティは2026年11月12日、RDSの標準サポート終了は2027年2月28日でした。

終了日を過ぎても、有償のExtended Supportを使えば動かし続けられます。ただし費用が乗るうえ、AWS側が出す修正版へ追随する作業は残ります。猶予を買う仕組みであって、更新を回避する仕組みではないと理解しておいてください。

メジャー版より先にマイナー版の期限が来る二段構造を見落とさない

もうひとつ、メジャー版の期限だけを見ていると外す論点があります。RDSのドキュメントは、マイナー版が対応するメジャー版よりも先に標準サポートを終える場合があると明記しました。挙げられている例では、マイナー版14.9が2025年3月に終了する一方、メジャー版14の終了は2027年2月です。

つまり「メジャー版はまだ大丈夫」と判断しても、走っているマイナー版が先に切れて自動更新の対象になることがあります。RDSがコミュニティのリリースへ追随する速度も明示されており、マイナー版は7日以内、メジャー版は新しいメジャー版の最初のマイナー版から30日以内という基準です。棚卸しでは、メジャー版とマイナー版の2つを別の列として持ってください。

版が古いまま放置されたときの実害は、機能の欠落よりも修正の受け取り漏れとして出ます。PL/Perlを通じた任意コード実行に至るPostgreSQLの脆弱性CVE-2024-10979のように、影響範囲が版で決まる事例では、確認結果がそのまま対応要否の判断材料になります。

確認結果を更新計画へ落とすときの分岐と3つの更新方式の選び方

マイナー更新がバイナリの入れ替えと再起動だけで完了する仕組み

読み取った版が対応中の系統で、マイナー版だけが古いという状態なら話は単純です。同一メジャー版のマイナー更新はデータ形式が変わらないため、パッケージを入れ替えて再起動すれば終わります。ダンプも取り直しも要りません。

それでも本番へ当てる前に検証環境で同じ手順を通してください。拡張が同梱バイナリを持つ場合、本体だけを入れ替えると読み込みに失敗することがあります。停止を伴う入れ替え全般の考え方はインプレースアップグレードとは？仕組みと採用の判断で整理しました。

メジャー更新はpg_upgradeとダンプ復元のどちらを選ぶか

メジャー版をまたぐ場合はデータファイルの構造が変わるため、道具が要ります。公式のpg_upgradeは、通常なら必要になるダンプと復元を経ずに新しいメジャー版へ上げられる道具で、9.2.X以降から現行のメジャー版まで対応すると書かれています。

pg_upgrade --check -b /usr/lib/postgresql/16/bin -B /usr/lib/postgresql/18/bin -d /var/lib/postgresql/16/main -D /var/lib/postgresql/18/main

ドキュメントが強調しているのは、常に新しいサーバ側のpg_upgradeを実行し、古いほうを使ってはならないという点です。--checkを付ければデータを変えずに検査だけを走らせられるので、停止時間を取る前に何度でも回せます。

速度を詰める選択肢も増えました。--linkはファイルをコピーせずハードリンクで済ませる方式で、旧クラスタと新クラスタが同じファイルシステム上にあることが条件です。18系で加わった--swapはデータディレクトリごと移し替える方式で、リレーション数が多いクラスタではもっとも速くなり得ると説明されています。ただし旧クラスタ側に多数の不要ファイルを残すため、同期方式はfsyncを勧めるという注記が付きました。

18系ではもうひとつ、更新後の性能低下を抑える変更が入っています。pg_upgradeがオプティマイザの統計情報を引き継ぐようになり、切り替え直後から実行計画が安定しやすくなりました。ただし拡張統計は引き継がれないため、そこを使っている環境では従来どおり収集し直す作業を段取りへ残してください。

論理レプリケーションで停止時間を詰めるときに付いてくる版の条件

停止時間を分単位まで詰めたい場合は、新しい版のクラスタを別に立てて論理レプリケーションで追いつかせ、切り替える方式を採ります。ただしこの方式には、あまり知られていない版の条件が付きます。

17系のリリースノートは、pg_upgradeがパブリッシャ側の論理レプリケーションスロットとサブスクライバ側のサブスクリプション状態を引き継ぐようになったと述べたうえで、これが機能するのは旧クラスタが17以降の場合に限ると明記しました。16以前から上げるときはスロットが残らないため、切り替えのたびに初期同期をやり直す前提で計画する必要があります。

加えて、論理レプリケーションはシーケンスの現在値や一部のDDLを運びません。切替の直前にシーケンスを進める手順、外部キーと索引の作成順、切り戻しの経路を手順書へ書き切っておいてください。物理レプリケーションで待機系を持つ構成との比較はrepmgrとは？レプリケーション管理と自動フェイルオーバーの側が参考になります。

版の確認を四半期の定例へ組み込んで棚卸しの仕組みへ落とす進め方

四半期ごとに版とEOLを収集して一覧へ残す運用の型と記録項目

確認は1回で終わる作業ではありません。コミュニティのマイナー版が少なくとも3か月に1度出る以上、棚卸しの間隔も四半期に合わせるのが噛み合います。収集して残すのはホスト名、メジャー版、マイナー版、コミュニティの最終リリース日、クラウド側の標準サポート終了日という5列です。

収集そのものは自動化できます。RDSならAWS CLIで版と終了日を機械的に引けますし、自前構築なら監視エージェントからserver_version_numを1つの指標として送るだけで足ります。人手を残すのは判断の部分だけにしてください。

aws rds describe-db-instances --query "DBInstances[].[DBInstanceIdentifier,EngineVersion]" --output text

一覧が揃うと、更新の順番が数字で決まります。残り期間が短い順、影響範囲が小さい順に並べれば、どこから検証環境を作るかで迷う時間がなくなるはずです。

同じ棚卸しの発想は、版だけでなくデータベース内のオブジェクトにも当てはまります。どの表がどれだけの容量を持つかを機械的に集める手順はPostgreSQLのテーブル一覧を取得する方法で扱いました。

棚卸しと更新を自前で回すか保守運用へ委ねるかを分ける3つの条件

棚卸しと更新を内製で回してよいのは、次の3条件がそろうときです。第一に、検証環境を本番に近い構成で再現できること。第二に、停止時間を確保できる業務の時間帯があること。第三に、切り戻しの判断を下せる担当者が当日いること。

逆に、担当者が1人しかいない、検証環境が本番と別構成、夜間の作業要員を置けないという状態なら、外部の手を入れたほうが結果的に安く付きます。EOLを過ぎたまま動かし続けるコストは、延長サポートの費用と、修正が来なくなった後の障害対応の両方で効いてくるためです。判断がつかない段階なら、保守運用・内製化支援で棚卸しと更新計画の部分だけを切り出して依頼する進め方もあります。

費用の全体像から先に決めたい場合は、PostgreSQLのライセンスと価格：無償の範囲と実際に払う費用で5年総額の考え方を示しました。無償のソフトウェアであっても、版を維持する工数は必ず発生します。そこを見込まずに導入すると、EOLの直前で慌てることになります。

よくある質問

SELECT version()とpsql -Vの結果が違うのは異常ですか？

異常ではありません。前者は接続先サーバの版、後者は手元のクライアントの版で、別々に導入されている以上ずれるのが普通です。むしろ両方を確認していないと、サーバを上げたつもりで古いクライアントを使い続ける状態に気づけません。

SQLを実行せずにサーバの版を知る方法はありますか？

データ領域の直下にあるPG_VERSIONというファイルにメジャー版が書かれているため、停止中のクラスタでも読めます。Debian系ならpg_lsclustersの出力にも版が並びます。ただしマイナー版まではこれらでは分からないので、正確な値が要るなら接続して確認してください。

server_version_numを条件分岐に使うのはなぜ勧められますか？

整数で返るため大小比較が壊れないからです。文字列で比較すると9.6が18.6より大きいと判定される場合があります。18.6は180006、17.11は170011という形なので、機能の入った版を数値で書いておけば判定式が単純になります。

サポート期限を過ぎたPostgreSQLを使い続けるとどうなりますか？

動作そのものは止まりませんが、バグ修正とセキュリティ修正が届かなくなります。影響範囲が版で決まる脆弱性が出たとき、残る対応策は更新だけでしょう。クラウドでは有償の延長サポートで猶予を買えるものの、費用が乗るうえ更新作業自体は残ります。

メジャー更新はどれくらいの停止時間を見込むべきですか？

データ量と方式で桁が変わるため一律の数値は出せません。目安として、pg_upgradeの--linkや--swapならデータ量にほぼ依存せず数分から数十分、ダンプと復元なら容量に比例して数時間規模になります。停止時間を分単位へ詰めるなら論理レプリケーションでの切替を検討してください。

関連記事

• PostgreSQLのインストール手順｜Windows・Ubuntu別の導入と文字コード
• データベースとは？種類・DBMS・RDBとNoSQLの選び方を実装目線で解説
• PostgreSQLのライセンスと価格：無償の範囲と実際に払う費用
• インプレースアップグレードとは？仕組み・他方式との違いと判断
• Neonとは？サーバーレスPostgresの構成・料金と採用判断