データベース

PostgreSQL 19の新機能とは？――非同期I/Oと仮想生成列が変えるデータベース運用、Beta 4で確認できる変更点と移行準備のすべて

Q: 非同期I/O（AIO）とio_uringはPostgreSQL 18と19のどちらで使えるようになりますか？

非同期I/Oサブシステム自体は、まずPostgreSQL 18で導入されました。iomethodパラメータでsync・worker・iouringの3方式を選択でき、公式プレスリリースでは特定のシナリオで最大3倍の読み取り性能向上が報告されています。PostgreSQL 19はその実用化を強化する位置づけで、I/Oワーカー数の自動スケーリング（iominworkers／iomaxworkersなど）、大きなリクエストに対するリードアヘッドスケジューリングの改善に加え、EXPLAIN ANALYZEへのIOオプションやautoexplain.logioといった観測手段が追加されます。

open claw

08 10月 2026 • 17 min read

はじめに――「次のメジャーバージョン」への備えはいつ始めるべきか

「PostgreSQLのメジャーアップグレード、そろそろ着手しないとな……」――そう思いながら、日々の運用に追われて先送りしていないでしょうか。

メジャーバージョンのアップグレードは、マイナーバージョン更新とは比較にならないほど慎重さが求められる作業です。アプリケーションが動かなくなるかもしれない。拡張モジュールの互換性が崩れるかもしれない。しかも一次情報の多くは英語で、リリースノートを読み解くだけでも一仕事です。さらに、pg_upgradeの実行時間や切り戻し手順を、実は誰も検証したことがない――というケースも珍しくありません。「本番に適用していいタイミング」を見極められず、現行バージョンのまま様子見を続けている現場も少なくないのではないでしょうか。

その「次のメジャーバージョン」が、いま目の前に来ています。PostgreSQL Global Development Groupは2026年9月24日、PostgreSQL 19 Beta 4をリリースしました（postgresql.org公式のアナウンスによる確定情報です）。すでにフィーチャーフリーズ（2026年4月8日）を経ており、搭載される機能はほぼ確定しています。このあとはRC1（2026年10月15日予定）を挟んで、正式リリース（GA）が2026年10月29日に予定されています（公式Wiki「PostgreSQL 19 Open Items」のスケジュールによる予定日であり、変更される可能性があります）。機能の全体像が固まり、GAまでに検証期間を確保できる――移行準備の着手には、まさに今が適切なタイミングなのです。

なお、ベータ版はあくまでテスト用のリリースであり、本番環境での使用は公式に非推奨とされています（postgresql.org/developer/beta/）。ベータで行うべきは機能の確認と互換性の評価であり、その結果をGA後の移行判断につなげるのが正しい向き合い方です。正式版が出てから慌てて評価を始めると、計画通りに移行できなくなるおそれがあります。逆に言えば、今のうちに「何が変わるのか」を把握し、検証計画を立てておけば、GA後に落ち着いて判断できるというわけです。

本記事では、PostgreSQL 19 Beta 4を題材に、以下の4点を解説します。

PostgreSQL 19の主要新機能――前バージョン18で導入された非同期I/Oと仮想生成列が、19でどのように強化されたのか
バージョン比較――PostgreSQL 17/18/19を主要な観点で整理し、「19は18の大型機能を実運用に仕上げるリリース」であることを確認します
移行手順と注意点――pg_upgradeを使った具体的なアップグレード手順と、把握が必須の非互換変更
本番投入前の評価の進め方――ベンチマークと検証のチェックリスト

たとえばPostgreSQL 19では、非同期I/OのI/Oワーカーが負荷に応じて自動的に増減する仕組みや、非同期I/Oの動きを可視化するEXPLAIN ANALYZE ... IOオプションが加わり、実運用での扱いやすさが一段と高まっています。仮想生成列も拡張統計情報に対応し、プランナーの精度向上が期待できるようになりました。一方で、JITのデフォルト無効化など、アップグレード前に把握しておくべき変更も含まれています。

