こんにちは、インフラエンジニアのryuです。
みなさんの現場で動いているPostgreSQLは、何番のバージョンでしょうか？
2021年9月に出たPostgreSQL 14は、2026年11月12日に最後のマイナーリリースが出て、コミュニティのサポートが終わる予定です。あと1か月ほどしかありません。
サポートが終わっても、データベースが急に止まるわけではありません。ただ、そのあとに見つかった脆弱性やデータ破損につながる不具合には、修正が出なくなります。
この記事では、14のサポート終了で何が変わるのかと、17や18へ上げるときに引っかかりやすい変更点、そして pg_upgrade で事前に確認する方法を順番に見ていきます。
PostgreSQL 14のサポート終了で何が変わるの？¶
まずは、PostgreSQLのサポートの決まり方を確認しておきます。
PostgreSQLは、メジャーバージョンごとに最初のリリースから5年間サポートされます。5年がたつと最後のマイナーバージョンが出て、それ以降は修正が出なくなります。
PostgreSQLのバージョン管理ポリシーでは、メジャーバージョンは最初のリリースから5年間サポートされ、その後に最後のマイナーバージョンが出てサポートが終了する、と説明されています。
公式の一覧に載っている、いまサポート中のバージョンを表にまとめます。
| バージョン | 最初のリリース | サポート終了（最後のリリース） |
|---|---|---|
| 14 | 2021年9月30日 | 2026年11月12日 |
| 15 | 2022年10月13日 | 2027年11月11日 |
| 16 | 2023年9月14日 | 2028年11月9日 |
| 17 | 2024年9月26日 | 2029年11月8日 |
| 18 | 2025年9月25日 | 2030年11月14日 |
次の19は、2026年9月の時点でベータ版が出ている段階です。正式リリースは10月の予定とされていますが、本番で使うならリリース後の様子を見てからでも遅くはありません。
いま14から上げるなら、5年近くサポートが残る18か、少し実績の長い17が現実的な候補になります。
どちらを選ぶかは、使っている拡張機能やドライバーが対応しているかで決めるのが確実です。新しいほど長く使えますが、アプリ側の対応が追いついていないと、上げたあとに思わぬところで止まってしまいます。
なお、11月12日に出る予定の最後のマイナーリリースは、14を使い続ける間に当てられる最後の修正です。メジャーバージョンを上げるのが年明け以降になりそうなら、せめて最後のマイナーバージョンまでは上げておくのがおすすめです。
どこで動かしているかで期限が違う¶
PostgreSQLのサポート終了で注意したいのは、動かしている場所によって期限が変わることです。
自分でサーバーに入れているのか、OSのパッケージを使っているのか、クラウドのマネージドサービスを使っているのかで、考え方が分かれます。
| 動かしている場所 | 期限の考え方 |
|---|---|
| PostgreSQL公式のリポジトリやソースから入れた | コミュニティの期限（2026年11月12日）がそのまま期限になる |
OSのパッケージ（Ubuntu 22.04の postgresql-14 など） |
OS側が修正を出し続けるかどうかは、ディストリビューションの方針しだい |
| Amazon RDS / Aurora | 標準サポートは2027年2月28日まで。そのあとは有料の延長サポートになる |
OSのパッケージは、少しややこしい部分です。たとえばUbuntu 22.04には postgresql-14 のパッケージがあり、いまもマイナーバージョンの更新が届いています。
ただ、コミュニティの修正が止まったあとに、OS側がどこまで修正を続けるかはディストリビューションごとに違います。OSのサポートが残っているから安心、と決めつけずに、使っているディストリビューションの案内を確認しておきましょう。
Amazon RDSは延長サポートの料金に注意¶
Amazon RDSとAuroraのPostgreSQL 14は、コミュニティの期限より少し長く、2027年2月28日まで標準サポートが続きます。
そのあとは RDS延長サポート に自動で切り替わり、2027年3月1日から追加の料金がかかります。延長サポートは2030年2月28日まで使えますが、年数がたつと料金も上がる仕組みです。
まずは、自分のアカウントにどのバージョンのRDSがあるのかを一覧にしてみましょう。
# RDS for PostgreSQL のインスタンス名とエンジンのバージョンを一覧にする
aws rds describe-db-instances \
--query "DBInstances[?Engine=='postgres'].[DBInstanceIdentifier,EngineVersion]" \
--output table
マイナーバージョンにも注意が必要です。RDSでは、14の中でも古いマイナーバージョンが先に標準サポートを終えることがあります。メジャーバージョンだけでなく、マイナーバージョンまで確認しておくと安心です。
17や18に上げると何が変わるの？¶
14から17や18へ上げると、間にある15と16の変更もまとめて受けることになります。
ここでは、インフラエンジニアが運用の中で気づきやすい変更を3つ取り上げます。
publicスキーマにテーブルを作れなくなる¶
PostgreSQL 15から、public スキーマにだれでもテーブルを作れる、という初期設定がなくなりました。
14までは、データベースに接続できるユーザーなら、public スキーマに自由にテーブルを作れました。これはセキュリティ上よくないということで、15からはデータベースの所有者だけが作れるように変わっています。
ここで気をつけたいのは、この変更が新しく作ったデータベースにだけ効くという点です。
pg_upgradeで上げたり、ダンプから戻したりしたデータベースは、14までの権限がそのまま引き継がれます。
つまり、上げ方によって権限の状態が変わります。新しいクラスタに空のデータベースを作ってアプリをつなぐと、テーブルを作る処理で permission denied for schema public のエラーが出ることがあります。
逆に、pg_upgrade で上げた環境は、古い権限のまま残っています。新しい初期設定に合わせたいなら、上げたあとに自分で権限を外します。
-- public スキーマの権限をいまの状態で確認する
\dn+ public
-- 15以降の初期設定に合わせたい場合（アプリへの影響を確認してから実行）
REVOKE CREATE ON SCHEMA public FROM PUBLIC;
どちらに合わせるかは、アプリがどのユーザーでテーブルを作っているかしだいです。マイグレーションツールを使っている場合は、そのユーザーに必要な権限を付けておきましょう。
MD5のパスワードが非推奨になった¶
PostgreSQL 18では、MD5方式のパスワード認証が非推奨になりました。将来のバージョンで削除される予定です。
18では、MD5のパスワードを設定するときに警告が出るようになっています。開発中の19では、MD5で認証に成功したときにも警告を出す変更が入っています。
14の時代に作ったユーザーは、MD5のパスワードのままになっていることがあります。上げる前に、どの方式で保存されているかを確認しておきましょう。
-- 保存されているパスワードの方式を確認する（スーパーユーザーで実行）
SELECT rolname,
CASE WHEN rolpassword LIKE 'md5%' THEN 'md5'
WHEN rolpassword LIKE 'SCRAM-SHA-256%' THEN 'scram-sha-256'
ELSE 'なし' END AS method
FROM pg_authid
WHERE rolcanlogin;
MD5のユーザーが見つかったら、password_encryption が scram-sha-256 になっている状態でパスワードを設定し直します。あわせて、pg_hba.conf の認証方式も scram-sha-256 に変えておくとよいです。
古いドライバーを使っているアプリは、SCRAM認証に対応していないことがあります。パスワードを変える前に、アプリ側のドライバーのバージョンも確かめておきましょう。
18ではデータチェックサムが最初から有効になる¶
PostgreSQL 18では、initdb でクラスタを作ると、データチェックサムが最初から有効になります。データチェックサムは、ディスク上のデータが壊れていないかを確かめるための仕組みです。
これが pg_upgrade に影響します。pg_upgrade は、古いクラスタと新しいクラスタでチェックサムの設定がそろっていることを求めるからです。
14のクラスタをチェックサムなしで作っていた場合、18の新しいクラスタを初期設定のまま作ると、設定が合わずに上げられません。その場合は、新しいクラスタを --no-data-checksums を付けて作ります。
# 古いクラスタでデータチェックサムが有効かを確認する
psql -c "SHOW data_checksums;"
# off だった場合は、18の新しいクラスタもチェックサムなしで作る
/usr/lib/postgresql/18/bin/initdb -D /var/lib/postgresql/18/main --no-data-checksums
チェックサムを有効にしたいなら、上げたあとに pg_checksums で有効にする方法もあります。ただしサーバーを止めて実行する必要があるので、作業時間に余裕のあるときに行いましょう。
上げ方はどれを選べばいいの？¶
PostgreSQLのメジャーバージョンを上げる方法は、大きく3つあります。
データの量と、止めてよい時間の長さで選ぶのが基本です。
| 方法 | 向いているケース | 気をつけること |
|---|---|---|
pg_dump / pg_dumpall で出して戻す |
データが少なく、止める時間を取れる | データが多いと時間がかかる |
pg_upgrade |
同じサーバーで、短い停止時間で上げたい | 拡張機能やチェックサムの設定をそろえる必要がある |
| 論理レプリケーション | 止める時間をできるだけ短くしたい | 設定が複雑で、DDLは自動で同期されない |
ダンプで戻す方法を使う場合は、新しいバージョン側の pg_dump を使うことが公式ドキュメントで勧められています。古いバージョンの pg_dump で出したデータを戻すより、問題が起きにくいからです。
pg_upgradeは --check で事前に確かめる¶
pg_upgrade を使うなら、本番の前に必ず --check を付けて実行しておきましょう。
--check を付けると、データには手を付けずに、上げられるかどうかのチェックだけを行います。古いサーバーが動いたままでも実行できます。
# 14から18へ上げられるかを確認する（データは変更されない）
/usr/lib/postgresql/18/bin/pg_upgrade \
--old-datadir=/var/lib/postgresql/14/main \
--new-datadir=/var/lib/postgresql/18/main \
--old-bindir=/usr/lib/postgresql/14/bin \
--new-bindir=/usr/lib/postgresql/18/bin \
--check
本番で --link を使う予定なら、--check にも --link を付けて実行します。--link はデータファイルをコピーせずにハードリンクでつなぐので速いのですが、新しいクラスタを起動したあとは古いクラスタを使えなくなります。
切り戻しが必要になったときに備えて、--link を使う前には必ずバックアップを取っておきましょう。
拡張機能のバージョンもそろえる¶
pg_upgrade でよく止まるのが、拡張機能です。
古いクラスタで pg_stat_statements や PostGIS などを使っている場合、新しいバージョン用の拡張機能を先に入れておく必要があります。
-- 古いクラスタで使っている拡張機能の一覧
SELECT extname, extversion FROM pg_extension;
一覧に出てきた拡張機能が、移行先のバージョンに対応しているかを1つずつ確認しましょう。外部の拡張機能は、対応が遅れることもあります。
上げたあとは統計情報を集め直す¶
上げ終わってサーバーが起動しても、作業はまだ終わりではありません。
PostgreSQLは、テーブルの統計情報をもとにSQLの実行計画を決めています。統計情報が足りない状態だと、ふだんは速いSQLが急に遅くなることがあります。
18の pg_upgrade では多くの統計情報が引き継がれるようになりましたが、すべてではありません。上げたあとは、pg_upgrade の出力に表示される案内に従って、統計情報を集め直しておきましょう。
# 18の場合：まず足りない統計情報だけを手早く作り、そのあと全体を集め直す
vacuumdb --all --analyze-in-stages --missing-stats-only
vacuumdb --all --analyze-only
アプリの動作確認は、この作業が終わってから行うと、本番に近い速さで確かめられます。
新人インフラエンジニアが押さえておきたいこと¶
データベースのバージョンアップは、新人インフラエンジニアが一人で担当することは少ない作業です。それでも、流れを知っておくと、先輩の作業を手伝うときに役立ちます。
大事なのは、いきなり本番で上げないことです。まずは検証環境で上げて、アプリが動くかを確かめます。環境を分ける理由は『本番・検証・開発の3つの環境は、何のために分けているのか』で詳しく解説しています。
上げる前のバックアップも欠かせません。冗長化しているから大丈夫、と考えるのは危険です。この違いは『冗長化とバックアップの違い』にまとめています。
また、同じ時期にサポートが終わったMySQL 8.0の記事『MySQL 8.0のサポート終了と8.4 LTSで確かめること』も、移行の進め方の参考になると思います。RDSそのものの作り方は『AWS RDSの使い方』で紹介しています。
手元で18を動かして試してみる¶
いきなり検証環境を用意するのが難しければ、Dockerで手元に18を立てて、変更点を試してみるのもおすすめです。
# PostgreSQL 18 のコンテナを起動して、チェックサムとパスワード方式を確認する
docker run -d --name pg18 -e POSTGRES_PASSWORD=secret postgres:18
docker exec -it pg18 psql -U postgres -c "SHOW data_checksums;"
docker exec -it pg18 psql -U postgres -c "SHOW password_encryption;"
実際に public スキーマに一般ユーザーでテーブルを作ってみると、15からの権限の変更がよく分かります。
InfraAcademyでは、こうしたミドルウェアを動かす土台になるLinuxの操作を、順番に学べるようにしています。コマンド操作に自信がない方は、Linuxロードマップ から学ぶ順番を確認してみてください。クラウドでデータベースを扱うなら、AWSロードマップ もあわせてどうぞ。
まとめ¶
PostgreSQL 14のサポート終了について、今回のポイントを振り返ります。
- コミュニティのサポートは2026年11月12日まで。そのあとは修正が出ない
- Amazon RDSとAuroraは2027年2月28日まで。そのあとは有料の延長サポートになる
- 15から、新しいデータベースでは
publicスキーマに一般ユーザーがテーブルを作れない - 18では、MD5パスワードが非推奨になり、データチェックサムが最初から有効になる
pg_upgradeは、本番の前に--checkで確認する
まだ14を使っているなら、まずはバージョンの棚卸しから始めてみてください。どこに14が残っているかが分かれば、上げる順番も決めやすくなります。
参考¶
- PostgreSQL: Versioning Policy（PostgreSQL公式）
- PostgreSQL 15 Released!（PostgreSQL公式）
- PostgreSQL 15.0 Release Notes（PostgreSQL公式）
- PostgreSQL 18 Released!（PostgreSQL公式）
- PostgreSQL 18.0 Release Notes（PostgreSQL公式）
- pg_upgrade（PostgreSQL 18 ドキュメント）
- Upgrading a PostgreSQL Cluster（PostgreSQL 18 ドキュメント）
- Release calendars for Amazon RDS for PostgreSQL（AWS）
- Viewing support dates for engine versions in Amazon RDS Extended Support（AWS）
- postgresql-14 パッケージ（Ubuntu jammy-updates）
