この記事でわかること

  • PostgreSQLのサポート期限の確かめ方
  • メジャーバージョンを上げる3つの方法の違い
  • 上げる前に確かめることと、pg_upgrade --checkでの検査
  • うまくいかなかったときの戻し方の決め方

自分でサーバーを運用していると、PostgreSQLの版が古くなり、サポートの期限が近づいてきます。ところが、メジャーバージョンを上げる作業は、マイナーバージョンの更新のように入れ替えるだけでは済みません。この記事では、上げる作業に入る前に決めておくことをまとめます。

もとにしたのは、PostgreSQLの公式の資料(Versioning Policy・アップグレードの章・pg_upgradeの説明)で、2026年10月29日に目を通しました。記事の中のコマンドは公式の資料に載っているもので、このサイトのサーバーで試したものではありません。

結論: 上げる前に「期限・方法・戻し方」の3つを決める

メジャーバージョンを上げる前に、いつまでに上げるか(期限)、どの方法で上げるか(方法)、失敗したときにどう戻すか(戻し方)の3つを決めます。 期限は公式のページの一覧で確かめ、方法はデータの大きさと止められる時間で選び、戻し方はバックアップと方法の組み合わせで決まります。

戻し方を決めないまま作業を始めると、途中で問題が出たときに、古い版へ戻れなくなることがあります。

メジャーバージョンとマイナーバージョンの違い

PostgreSQL 10からは、番号の最初の部分がメジャーバージョンです。16から17へ上げるのがメジャーバージョンの更新、16.4から16.5へ上げるのがマイナーバージョンの更新です。

マイナーバージョンを上げるときは、ダンプと復元は要りません。サーバーを止めて新しいプログラムに入れ替え、起動し直します。公式のページは、同じメジャーバージョンの最新のマイナーリリースを使うよう勧めています。

メジャーバージョンは違います。データのディレクトリの中身は、前の版との互換性が保たれません。そのため、ダンプと復元か、pg_upgradeのような専用の道具が必要になります。

サポート期限の確かめ方

公式のVersioning Policyのページによると、PostgreSQLはメジャーバージョンを最初のリリースから5年間支援します。その後、最後のマイナーバージョンが出て、支援が終わります。新しいメジャーバージョンは、およそ1年に1回出ます。

同じページの表に、版ごとの最初のリリースの日と、最後のリリースの日が載っています。2026年10月29日に見た表では、PostgreSQL 14は2026年11月12日が最後のリリースの日でした。日付は変わることがあるため、自分の版の行を公式のページで確かめます。

自分の版は、psqlで接続して確かめられます。

【用途】サーバーの版を確かめる ／【実行場所】psql(DBに接続した状態) ／【状態変更】なし(読み取りだけ)

SELECT version();

表示された文字列の最初にある「PostgreSQL」の後の数字が、いま動いている版です。

上げる方法は3つ

公式のアップグレードの章では、メジャーバージョンを上げる方法として3つを挙げています。

方法 止まる時間 向く場面
ダンプと復元 長くなりやすい 量が少ない
pg_upgrade 短い 量が多い
レプリケーション 数秒 止められない

ダンプと復元

昔からある方法はダンプと復元で、時間がかかることがあります。古い版からpg_dumpallでデータを書き出し、新しい版に読み込ませます。この方法では、pg_dumpallのような論理バックアップの道具を使う必要があり、ファイルをそのまま写すバックアップでは移せません。

公式の資料は、新しい版のpg_dumpとpg_dumpallを使うよう勧めています。今の版のダンプの道具は、9.2以降のサーバーから読み出せます。

【用途】すべてのDBを1つのファイルに書き出す ／【実行場所】DBのサーバー(PostgreSQLの管理用のユーザー) ／【状態変更】あり(ダンプのファイルを作る)

pg_dumpall > outputfile

書き出している間にデータが変わると、その変更はダンプに入りません。作業の間は、アプリからの書き込みを止めておきます。

pg_upgrade

pg_upgradeは、データのファイルを使い回して、新しい版の仕組みに合わせる道具です。公式の資料では、--linkの方式なら数分で終わることがあると説明しています。9.2以降から最新のメジャーバージョンへ上げられます。

実行するときは、新しい版のpg_upgradeを実行します。古い版で使っていた拡張機能がある場合は、拡張機能のファイルを、新しい版に合わせて入れておく必要があります。

論理レプリケーション

新しい版のサーバーを別に用意し、論理レプリケーションでデータを写し続けてから切り替える方法です。公式の資料では、切り替えで止まる時間は数秒だと説明しています。その代わり、2つのサーバーを並べて動かす準備が要ります。