「アップグレードは壊れるかもしれないから怖い」「情報が英語で追いきれない」「いつ動いていいのか分からない」――こうした悩みに対する具体的な答えを、この記事で一緒に整理していきましょう。

PostgreSQL 19の主要新機能――非同期I/Oと仮想生成列が「運用」を変える

まず前提を押さえておきます。非同期I/O（AIO）と仮想生成列は、いずれもPostgreSQL 18で導入された機能です。PostgreSQL 19（以下PG19）は、この2つを実運用に近づける強化が中心のリリースで、さらにREPACKやWAITといった運用直結の新コマンドが加わります。以下、PostgreSQL 19リリースノート（Beta 4時点のスナップショット版）で確認できる範囲で見ていきましょう。本記事の機能名・パラメータ名・挙動の記述は、すべてこのリリースノート本文と項目ごとに照合しています。

非同期I/O（AIO）――18で導入された大型機能が「自動化」と「可視化」で実運用へ

非同期I/OサブシステムはPostgreSQL 18で新設され、io_methodパラメータでsync（従来の同期I/O）/worker（専用ワーカー経由）/io_uring（Linuxカーネルの非同期I/O機構）の3方式を選べるようになりました。公式プレスリリースによれば、PG18のAIOは読み取り負荷の高い一部のシナリオで最大3倍の読み取り性能向上が報告されています（出典: PostgreSQL 18 Released!（公式プレスリリース））。

PG19では、このAIOを実運用向けへ強化しています。

I/Oワーカーの自動スケーリング: io_method = worker のとき、負荷に応じてI/Oワーカー数が自動増減します。新GUCは io_min_workers / io_max_workers / io_worker_idle_timeout / io_worker_launch_interval です。
リードアヘッドの改善: 大きなリクエストに対するAIOのリードアヘッドが改善しました。
可視化: EXPLAIN ANALYZE に IO オプションが新設され、非同期I/Oの活動をレポートできます。auto_explain.log_io も追加されました。

仕組みを図に整理すると次の通りです。

flowchart LR
  A[クエリ] --> B{io_method}
  B -- sync --> C[同期I/O<br>従来動作]
  B -- worker --> D[I/Oワーカープール]
  D --> E[負荷に応じて自動増減<br>io_min/max_workers]
  E --> F[ストレージ並列読み取り]
  F --> G[EXPLAIN ANALYZE IO<br>で活動を可視化]
  B -- io_uring --> H[(Linux io_uring)]

図を補足します。syncはPG18以前と同じ同期I/Oです。workerでは専用I/Oワーカーのプールが読み取り要求を非同期にさばき、PG19からは io_min_workers〜io_max_workers の範囲でプールが自動増減します（アイドルワーカーの回収は io_worker_idle_timeout、追加起動の間隔は io_worker_launch_interval で制御）。Linuxの io_uring はカーネルの非同期I/O機構を直接利用します。どの方式でも EXPLAIN ANALYZE ... IO や auto_explain.log_io でI/O活動を観測できる点が大きな前進です。

このほかI/O周りでは、テーブルスキャンがvisibility mapにall-visibleマークを付けられるようになった点（従来はVACUUMとCOPY FREEZEのみ）も見逃せません。ハッシュインデックスの一括削除やGINインデックスのバキュームはストリーミングリードを使うようになり、COPY FROM（テキスト/CSV）もSIMD命令で高速化しました。

なお、PG19単体の公式ベンチマーク数値は現時点で未公表（未確認）です。「最大3倍」はあくまでPG18の公式数値であり、PG19の効果はGA後に自社ワークロードで計測して判断することになります。

仮想生成列――拡張統計情報対応でプランナー精度が向上

仮想生成列（VIRTUAL GENERATED）もPostgreSQL 18で導入されました。式の計算を読み出し時に行うためストレージを消費せず、PG18からは生成列のデフォルト種別になっています。

PG19では、この仮想生成列の実運用面が補強されました。

