PostgreSQL 19の新機能｜Beta 4時点の確定機能と差し戻し・18からの移行で壊れる箇所

PostgreSQL 19は、2026年10月11日の時点でまだ正式版ではありません。最新は9月24日公開のBeta 4で、この版でSQL/PGQ（グラフ問い合わせ）を含む5つの機能が取り下げられました。Beta 1の頃の紹介記事を頼りに検証を始めると、試そうとした機能がそもそも入っていない事態が起こります。この記事では、Beta 4時点の公式リリースノートを正として、残った新機能をDockerで動かすSQL、18から上げるときに壊れる設定と挙動、そして19を待つべきか18へ先に上げるべきかの判断までを実装者向けにまとめました。製品としての位置づけはデータベースとは？種類・DBMS・RDBとNoSQLの選び方で先に押さえておくと読みやすくなります。

まとめ：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、9月24日にBeta 4が出ました。Beta 4の告知は次をRC（リリース候補）とし、時期を「early October」、GAも「may also occur in October」と書いています。

ただし10月11日時点で、postgresql.orgのニュース一覧にRC1の告知はまだ出ていません。ロードマップも「planned for October 2026」と月までしか示していないため、GA日は未確定として扱うのが正確です。Beta同士の更新でも告知はpg_upgradeかダンプとリストアを求めており、検証用クラスタはBetaが上がるたびに作り直す前提で組んでください。

SQL/PGQやFOR PORTION OFなどBeta 4で取り下げられた機能一覧

Beta 4の告知で「Revert」と明記された機能は次のとおりです。いずれも19の正式版には入らない前提で読んでください。

表のSQL/PGQは、プロパティグラフを問い合わせる機能です。統合・分割SQLはALTER TABLE ... MERGE PARTITIONSとSPLIT PARTITIONS、DDL出力関数はpg_get_role_ddl()などを指します。

影響が大きいのはSQL/PGQです。2026年7月16日のRDSデータベースプレビュー環境のBeta 2告知は、新機能の筆頭近くにSQL/PGQを挙げていました。この告知や同時期の解説を根拠に19でグラフ問い合わせを使う設計を進めていたなら、20以降まで待つか、拡張や別製品で代替する方向へ切り替える必要があります。

REPACKとWAIT FOR LSNで変わる保守運用をSQLで試す手順

Docker公式イメージ19beta4で検証環境を立ち上げる手順

手元で試すなら、Docker公式の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構築の手順と同じ考え方で足ります。Betaのデータ領域は次の版で読めなくなる可能性があるので、使い捨ての前提にしてください。

REPACK CONCURRENTLYでVACUUM FULLのロックを避ける条件

19の最大の変更はREPACKです。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運用で整理した考え方のままです。

WAIT FOR LSNでスタンバイ読み取りの書き込み直後ずれを防ぐ

読み取りをスタンバイへ逃がす構成では、更新した直後の画面で古い値が見えるという不具合が付きものでした。19のWAIT FOR LSNは、指定した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のレプリケーション管理と自動フェイルオーバー構築で扱っています。

ON CONFLICT DO SELECTとCOPY TOのJSON出力の書き方

アプリ実装で効いてくるのが、INSERT ... ON CONFLICT DO SELECTです。重複したときに更新せず、既存行をそのまま返します。従来は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形式は出力専用で、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による実行計画の比較を行い、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のロールと権限設計のパスワード周りと重なります。

見落としやすいのがstandard_conforming_stringsの常時on化です。offの状態で取った18以前のダンプは、19へ正しく読み込めない場合があります。古いアプリでoffを前提にしているかは、SHOW standard_conforming_strings;とダンプの先頭にあるSET文で確かめられます。

max_locks_per_transaction倍増など値の意味が変わった設定項目

設定値そのものの意味が変わった項目は、構成管理のテンプレートを持ち越すと静かに効きます。

表の自動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へ上げる判断

公式のバージョン方針では、14系の最終リリースは2026年11月12日です。19のGAが10月に間に合ったとしても、検証と移行の期間を考えれば14の期限には届きません。14を動かしているなら、結論は1つです。19を待たず、18（18.6系・2030年11月14日まで）へ上げる計画を先に確定させてください。

18へ上げておけば、19への移行は後から別の案件として計画することが可能です。いま動いている版の確かめ方と期限の読み方はPostgreSQLのバージョン確認方法とEOL判定にまとめています。移行方式の選び方はPostgreSQLのバックアップ設計のダンプとPITRの章、停止時間をどこまで許すかの考え方はインプレースアップグレードの採用判断が参考になります。

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とはとAurora PostgreSQLとはで整理しています。14の期限と18/19の移行が重なって社内で手が回らない場合は、データベース設計・移行支援で、非互換の棚卸しから切替リハーサルまでを請け負っています。

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判定・更新計画：いま動いている版と残りサポート期間の読み方
• Docker PostgreSQL構築の手順｜18で変わったボリューム位置とcompose定義：19beta4を試す検証環境の組み方
• PostgreSQLのVACUUM運用｜autovacuumのしきい値設計とXID周回・肥大の切り分け：REPACKに頼る前の肥大対策
• Amazon RDS for PostgreSQLとは？マルチAZ構成・延長サポート課金・DMS移行：マネージドでの版追従と延長サポート
• PostgreSQLのライセンスと価格：無償の範囲と実際に払う費用：版の維持工数を含めた5年総額の考え方