どの方法にするかの判断

止める時間を長く取れて、データの量が少ないなら、ダンプと復元が分かりやすい方法です。止める時間を短くしたいならpg_upgrade、ほとんど止められないならレプリケーションを考えます。個人で運用している小さなサーバーなら、作業の時間を決めてアプリを止め、ダンプと復元かpg_upgradeで上げる形が多くなります。

上げる前に確かめること

リリースノートを読む

メジャーバージョンでは、使い方の変わる点が入ることがあります。公式の資料は、リリースノートの「Migration」の節を特に読むよう勧めています。間の版を飛ばして上げられますが、間のすべてのメジャーバージョンのリリースノートを読むよう勧めています。

アプリを新しい版で試す

公式の資料では、慎重に進めるなら、切り替える前に、アプリを新しい版で試すよう書いています。古い版と新しい版を並べて入れておき、アプリの動きを新しい版で確かめてから切り替えます。

pg_upgrade --checkで検査する

pg_upgradeには、検査だけを行う--checkという指定があります。古いサーバーを動かしたままでも実行でき、上げた後に手で直す点も教えてくれます。新しい版を入れ、新しいクラスタを作ってから実行します。

【用途】上げられるかを検査する ／【実行場所】DBのサーバー(PostgreSQLの管理用のユーザー) ／【状態変更】なし(検査だけ。古いクラスタは変えない)

pg_upgrade -b <古い版のbinのディレクトリ> -B <新しい版のbinのディレクトリ> -d <古い版のデータのディレクトリ> -D <新しい版のデータのディレクトリ> --check

--linkの方式で上げる予定なら、検査のときも--linkを付けて、その方式に固有の検査も行います。

戻し方を先に決める

pg_upgradeを使った後に古い版へ戻せるかは、使った方式で変わります。

  • --checkだけなら、古いクラスタは変わりません。そのまま起動できます
  • 既定のコピーの方式なら、古いクラスタはそのままで、起動し直せます
  • --linkの方式では、新しいクラスタを起動した後は、古いクラスタを使うのは安全ではなく、バックアップから戻す必要があります

ダンプと復元の方法では、古い版のディレクトリを消さずに名前を変えておくと、問題が起きたときに戻りやすくなります。

どの方法でも、上げる前にバックアップを取り、取れたことを確かめておきます。このサイトでも、DBを変える作業の前には必ずバックアップを取り、取れたことを確かめてから進めています。設定ファイルを変えるときも、変える前の控えを取ってから置き換えています。バックアップの取り方と復元の確かめ方は、サーバーのバックアップと復元確認で紹介しています。

作業の前のチェックリスト

  • [ ] 自分の版と、支援の終わる日を公式のページで確かめた
  • [ ] 上げる先の版と、間の版のリリースノートの「Migration」の節を読んだ
  • [ ] 方法(ダンプと復元・pg_upgrade・レプリケーション)を、データの量と止められる時間で決めた
  • [ ] バックアップを取り、取れたことを確かめた
  • [ ] pg_upgradeを使うなら、--checkで検査した
  • [ ] 失敗したときの戻し方を、使う方式に合わせて決めた
  • [ ] アプリを新しい版で動かして確かめた

つまずきやすいところ

  • 古い版のpg_upgradeを実行する: pg_upgradeは、新しい版のものを使います
  • ファイルを写すだけで移そうとする: メジャーバージョンが違うと、データのディレクトリをそのまま使えません
  • --linkの後に戻ろうとする: 新しいクラスタを起動した後は、バックアップから戻すしかありません
  • 拡張機能を入れ忘れる: 古い版で使っていた拡張機能のファイルは、新しい版にも入れておきます
  • 統計情報を作り直さない: 上げた後には、最後に統計情報を作り直すコマンドの案内が出ます。終わったら案内に沿って実行します

PostgreSQLを入れてアプリ用のユーザーとDBを作る手順は、AlmaLinuxでPostgreSQLを構築しアプリ用のユーザーとDBを作る手順で、サーバーの作業をClaude Codeと進める流れは、Claude CodeでAlmaLinuxサーバーを構築・運用する方法で紹介しています。

まとめ

  • メジャーバージョンを上げる前に、期限・方法・戻し方の3つを決めます
  • 支援の期間は最初のリリースから5年で、終わる日は公式のページの表で確かめます
  • 方法はダンプと復元・pg_upgrade・論理レプリケーションの3つで、データの量と止められる時間で選びます
  • 間の版のリリースノートを読み、pg_upgrade --checkで検査してから上げます
  • --linkの方式では古いクラスタに戻れなくなるため、上げる前のバックアップが欠かせません