拡張統計情報（extended statistics）の作成を許可: 仮想生成列に対する拡張統計が作成できるようになり、複数列の相関を考慮したプランナーの見積もり精度が向上します。あわせて拡張統計のバックアップ/復元用に pg_restore_extended_stats() / pg_clear_extended_stats() 関数も追加されました。
式の変更を許可: CHECK制約が付いた仮想生成列について、ALTER TABLE ... COLUMN SET EXPRESSION による式変更が可能になりました（従来は禁止）。

制限の把握も重要です。生成式はビルトインのイミュータブル関数のみ（ユーザー定義関数・型は参照不可）で、サブクエリや他の生成列の参照、パーティションキーへの指定はできません。論理レプリケーションの対象にできるのはストアド生成列のみです（PG18ドキュメント準拠）。「SQLの式で完結する列は仮想、複雑なロジックやレプリ対象はストアド」という使い分けが現実解です。

テーブル再編――新コマンド「REPACK」で読み書きをブロックせず

運用者にとって待望なのがREPACKコマンドの新設です。従来のVACUUM FULLとCLUSTERの機能を統合した新コマンドで、REPACK (CONCURRENTLY) を使えばテーブルの読み書きをブロックせずに再編（ディスク容量回収・再構成）が可能になります。日中も止められない肥大化対策を、標準機能として実施できるようになります（ベータ段階の機能であるため、正式版での最終仕様はリリースノートの更新をご確認ください）。関連GUCとして max_repack_replication_slots が追加され、旧コマンド（VACUUM FULL / CLUSTER）も互換性のため残ります。

スタンバイ運用――新コマンド「WAIT」でread-your-writesを簡単に

新SQLコマンドのWAITは、スタンバイ側で指定LSNまでのWAL適用（write/flush/replay）を待機するものです。アプリ側の工夫なしに、「自分の書き込みが反映された状態」を待ってから読み取るread-your-writes構成が、SQLだけで簡単に組めるようになります。

論理レプリケーション――シーケンス複製と再起動なしの有効化

シーケンス値のレプリケーションに対応しました（CREATE/ALTER PUBLICATION ... ALL SEQUENCES、ALTER SUBSCRIPTION ... REFRESH SEQUENCES など）。
wal_level = replica のまま、必要なときにだけ論理レプリケーションをサーバー再起動なしで有効化できます。実効レベルは新GUC effective_wal_level で確認可能です。
ほかにも、パブリケーションの EXCEPT 句によるALL TABLESからのテーブル除外や、サブスクリプション新設定 retain_dead_tuples / max_retention_duration（競合検出用情報の保持）が加わりました。

並列autovacuumと監視の進化

並列インデックスバキューム: インデックスのバキュームに並列ワーカーを使えるようになりました（GUC autovacuum_max_parallel_workers、テーブル単位の autovacuum_parallel_workers）。
スコアリングによる優先順位付け: どのテーブルをバキューム/分析すべきかをスコアで自動判定する新しい仕組みが導入され、pg_stat_autovacuum_scores ビューで確認できます。
監視系の拡充: 新システムビューとして pg_stat_lock（ロック種別ごとの統計）と pg_stat_recovery（リカバリ状況）が追加されました。log_lock_waits はデフォルトで有効化され、xid/multixactのラップアラウンド警告も1億トランザクション前から（従来は4,000万）発報されます。
このほか、プランナーの判断を制御する新エクステンション pg_plan_advice（pg_stash_advice と併用）も追加されています。

まとめると、PG19の新機能は「18で導入したAIOと仮想生成列を、自動スケーリング・可視化・拡張統計対応によって実運用に仕上げる」ことに軸足があり、そこへREPACK・WAIT・論理レプリケーション強化・並列autovacuumといった運用面の進化が重なっています。機能一覧の一次出典は公式リリースノート（postgresql.org/docs/19/release-19.html）で、GAに向けて更新されるため最終版の再確認を推奨します。

