--- title: "PostgreSQL 19の新機能｜Beta 4時点の確定機能と差し戻し・18からの移行で壊れる箇所" url: "https://www.issoh.co.jp/tech/details/18247/" published: 2026-10-11 updated: 2026-10-11 categories: ["データベース"] publisher: "株式会社一創" --- # PostgreSQL 19の新機能｜Beta 4時点の確定機能と差し戻し・18からの移行で壊れる箇所 PostgreSQL 19は、2026年10月11日の時点でまだ正式版ではありません。最新は9月24日公開のBeta 4で、この版で**SQL/PGQ（グラフ問い合わせ）を含む5つの機能が取り下げられました**。Beta 1の頃の紹介記事を頼りに検証を始めると、試そうとした機能がそもそも入っていない事態が起こります。この記事では、Beta 4時点の[公式リリースノート](https://www.postgresql.org/docs/19/release-19.html)を正として、残った新機能をDockerで動かすSQL、18から上げるときに壊れる設定と挙動、そして19を待つべきか18へ先に上げるべきかの判断までを実装者向けにまとめました。製品としての位置づけは[データベースとは？種類・DBMS・RDBとNoSQLの選び方](https://www.issoh.co.jp/tech/details/13012/)で先に押さえておくと読みやすくなります。 ## まとめ：PostgreSQL 19で押さえる確定機能と移行前の確認4点 - 19はBeta 4（2026年9月24日）が最新。RCは10月上旬、GAは10月の見込みとされ、リリースノートの日付欄はまだ「2026-??-??」です。 - 残った目玉は`REPACK`（`VACUUM FULL`と`CLUSTER`の統合とオンライン化）、`WAIT FOR LSN`、論理レプリケーションのシーケンス複製、autovacuumの並列化の4つです。 - JITの既定無効化、`max_locks_per_transaction`の既定値倍増、RADIUS認証の削除など、18の設定をそのまま持ち込むと挙動が変わる項目が17件あります。 - 14系のサポートは2026年11月12日で終わります。14を使っているなら19を待たず、18へ上げる計画を先に立ててください。 ## PostgreSQL 19のリリース状況とBeta 4で差し戻された5つの機能 ### Beta 4が最新でRCは10月上旬予定・GAは10月の見込みという現在地 19の開発版は2026年6月のBeta 1から始まり、8月13日に18.6などの定例マイナー版と同時に[Beta 3](https://www.postgresql.org/about/news/postgresql-186-1711-1615-1519-1424-and-19-beta-3-released-3365/)、9月24日に[Beta 4](https://www.postgresql.org/about/news/postgresql-19-beta-4-released-3386/)が出ました。Beta 4の告知は次をRC（リリース候補）とし、時期を「early October」、GAも「may also occur in October」と書いています。 ただし10月11日時点で、postgresql.orgのニュース一覧にRC1の告知はまだ出ていません。[ロードマップ](https://www.postgresql.org/developer/roadmap/)も「planned for October 2026」と月までしか示していないため、GA日は未確定として扱うのが正確です。Beta同士の更新でも告知は`pg_upgrade`かダンプとリストアを求めており、検証用クラスタはBetaが上がるたびに作り直す前提で組んでください。 ### SQL/PGQやFOR PORTION OFなどBeta 4で取り下げられた機能一覧 Beta 4の告知で「Revert」と明記された機能は次のとおりです。いずれも19の正式版には入らない前提で読んでください。 | 取り下げられた機能 | Beta 1〜3での位置づけ | 19での扱い | | -------------------------- | ------------------- | ------ | | SQL/PGQ（グラフ問い合わせ） | AWSのBeta 2告知でも目玉の1つ | 削除 | | データチェックサムのオンライン有効化と無効化 | 停止なしで切替できる機能 | 削除 | | `FOR PORTION OF`で期間指定更新・削除 | 時制データ向けのSQL標準機能 | 削除 | | パーティションの統合・分割SQL | パーティションの統合と分割 | 削除 | | DDLを出力する3つの関数 | ロールやDBの定義をSQLで取得 | 削除 | 表のSQL/PGQは、プロパティグラフを問い合わせる機能です。統合・分割SQLは`ALTER TABLE ... MERGE PARTITIONS`と`SPLIT PARTITIONS`、DDL出力関数は`pg_get_role_ddl()`などを指します。 影響が大きいのはSQL/PGQです。2026年7月16日の[RDSデータベースプレビュー環境のBeta 2告知](https://aws.amazon.com/jp/about-aws/whats-new/2026/07/postgresql-19-beta-2-amazon-rds-database-preview-environment/)は、新機能の筆頭近くにSQL/PGQを挙げていました。この告知や同時期の解説を根拠に19でグラフ問い合わせを使う設計を進めていたなら、20以降まで待つか、拡張や別製品で代替する方向へ切り替える必要があります。 ## REPACKとWAIT FOR LSNで変わる保守運用をSQLで試す手順 ### Docker公式イメージ19beta4で検証環境を立ち上げる手順 手元で試すなら、[Docker公式のpostgresイメージ](https://hub.docker.com/%5F/postgres)に`19beta4`タグが出ています（2026年10月7日更新）。既存の18と衝突しないよう、ホスト側のポートをずらして起動します。 ``` docker run --name pg19 -e POSTGRES_PASSWORD=devpass -p 5433:5432 -d postgres:19beta4 docker exec -it pg19 psql -U postgres -c "SELECT version();" docker exec -it pg19 psql -U postgres -c "SHOW jit;" ``` 2行目で「PostgreSQL 19beta4」を含む文字列が返れば起動は完了です。3行目は`off`を返すはずで、18の既定（`on`）との違いがここで1つ確認できます。永続化やcomposeでの組み方は[Docker PostgreSQL構築の手順](https://www.issoh.co.jp/tech/details/16976/)と同じ考え方で足ります。Betaのデータ領域は次の版で読めなくなる可能性があるので、使い捨ての前提にしてください。 ### REPACK CONCURRENTLYでVACUUM FULLのロックを避ける条件 19の最大の変更は[REPACK](https://www.postgresql.org/docs/19/sql-repack.html)です。`VACUUM FULL`と`CLUSTER`の機能を1つのコマンドへまとめ、`CONCURRENTLY`を付けると、再構築中もテーブルの読み書きを止めません。排他ロックを取るのは最後のファイル差し替えの瞬間だけで、再構築中の変更は論理デコーディングで拾って反映します。 ``` -- 主キーを持つテーブルを、読み書きを止めずに再編成する REPACK (CONCURRENTLY, VERBOSE) orders; -- 別セッションから進捗を確認する SELECT * FROM pg_stat_progress_repack; -- 索引順に並べ直す（従来のCLUSTER相当）。CONCURRENTLYなしは排他ロック REPACK orders USING INDEX orders_created_at_idx; ``` 便利な反面、`CONCURRENTLY`が使えない条件がはっきり決まっています。主キーも索引ベースのレプリカ識別も無いテーブル、`UNLOGGED`テーブル、パーティション親テーブル、トランザクションブロック内での実行は対象外です。さらにレプリケーションスロットを1本消費するため、`max_repack_replication_slots`に空きが要ります。ディスクはテーブルと索引の合計以上の空きが必要で、ここは`VACUUM FULL`と変わりません。 公式ドキュメントは`CONCURRENTLY`付きの実行を「not MVCC-safe」と注記しています。再構築の前から開いている長いトランザクションが、処理後のテーブルを空に見る可能性があるという意味です。夜間バッチや分析クエリが動く時間帯は避けてください。肥大の原因切り分けとautovacuumの調整が先で、`REPACK`は最後の手段という位置づけは[PostgreSQLのVACUUM運用](https://www.issoh.co.jp/tech/details/16982/)で整理した考え方のままです。 ### WAIT FOR LSNでスタンバイ読み取りの書き込み直後ずれを防ぐ 読み取りをスタンバイへ逃がす構成では、更新した直後の画面で古い値が見えるという不具合が付きものでした。19の[WAIT FOR LSN](https://www.postgresql.org/docs/19/sql-wait.html)は、指定したWAL位置までスタンバイが再生し終えるのをSQLで待てるコマンドです。 ``` -- プライマリ：更新した直後のWAL位置を取得し、アプリ側で保持する UPDATE orders SET status = 'paid' WHERE id = 42; SELECT pg_current_wal_insert_lsn(); -- 例: 0/0306EE20 -- スタンバイ：その位置まで再生されるのを最大500ミリ秒だけ待つ WAIT FOR LSN '0/0306EE20' WITH (TIMEOUT '500ms', NO_THROW); -- statusがsuccessならスタンバイで読む。timeoutならプライマリで読み直す ``` モードは既定の`standby_replay`のほか、`standby_write`、`standby_flush`、`primary_flush`の4種です。`NO_THROW`を付けるとタイムアウトがエラーではなく`timeout`という戻り値になるため、アプリ側で「待ちきれなければプライマリへ」の分岐が書けます。`TIMEOUT`を省くと無期限に待つ点は見落としやすいので、必ず上限を付けてください。スタンバイ構成そのものの組み方は[repmgrとは？PostgreSQLのレプリケーション管理と自動フェイルオーバー構築](https://www.issoh.co.jp/tech/details/3756/)で扱っています。 ### ON CONFLICT DO SELECTとCOPY TOのJSON出力の書き方 アプリ実装で効いてくるのが、[INSERT ... ON CONFLICT DO SELECT](https://www.postgresql.org/docs/19/sql-insert.html)です。重複したときに更新せず、既存行をそのまま返します。従来は`DO NOTHING`のあとに`SELECT`を投げ直すか、意味のない`DO UPDATE`で行を返させていました。 ``` -- 無ければ作り、あれば既存行のidを返す（get-or-create） INSERT INTO tags (name) VALUES ('postgres') ON CONFLICT (name) DO SELECT RETURNING id; -- 結果をJSON配列としてファイルに書き出す（COPY TO専用） COPY (SELECT id, name FROM tags ORDER BY id) TO STDOUT (FORMAT json, FORCE_ARRAY); ``` `DO SELECT`は競合対象の列指定と`RETURNING`が必須で、`FOR UPDATE`を付ければ返した行のロックも同時に取れます。[COPYのJSON形式](https://www.postgresql.org/docs/19/sql-copy.html)は出力専用で、`COPY FROM`では使えません。SQLの`NULL`とJSONの`null`リテラルが同じ`null`に出る点は、データ連携で受け側が両者を区別しているなら事前に確認が要ります。 ## autovacuum並列化と論理レプリケーションの改善を運用設計に反映する観点 ### autovacuumの並列ワーカーとスコア順で大テーブルの待ちを減らす 19のautovacuumは、テーブルの索引を並列ワーカーで掃除できるようになりました。全体の上限はサーバ変数`autovacuum_max_parallel_workers`、テーブルごとの指定は格納パラメータ`autovacuum_parallel_workers`で決めます。索引を多く抱える大きな更新系テーブルほど効果が出る変更です。 もう1つは処理順の決め方です。従来はテーブルを順に見ていくだけでしたが、19は凍結の切迫度や不要行の量から点数を付け、高い順に処理します。重みは`autovacuum_vacuum_score_weight`など5つの変数で調整でき、現在の点数は新設の`pg_stat_autovacuum_scores`ビューで見えます。XID周回の警告しきい値も4,000万から1億へ引き上げられました。監視の閾値をこの値に合わせて見直してください。 ### シーケンス複製とwal\_level=replicaでの自動有効化が効く移行場面 論理レプリケーションでメジャー版を上げるとき、これまでシーケンスの値は複製されず、切替直前に`setval`で手合わせするのが定番の手順でした。19は`ALTER SUBSCRIPTION ... REFRESH SEQUENCES`と`ALL SEQUENCES`付きのパブリケーションで、値を購読側へ写せます。 もう1点、`wal_level`が`replica`のままでも、論理レプリケーションが必要になった時点で自動的に有効になります。実際に有効になっている値の確認先は、新しい`effective_wal_level`です。`wal_level=logical`への変更に再起動が要るせいで移行の段取りが1回増えていた環境では、この差が効きます。ただし移行元が18以前なら、送り側の制約は旧版のままです。19の恩恵を受けるのは、19から20へ上げる次の移行からだと考えてください。 ### NOT INのANTI JOIN変換とJIT既定無効でクエリ性能が動く箇所 オプティマイザ側では、NULLが入らないと分かっている`NOT IN`を`ANTI JOIN`へ書き換えるようになりました。`NOT EXISTS`へ手で書き直していた遅いクエリは、19では書き換えなしで速くなる可能性があります。一部の集約を結合の前に済ませる書き換えも入りました。 逆方向に動くのがJITです。19は既定で無効になり、公式は理由を「コスト見積もりが当てにならないと判断した」と説明しています。大きな集計クエリを多く流す分析用途では、`jit = on`を明示しないと18より遅くなる場合があります。上げたあとは同じクエリで[EXPLAIN ANALYZEによる実行計画の比較](https://www.issoh.co.jp/tech/details/16994/)を行い、JIT欄の有無と実行時間を突き合わせてください。 ## 18から19へ上げる前に確認する非互換と設定値の変更点の洗い出し ### pg\_upgradeが拒否するクラスタ条件とbtree\_gistのinet索引 リリースノートの移行の章には17項目が並びます。最初に確認すべきは、`pg_upgrade`がそもそも処理を拒否する2つの条件です。 1. データベース名、ロール名、テーブルスペース名に改行（CRやLF）を含むものがある 2. `btree_gist`拡張の`inet`または`cidr`の演算子クラスで作った索引がある 2つ目は、旧来の演算子クラスが行を取りこぼす不具合を抱えていたための措置です。該当する索引は、18のうちに標準のGiST演算子クラスで作り直してから上げます。名前の確認は`pg_database`や`pg_roles`への問い合わせで済みます。どちらも本番の直前ではなく、検証環境で`pg_upgrade --check`を通す段階で潰しておくのが安全です。 ### MD5警告とRADIUS削除・文字列エスケープ固定の影響範囲 認証まわりでは、RADIUS認証が削除されました。`pg_hba.conf`に`radius`の行が残っていても、19ではその認証方式自体が使えません。上げる前に別の方式へ移してください。MD5パスワード認証は成功しても警告を出すようになり、`md5_password_warnings`で止められます。MD5は18で非推奨になっているので、警告を消すより`scram-sha-256`への切替を先に進めてください。手順は[PostgreSQLのロールと権限設計](https://www.issoh.co.jp/tech/details/16984/)のパスワード周りと重なります。 見落としやすいのが`standard_conforming_strings`の常時`on`化です。`off`の状態で取った18以前のダンプは、19へ正しく読み込めない場合があります。古いアプリで`off`を前提にしているかは、`SHOW standard_conforming_strings;`とダンプの先頭にある`SET`文で確かめられます。 ### max\_locks\_per\_transaction倍増など値の意味が変わった設定項目 設定値そのものの意味が変わった項目は、構成管理のテンプレートを持ち越すと静かに効きます。 | 項目 | 18まで | 19 | 対応 | | --------------------------- | -------------- | -------- | -------------- | | `max_locks_per_transaction` | 既定64 | 既定128 | 独自値は2倍にして同じ容量 | | `jit` | 既定on | 既定off | 分析用途は明示的にon | | `log_lock_waits` | 既定off | 既定on | ログ量の増加を見込む | | 自動VACUUMのログ出力しきい値 | vacuumとanalyze | vacuumのみ | analyzeは新変数で指定 | 表の自動VACUUMのログ出力しきい値は、`log_autovacuum_min_duration`の設定です。 筆頭の`max_locks_per_transaction`は、ロックの割り当て方式が変わったため、18で256を入れていた環境は19で512にしないと同じ数を確保できません。パーティションを数百持つテーブルで「out of shared memory」が出る典型的な原因になるので、移行チェックリストの上位に置いてください。 ### 監視スクリプトが壊れる改名とjson\_arrayの戻り値の変化 監視やアプリが名前で参照している箇所も変わります。待機イベントの型`BUFFERPIN`は`BUFFER`へ、`pg_stat_subscription_stats`の`sync_error_count`は`sync_table_error_count`へ改名されました。どちらも名前一致で集計している監視は、値が取れず0件に見えます。 SQLの実行結果が従来と変わる点も、移行前の確認対象です。`json_array()`は行が無いとき`NULL`ではなく空の配列を返すようになり、`IS NULL`で「該当なし」を判定していた処理は分岐が逆になります。`postgres_fdw`では、`READ ONLY`トランザクションの属性がリモート側へ伝わるようになり、読み取り専用トランザクションの中からリモート表を更新していた処理はエラーになります。 ## 19を本番採用する条件と見送る場面・14サポート終了との優先順位 ### 14系は2026年11月12日で終了・19を待たず18へ上げる判断 [公式のバージョン方針](https://www.postgresql.org/support/versioning/)では、14系の最終リリースは2026年11月12日です。19のGAが10月に間に合ったとしても、検証と移行の期間を考えれば14の期限には届きません。14を動かしているなら、結論は1つです。**19を待たず、18（18.6系・2030年11月14日まで）へ上げる計画を先に確定させてください。** 18へ上げておけば、19への移行は後から別の案件として計画することが可能です。いま動いている版の確かめ方と期限の読み方は[PostgreSQLのバージョン確認方法とEOL判定](https://www.issoh.co.jp/tech/details/16965/)にまとめています。移行方式の選び方は[PostgreSQLのバックアップ設計](https://www.issoh.co.jp/tech/details/16996/)のダンプとPITRの章、停止時間をどこまで許すかの考え方は[インプレースアップグレードの採用判断](https://www.issoh.co.jp/tech/details/14688/)が参考になります。 ### 19.0を本番投入しない場面と19.1以降へ回すべき構成の条件 新規のシステムでも、19.0をそのまま本番へ入れるのは勧めません。次のどれかに当てはまるなら、11月12日予定の次の定例マイナー版以降まで待つか、18で始めてください。 - `pgvector`や`PostGIS`など、19対応版の提供が追いついていない拡張に依存している - RDSやAuroraで運用する予定で、クラウド側の19の正式提供がまだ発表されていない - `REPACK`やシーケンス複製など、19で入ったばかりの機能を本番の保守手順に組み込む前提で設計している 逆に、オンプレや自前のVMで動かす新規案件で、拡張依存が薄く、GA後に数か月の検証期間を取れるなら19から始める価値があります。`REPACK CONCURRENTLY`で外部ツールの`pg_repack`を外せる点は、保守の手間を1つ減らします。 ### マネージド環境で19を先行検証する順序とRDSプレビュー環境の制約 RDSやAuroraで動かしている場合、コミュニティのGAとクラウド側の提供開始日は一致しません。AWSはBeta段階から、本番と切り離したデータベースプレビュー環境で19を出しています。プレビュー環境のインスタンスは最大60日で自動削除され、料金は米国東部（オハイオ）に準じた設定です。プレビュー環境で取ったスナップショットは通常の環境へ戻せないため、検証データはダンプで出し入れする前提になります。 実務の順番は、まずDockerの19beta4で非互換17項目を当て、次にクラウドのプレビュー環境でパラメータグループと拡張の対応を確かめ、正式提供後に本番の更新計画へ進む流れが無駄がありません。RDSとAuroraでの延長サポートや版の追従の違いは、[Amazon RDS for PostgreSQLとは](https://www.issoh.co.jp/tech/details/16972/)と[Aurora PostgreSQLとは](https://www.issoh.co.jp/tech/details/16970/)で整理しています。14の期限と18/19の移行が重なって社内で手が回らない場合は、[データベース設計・移行支援](https://www.issoh.co.jp/service/system/database/)で、非互換の棚卸しから切替リハーサルまでを請け負っています。 ## PostgreSQL 19の新機能と移行についてのよくある質問 PostgreSQL 19の公開時期、Beta版の扱い、旧版からの移行について、検索の多い質問に答えます。 ### PostgreSQL 19の正式リリース日はいつですか？ 2026年10月11日時点で確定していません。Beta 4の告知はRCを10月上旬、GAを10月の可能性ありと書き、公式ロードマップも「2026年10月予定」とだけ示しています。リリースノートの日付欄も「2026-??-??」のままです。社内の計画では、GA日は公式の告知が出てから確定させるのが確実でしょう。 ### Beta版のPostgreSQL 19を本番環境で使ってもよいですか？ 使うべきではありません。Beta 4では5つの機能が丸ごと取り下げられたように、正式版までに機能や挙動が変わります。Beta間の更新でもダンプとリストアか`pg_upgrade`が必要で、データ領域の互換も保証されません。検証用の使い捨て環境に限ってください。 ### REPACKが入ったらpg\_repack拡張は不要になりますか？ 19へ上げた環境では、`REPACK CONCURRENTLY`で多くの用途を置き換えられます。ただし主キーも索引ベースのレプリカ識別も無いテーブル、`UNLOGGED`テーブル、パーティション親テーブルには使えません。18以前の環境では引き続き`pg_repack`が必要です。 ### PostgreSQL 14から19へ直接上げられますか？ `pg_upgrade`は複数のメジャー版を飛ばした更新に対応しているため、手順上は可能です。ただし19のGAと14のサポート終了（2026年11月12日）の間はほとんど空かないため、期限内に検証を終えるのは難しいでしょう。14は先に18へ上げ、19は落ち着いてから別に計画する二段構えを勧めます。 ### SQL/PGQのグラフ問い合わせはPostgreSQL 19で使えますか？ 使えません。Beta 1〜3には入っていましたが、9月24日のBeta 4で取り下げられました。19の正式版には含まれない前提で設計してください。次のメジャー版以降で再び入るかは、現時点で公式から示されていません。 ## 関連記事 - [PostgreSQLのバージョン確認方法｜サーバ・クライアント別コマンドとEOL判定・更新計画](https://www.issoh.co.jp/tech/details/16965/)：いま動いている版と残りサポート期間の読み方 - [Docker PostgreSQL構築の手順｜18で変わったボリューム位置とcompose定義](https://www.issoh.co.jp/tech/details/16976/)：19beta4を試す検証環境の組み方 - [PostgreSQLのVACUUM運用｜autovacuumのしきい値設計とXID周回・肥大の切り分け](https://www.issoh.co.jp/tech/details/16982/)：REPACKに頼る前の肥大対策 - [Amazon RDS for PostgreSQLとは？マルチAZ構成・延長サポート課金・DMS移行](https://www.issoh.co.jp/tech/details/16972/)：マネージドでの版追従と延長サポート - [PostgreSQLのライセンスと価格：無償の範囲と実際に払う費用](https://www.issoh.co.jp/column/details/16916/)：版の維持工数を含めた5年総額の考え方 --- 出典: [PostgreSQL 19の新機能｜Beta 4時点の確定機能と差し戻し・18からの移行で壊れる箇所]()（株式会社一創）