---
title: "PostgreSQLのバージョン確認方法｜サーバ・クライアント別コマンドとEOL判定・更新計画"
url: "https://www.issoh.co.jp/tech/details/16965/"
published: 2026-08-25
updated: 2026-08-25
categories: ["データベース"]
publisher: "株式会社一創"
---

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

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

## まとめ：版の確認で最初に押さえる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の構成・料金と採用判断](https://www.issoh.co.jp/tech/details/16444/)も併読すると比較の軸が増えるはずです。

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

### 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の概要と主要な特徴](https://www.issoh.co.jp/tech/details/8225/)で扱いました。

```
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の基本概要とベクトル検索](https://www.issoh.co.jp/tech/details/6231/)の側も合わせて見ておくと判断が早まります。

| 確認したい対象   | 使うコマンド                    |
| --------- | ------------------------- |
| サーバ本体     | SELECT version()          |
| 機械判定用の版番号 | SHOW server\_version\_num |
| Aurora側の版 | SELECT aurora\_version()  |
| 手元のクライアント | psql -V                   |
| 導入済みの拡張   | pg\_extension を参照         |

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

### Ubuntuはpg\_lsclustersでクラスタごとの版を一覧する

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

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

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

### 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系統でした。判定に使うのは最終リリース日の列です。

| 版  | 対応中のマイナー | 最終リリース日     |
| -- | -------- | ----------- |
| 18 | 18.6     | 2030年11月14日 |
| 17 | 17.11    | 2029年11月8日  |
| 16 | 16.15    | 2028年11月9日  |
| 15 | 15.19    | 2027年11月11日 |
| 14 | 14.24    | 2026年11月12日 |

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

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

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

| 版  | コミュニティEOL   | RDS標準サポート終了 |
| -- | ----------- | ----------- |
| 18 | 2030年11月    | 2031年2月28日  |
| 17 | 2029年11月    | 2030年2月28日  |
| 16 | 2028年11月    | 2029年2月28日  |
| 15 | 2027年11月    | 2028年2月29日  |
| 14 | 2026年11月12日 | 2027年2月28日  |

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

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

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

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

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

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

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

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

| 更新の種類      | 必要な作業           |
| ---------- | --------------- |
| マイナー更新     | 入れ替えと再起動のみ      |
| メジャー更新     | pg\_upgrade か復元 |
| 停止時間を詰める場合 | 論理レプリケーション      |

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

### メジャー更新は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とは？レプリケーション管理と自動フェイルオーバー](https://www.issoh.co.jp/tech/details/3756/)の側が参考になります。

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

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

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

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

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

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

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

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

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

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

費用の全体像から先に決めたい場合は、[PostgreSQLのライセンスと価格：無償の範囲と実際に払う費用](https://www.issoh.co.jp/column/details/16916/)で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別の導入と文字コード](https://www.issoh.co.jp/tech/details/16963/)
- [データベースとは？種類・DBMS・RDBとNoSQLの選び方を実装目線で解説](https://www.issoh.co.jp/tech/details/13012/)
- [PostgreSQLのライセンスと価格：無償の範囲と実際に払う費用](https://www.issoh.co.jp/column/details/16916/)
- [インプレースアップグレードとは？仕組み・他方式との違いと判断](https://www.issoh.co.jp/tech/details/14688/)
- [Neonとは？サーバーレスPostgresの構成・料金と採用判断](https://www.issoh.co.jp/tech/details/16444/)

---

出典: [PostgreSQLのバージョン確認方法｜サーバ・クライアント別コマンドとEOL判定・更新計画](<https://www.issoh.co.jp/tech/details/16965/>)（株式会社一創）