バージョン比較表で見るPostgreSQL 17/18/19

機能を1つずつ眺めるだけでは、PostgreSQL 19がどのような位置づけのリリースなのかはつかみにくいものです。そこでここでは、直近3バージョンの主要な動きを並べて比較します。見方のポイントは、18の列で新たに登場した機能が、19の列でどう「仕上げられているか」に注目することです。とくに非同期I/Oと仮想生成列は18で導入され、19で強化された機能群であり、この「18で導入→19で強化」という流れを意識すると、19の変更内容が整理しやすくなります。

観点	PostgreSQL 17（2024-09リリース）	PostgreSQL 18（2025-09-25リリース）	PostgreSQL 19（GA予定 2026-10-29）
非同期I/O	なし（OSのreadahead頼み）	AIOサブシステム新設（io_method: sync/worker/io_uring）、シーケンシャルスキャン・ビットマップヒープスキャン・VACUUMが対象、最大3倍の読み取り改善を報告	自動ワーカースケーリング（io_min/max_workers等）、リードアヘッド改善、EXPLAIN ANALYZE IOオプション、auto_explain.log_io
生成列	ストアド生成列のみ	仮想生成列導入（デフォルト種別化）、ストアド生成列の論理レプリ対応	仮想生成列の拡張統計対応、CHECK制約付き仮想列の式変更を許可
テーブル再編	VACUUM FULL/CLUSTER（排他ロック）	同左	REPACK新設（統合コマンド）、`CONCURRENTLY`で読み書きブロックなし
論理レプリケーション	—	競合報告、並列ストリーミング既定化、idleスロット自動削除	シーケンス複製、wal_level=replicaのまま再起動なしで有効化、EXCEPT句、retain_dead_tuples
バキューム	—	積極的なフリーズでラップアラウンド対策	並列インデックスバキューム＋スコアリング優先順位
スタンバイ運用	—	—	WAITコマンド（read-your-writes）
アップグレード	pg_upgrade従来型	統計引き継ぎ、`--swap`、並列チェック	LOメタデータコピー高速化、PGDATA内テーブルスペース対応、ほぼ全統計引き継ぎ
監視	—	per-backend I/O/WAL統計、pg_stat_ioバイト列	pg_stat_lock / pg_stat_recovery / pg_stat_autovacuum_scores、log_lock_waits既定on
認証	SCRAM	OAuth 2.0、MD5非推奨化	MD5で警告、RADIUS削除、SNI対応、パスワード期限警告
その他目玉	—	uuidv7()、スキップスキャン、時間制約（WITHOUT OVERLAPS）、プロトコル3.2、initdbでチェックサム既定on	ウィンドウ関数IGNORE NULLS、ON CONFLICT DO SELECT RETURNING、COPY TO JSON、プランナーアドバイス拡張

※PostgreSQL 17の欄は一般に知られている内容に基づく参考表現です。18の欄はPostgreSQL 18公式プレスリリース、19の欄はPostgreSQL 19リリースノート（Beta 4時点）に基づいています。

① 非同期I/O：「導入した」から「使いこなす」へ。 非同期I/O（AIO）サブシステム自体は18で新設され、io_methodの選択（sync/worker/io_uring）とともに、特定シナリオで最大3倍の読み取り改善が公式に報告されました。19はその上に立ち、I/Oワーカーの自動スケーリング（io_min/max_workers等）やEXPLAIN ANALYZEのIOオプション、auto_explain.log_ioによって、チューニングと観測の面を実運用仕様へ引き上げています。

② 仮想生成列：プランナー精度とスキーマ運用の補強。 仮想生成列（読み出し時に計算されストレージを消費しない生成列）は18で導入され、生成列のデフォルト種別になりました。19では拡張統計情報を作成できるようになったため実行計画の精度が上がり、CHECK制約付き仮想列でのALTER TABLE ... COLUMN SET EXPRESSION（式の変更）も許可されました。本番での使い始めやすさが大きく前進しています。

③ 運用機能の積み増しが19のもう一つの柱。 テーブル再編のREPACK、スタンバイ運用のWAITコマンド、論理レプリケーションのシーケンス複製、並列autovacuumなど、19の行は「18にはなかった要素を埋める」方向で埋まっています。一方で監視・認証の行は19の変更項目が多く、メジャーアップグレード時に確認すべき事項が増えることもこの表から読み取れます。

一行でまとめるなら、19のテーマは「18の大型機能を実運用に耐える仕上げ」です。なお、PostgreSQL 19は執筆時点でBeta 4（2026-09-24リリース）の段階であり、GAは公式Wikiのスケジュールで2026-10-29（予定）とされています。日程には変更の可能性がある点にご留意ください。

実践ステップ――pg_upgradeで移行する手順と落とし穴

PostgreSQLはメジャーバージョン間でデータ形式の互換性がなく、19への移行はダンプ＆リストアかpg_upgradeのいずれかです。ダウンタイムを抑えたい環境ではpg_upgradeが定番でしょう。GA（予定2026-10-29）が近いいま、公式のpg_upgradeドキュメント（PostgreSQL 19版）の標準手順に沿って流れを確認しましょう（本節のコマンド例とオプション説明は、同ドキュメントの記載と照合済みです）。

ステップ1: 事前互換チェックを実行する

移行を阻む要素がないか、pg_upgrade --checkで確認します。旧サーバー起動中でも実行でき、サービスへの影響がありません。後述の落とし穴（名称へのCR/LF混入、btree_gistのinet/cidrインデックス等）もこの段階で検出できます。

pg_upgrade \
  --old-datadir /var/lib/postgresql/18/main \
  --new-datadir /var/lib/postgresql/19/main \
  --old-bindir /usr/lib/postgresql/18/bin \
  --new-bindir /usr/lib/postgresql/19/bin \
  --check

ステップ2: 新バージョンの環境を準備する

新バージョンのバイナリを導入し、initdbで新クラスタを初期化します。旧クラスタと互換性のあるロケール・エンコーディング等を指定してください。利用中のエクステンションの共有オブジェクト（.so）も新バージョン用に別途導入します（スキーマ定義はpg_upgradeがコピー）。

ステップ3: 旧・新両サーバーを停止する

pg_upgradeは両サーバーが停止した状態で実行します。ストリーミングレプリケーションのスタンバイは、停止前にすべての変更を受信し終えていることを確認してください。

ステップ4: pg_upgradeを実行する

実行に使うのは、必ず新バージョンのpg_upgradeバイナリです。

pg_upgrade \
  --old-datadir /var/lib/postgresql/18/main \
  --new-datadir /var/lib/postgresql/19/main \
  --old-bindir /usr/lib/postgresql/18/bin \
  --new-bindir /usr/lib/postgresql/19/bin \
  --link --jobs 4

モードは要件に応じて選びます。

モード	特徴・注意点
既定（copy）	安全だが容量と時間を要する
`--link`	ハードリンクで高速・省ディスク。実行後は旧クラスタ起動不可
`--clone`	高速で旧クラスタを残せる（対応ファイルシステムのみ）
`--swap`	多数リレーションで最速級。旧クラスタに破壊的変更の可能性あり

--jobsの並列数はCPUコア数が目安です。pg_upgradeは誤接続防止のため既定でポート50432を使用します。スタンバイはlinkモードならrsyncで反映でき、link以外では作り直します。

ステップ5: 新サーバーを起動し、統計を補完する

新サーバーを起動したら、pg_upgradeが生成したpost-upgradeスクリプトを実行します。PostgreSQL 19のpg_upgradeはオプティマイザ統計を大部分引き継ぎますが、すべてではないため、次の順で補完します。

vacuumdb --all --analyze-in-stages --missing-stats-only
vacuumdb --all --analyze-only

ステップ6: 検証後に旧クラスタを削除する

アプリケーションの動作と監視を確認できるまで旧クラスタは残します。十分に検証してから削除しましょう（公式ドキュメントにrevert手順の記載あり）。

落とし穴――移行前に確認したい互換性変更

pg_upgradeが拒否する構成（ステップ1で検出可能）

データベース名・ロール名・テーブルスペース名へのCR/LF混入。19で禁止され、該当クラスタはpg_upgradeが拒否されます
btree_gistのinet/cidrインデックス。既定の索引opclassがbtree_gistからGiSTへ変更されました。行を取りこぼす問題があるため、該当インデックスがあるとpg_upgradeは拒否されます

移行後に動作が変わるもの

JITがデフォルト無効化: 分析クエリを多用する環境では、必要に応じて手動で有効化します
max_locks_per_transactionの既定値が64→128に: 旧リリースと実効容量を揃えるには設定値を2倍にします
TOAST圧縮の既定がpglz→lz4に: 圧縮率・速度の特性が変わり、ストレージ見積りに影響します

認証まわり

MD5パスワード認証では警告が発報されます（18で非推奨化）。SCRAMへの移行を進めることが強く推奨されます
RADIUSサポートが削除されました（UDPのみの対応で修正不能な脆弱性があるため）

ダンプ・エンコーディング互換

standard_conforming_stringsが常時onになり、旧pg_dumpのダンプ（off指定）は19へ正しくロードできません。ダンプは19以降のpg_dumpで取り直してください
MULE_INTERNALエンコーディングが削除されました。該当DBはダンプ＆リストアで別のエンコーディングへ移行します

監視まわり

pg_stat_subscription_statsの列名が変わりました（sync_error_count→sync_table_error_count）＋新列追加。ダッシュボードやアラートの修正が必要です
待機イベント名がBUFFERPINからBUFFERに変わりました。監視ツール側の対応が必要です

一方で、好材料もあります

19のpg_upgradeはオプティマイザ統計を大部分引き継ぐほか、ラージオブジェクトのメタデータコピーも高速化しています。大規模データベースほど移行時間短縮が期待できるでしょう。

導入評価の進め方――ベンチマークと検証のチェックリスト

新機能の概要と移行手順が見えたところで、次は「どう評価を進めるか」です。まず大前提として、ベータ版の本番環境での使用は公式が強く非推奨としています（PostgreSQLベータ情報ページ）。フィーチャーフリーズ済みとはいえ、重大なバグや後方互換性のない変更が残る可能性があります。したがって、Beta 4段階での検証は「新機能の理解」と「互換性・ツール対応の確認」に限定し、本番投入の判断はRC1（2026年10月15日）以降、確実を期すならGA（予定2026年10月29日）後が安全です。

実際、公式Wiki「PostgreSQL 19 Open Items」を見ると、Beta 4時点でも目玉機能周辺の修正が続いています（pg_*_advice のTSVロード失敗、並列autovacuum中の DROP DATABASE (FORCE) 失敗など）。一方でREPACK (CONCURRENTLY) の複数バグはRC1前に解決済みで、品質はRCへ収束しつつあります。この状況を踏まえ、次のチェックリストで検証を進めてください。

検証チェックリスト

互換性チェック

[ ] 現行クラスタで pg_upgrade --check を実行し、拒否要因（DB名・ロール名・テーブルスペース名のCR/LF、btree_gistのinet/cidrインデックス、MULE_INTERNALエンコーディング）を確認する
[ ] 利用中の拡張モジュールのPostgreSQL 19向け共有オブジェクト（.so）が各ベンダ・リポジトリで提供されているか確認する

アプリケーション・認証

[ ] MD5パスワード認証の利用有無を確認し、SCRAMへの移行計画を立てる（PG19では警告が発報）
[ ] RADIUS認証の利用有無を確認する（PG19で削除）
[ ] standard_conforming_strings の常時on化が既存SQLに影響しないか確認する
[ ] JITデフォルト無効化の影響を、実行計画・実行時間の比較で確認し、必要なら手動有効化を検討する

性能評価（非同期I/O）

[ ] io_method を sync / worker / io_uring の3態で切り替え、pgbench（--continue-on-error も利用可）など自社ワークロードでベンチ比較する
[ ] EXPLAIN ANALYZE ... IO と pg_stat_io で非同期I/Oの活動を観測する
[ ] io_min_workers / io_max_workers によるI/Oワーカー自動スケーリングの挙動を、負荷変動下で確認する
[ ] pg_test_timing（ナノ秒表示に改善）でタイミング計測のオーバーヘッドを点検する

運用機能の評価

[ ] 仮想生成列＋拡張統計情報（extended statistics）で実行計画が改善するか確認する
[ ] REPACK (CONCURRENTLY) の所要時間と運用負荷を実データに近いサイズで計測する
[ ] 並列autovacuumとスコアリング（pg_stat_autovacuum_scores）の効果を確認する

レプリケーション

[ ] シーケンス複製（ALL SEQUENCES）の動作を確認する
[ ] wal_level = replica のまま、サーバー再起動なしで論理レプリケーションを有効化できるか確認する
[ ] WAITコマンドでスタンバイのread-your-writesが実現できるか確認する

監視パイプライン

[ ] 新ビュー（pg_stat_lock など）の取り込みと、pg_stat_subscription_stats の列名変更、待機イベント名の変更（BUFFERPIN→BUFFER）へのアラート対応を行う

数値の扱いについて

性能評価で注意したいのは、PostgreSQL 19単体の公式ベンチマーク数値はまだ公表されていないという点です。非同期I/Oの「最大3倍」という読み取り改善の数値はPostgreSQL 18の公式プレスリリースによるもので、19の成績ではありません。GA後も当面は「自社のワークロード・自社のストレージでの計測結果」を唯一の判断材料と考え、外部の数値を引用するときは出典のバージョンを必ず確認してください。

最後に、アップグレード後には、pg_upgradeが生成するpost-upgradeスクリプトの実行と、vacuumdb --all --analyze-in-stages --missing-stats-only → --analyze-only による統計補完を忘れないでください。PG19のpg_upgradeはオプティマイザ統計を大部分引き継ぎますが、すべてではないため、不完全な統計のまま性能評価すると誤った結論を招く恐れがあります。

よくある質問（FAQ）

PostgreSQL 19の正式リリース（GA）はいつですか？

公式スケジュールでは、2026年10月29日がGA（正式リリース）の予定日です。その前段階として、リリース候補版のRC1が2026年10月15日に予定されています。ただし、これらは公式Wiki「PostgreSQL 19 Open Items」のImportant Datesに記載された予定日であり、変更される可能性があります。正式リリース日前のリリースノートはスナップショット版のため、実施の際は必ず公式サイトで最新情報を再確認してください。

非同期I/O（AIO）とio_uringはPostgreSQL 18と19のどちらで使えるようになりますか？

非同期I/Oサブシステム自体は、まずPostgreSQL 18で導入されました。io_methodパラメータでsync・worker・io_uringの3方式を選択でき、公式プレスリリースでは特定のシナリオで最大3倍の読み取り性能向上が報告されています。PostgreSQL 19はその実用化を強化する位置づけで、I/Oワーカー数の自動スケーリング（io_min_workers／io_max_workersなど）、大きなリクエストに対するリードアヘッドスケジューリングの改善に加え、EXPLAIN ANALYZEへのIOオプションやauto_explain.log_ioといった観測手段が追加されます。

仮想生成列は本番で使えますか？制限はありますか？

仮想生成列は読み出し時に計算されストレージを消費しない生成列で、PostgreSQL 18で導入され、生成列のデフォルト種別になりました。PostgreSQL 19では拡張統計情報（extended statistics）の作成が可能になり、プランナーの推定精度が向上します。ただし制限もあります。生成式にはユーザー定義関数を使えず、ビルトインのイミュータブル関数のみが許可されます。そのほか、サブクエリの利用不可、他の生成列の参照不可、パーティションキーとして使用不可といった制約があり、論理レプリケーションの対象にできるのはストアド生成列のみです（18時点の仕様）。なお19では、CHECK制約付きの仮想列に対してALTER TABLE ... COLUMN SET EXPRESSIONによる式の変更が許可されるようになりました。

ベータ版を本番環境で試してもいいですか？

公式はベータ版の本番使用を強く非推奨としています。ベータ段階では重大なバグが残っている可能性や、機能が後方互換性のない形で変更・削除される可能性が公式に注意喚起されています。ベータの適切な使い方は、新機能の理解や互換性確認、周辺ツールの対応準備です。本番環境を前提とした性能評価や移行の最終判断は、RC1以降、できればGA後の検証で行うことをおすすめします。

アップグレード時、一番注意すべき変更点は何ですか？

大きく4点あります。まず、JITがデフォルトで無効化されるため、大規模な分析クエリを多用する環境では手動での再有効化が必要です。次に、データベース名・ロール名・テーブルスペース名にCR/LFが含まれる構成や、btree_gistのinet/cidrインデックスを持つクラスタは、pg_upgradeが実行を拒否します。さらに、MD5パスワード認証では警告が発報されるため、SCRAMへの移行を進めることが推奨されます。最後に、pg_stat_subscription_statsの列名変更や待機イベント名のBUFFERPIN→BUFFER変更など、監視系の名称変更にも対応が必要です。これらの多くは、事前にpg_upgrade --checkを実行することで検出できます。

まとめ――GAまでにやるべき3つのアクション

この記事では、2026年9月24日にリリースされたPostgreSQL 19 Beta 4を題材に、次期メジャーバージョンの全体像と移行準備の進め方を確認してきました。

PostgreSQL 19の本質は、非同期I/O（AIO）と仮想生成列という「PostgreSQL 18で導入された大型機能」を実運用に近づける強化を中心に据えていることにあります。I/Oワーカーの自動スケーリングやEXPLAIN ANALYZE ... IOによる観測性向上、仮想生成列の拡張統計対応といった強化に加え、REPACKコマンド、WAITコマンド、論理レプリケーション強化、並列autovacuumなど、運用面の進化も見逃せません。一方で、JITのデフォルト無効化やMD5認証への警告など、アップグレード前に把握しておくべき非互換変更も含まれます。

読者の皆さんが今日から始められるアクションを、3つに整理します。

今すぐ: 現行クラスタでpg_upgrade --checkを実行する DB名・ロール名へのCR/LF混入やbtree_gistのinet/cidrインデックスといった拒否要因、MD5認証の有無を棚卸ししましょう。旧サーバーを起動したまま実行できるため、最も負担の少ない第一歩です。
RC1からGAまでの10月中: ステージング環境でRC1を評価する 2026年10月15日のRC1公開後に検証環境を構築し、自社ワークロードでAIO（io_methodのsync/worker/io_uringの3態）、REPACK、並列autovacuumの効果を計測します。ベータの本番使用は公式に非推奨のため、本番投入の判断はRC以降に限定するのが安全です。
GA後: 移行計画を確定する JIT無効化への対応と、監視ダッシュボードの更新（pg_stat_lockなどの新ビュー、pg_stat_subscription_statsの列名変更、待機イベントBUFFERPIN→BUFFER）を反映したうえで、ローリング移行の計画を固めます。pg_upgradeはオプティマイザ統計を大部分引き継ぎますが、移行後はvacuumdb --all --analyze-in-stagesで統計を補完するのを忘れずに。

正式リリース（GA）は予定では2026年10月29日です。日程には変更の可能性があるため、実施前には必ず公式リリースノートの最終版を再確認してください。メジャーアップグレードは「いつかやるもの」ではなく「準備した分だけ安全になるもの」です。Beta 4の段階から一歩ずつ動き出すことが、来る移行を静かな成功へ導いてくれるはずです。