PostgreSQL 19は何が変わるのか——SQL/PGQ、非同期I/O、そして2026年秋リリースを待つ新機能を読み解く

はじめに——PostgreSQL 19はいつリリース？何が変わる？

PostgreSQLのメジャーバージョンは毎年秋に登場しますが、2026年の主役は間違いなくPostgreSQL 19です。すでにBeta 1が2026年6月4日に、Beta 2が2026年7月中旬にリリースされており、正式版（GA）は2026年9月〜10月頃の見込みとなっています。ベータ段階ではありますが、機能面はほぼ固まっており、今のうちに何が変わるのかを把握しておく価値は十分にあります。

リリースまでの流れをタイムラインで整理すると、次のようになります。

timeline
    title PostgreSQL 19 リリースロードマップ
    2026年6月4日 : Beta 1 リリース（機能プレビュー）
    2026年7月中旬 : Beta 2 リリース（安定化段階）
    （追加ベータ・RCを経由）
    2026年9月〜10月頃 : 正式版（GA）リリース予定

なお、Beta期間中はプロトコル互換性の問題を洗い出すための一時的な「grease mode」キャンペーンも実施されています。ベータ版は本番利用を想定したものではありませんが、移行検証を前倒しで進める絶好の材料です。

PostgreSQL 19の位置づけ

一言でいえば、PostgreSQL 19は「PostgreSQL 18が築いた非同期I/Oの基盤の上に機能を積み増した版」です。PostgreSQL 18で導入された非同期I/Oサブシステム（io_uring対応を含む）を継承・拡張しつつ、その性能基盤を活かす最適化が数多く追加されています。

そして、最大の目玉はSQL/PGQ（SQL Property Graph Queries）でしょう。SQL標準構文でグラフクエリが書けるようになる、PostgreSQLの進化を象徴する機能です。従来はNeo4jなどのグラフデータベースやApache AGE拡張が必要だった用途を、PostgreSQL単体でカバーできるようになります。

本記事の読み方

本記事は、単なる新機能の羅列ではなく、「移行判断の観点」を軸にPostgreSQL 19を読み解きます。

• 目玉機能のSQL/PGQが何を可能にするのか
• 非同期I/Oの進化で性能がどのくらい変わるのか
• 開発者・DBAそれぞれが得する新機能
• 非互換変更点と、移行前後のチェックリスト

ベータ版の情報に基づいているため、正式リリース時には細部が変わる可能性がある点はご了承ください。その上で、2026年秋のGAに向けて今から準備できることを整理していきます。

SQL/PGQって何？——SQL標準構文でグラフクエリが書けるようになる理由

PostgreSQL 19の最も注目度が高い新機能が、SQL/PGQ（Property Graph Queries）です。これはSQL:2023標準に含まれるグラフクエリ仕様で、PostgreSQL 19でいよいよネイティブ実装されます。

従来のグラフクエリの課題

「顧客Aと顧客Bが同じ口座を経由してつながっているか」「ユーザーの友人の友人が購入した商品」のような関係性を横断するクエリは、リレーショナルモデルとの相性があまり良くありません。複数テーブルの多段JOINと再帰クエリ（WITH RECURSIVE）を駆使する必要があり、可読性も性能も課題になりがちでした。

そのため、不正検知、レコメンドエンジン、SNSの関係分析といった用途では、Neo4jなどのグラフデータベースを別途導入するか、PostgreSQLならApache AGE拡張に頼るのが定番でした。つまり「RDBとグラフDBの二重運用」というアーキテクチャ上の複雑さが付きまとっていたのです。

PostgreSQL 19で何ができるようになるか

SQL/PGQでは、既存のテーブルの上にグラフ構造をマッピングして定義し、その上でパターンマッチングによるクエリを実行できます。イメージは次のとおりです。

-- テーブル上にプロパティグラフを定義
CREATE PROPERTY GRAPH social_graph
  NODE TABLES (users, accounts)
  EDGE TABLES (
    transactions
      SOURCE KEY (from_id) REFERENCES users (id)
      DESTINATION KEY (to_id) REFERENCES users (id)
  );

-- MATCHパターンでグラフを横断するクエリ
SELECT * FROM GRAPH_TABLE (social_graph
  MATCH (a IS users) -[t IS transactions]-> (acc IS accounts) <-[t2 IS transactions]- (b IS users)
  WHERE a.id <> b.id
  COLUMNS (a.name AS user_a, b.name AS user_b, acc.id AS account_id)
);

（※ベータ版時点の機能に基づくイメージです。正式リリース時の構文詳細は公式ドキュメントをご確認ください。）

ポイントは次の3つです。

• CREATE PROPERTY GRAPHで、既存テーブルからグラフを定義できる（データ移行が不要）
• MATCHパターンで、関係の横断を直感的に記述できる
• SQL標準構文なので、既存のSQL資産・ツール・ドライバとそのまま連携できる

日本語圏でも検証が進んでいる

日本PostgreSQLユーザ会の資料でも、SQL/PGQはPostgreSQL 19の主要候補機能の筆頭として挙げられています。さらに、Amazon RDSのデータベースプレビュー環境でもPostgreSQL 19 Beta 1が利用可能で、SQL/PGQが実際に動作することが確認されています。本番導入前にマネージド環境で試したい場合も、検証の選択肢があるのは心強いところです。

ユースケース：不正検知・レコメンド・関係分析

SQL/PGQが効果を発揮する典型例は、次のような「関係の多段横断」が必要な場面です。

• 不正検知：複数の口座・端末・IPを経由してつながる不審な資金移動のパターン検出
• レコメンド：友人の購入履歴や閲覧履歴を辿ったレコメンデーション
• 関係分析：SNSでのつながり、サプライチェーンの依存関係の可視化

これらをPostgreSQL単体でカバーできるようになることで、グラフDBのためだけに別システムを運用していたチームにとっては、アーキテクチャを大きくシンプルにできる可能性があります。

非同期I/Oと性能向上はどのくらい変わる？——外部キー付きINSERT最大2倍の意味

PostgreSQL 18で導入された非同期I/Oサブシステム（io_uring対応を含む）は、PostgreSQLのI/O処理を根幹から変える大きな変更でした。PostgreSQL 19は、この基盤を継承・拡張し、その恩恵をより多くのワークロードで引き出せるようにしたバージョンです。

I/Oワーカーの自動スケール

PostgreSQL 19では、io_method=worker を選択した際のI/Oワーカー数が、新しい io_min_workers / io_max_workers 設定で自動スケールされるようになりました。従来は固定だったワーカー数を負荷に応じて調整できるため、I/Oがボトルネックになる環境でチューニングの負担が減ります。

外部キー付きINSERTで最大2倍

注目すべき具体効果として、外部キー制約付きのINSERTで最大2倍の性能向上が報告されています。外部キーの参照整合性チェックは、参照先テーブルへの参照（I/O）を伴うため、非同期I/Oの改善が直結しやすい領域です。大量データの投入やトランザクションの多いワークロードでは、体感できる差になる可能性があります。

プランナ・エグゼキュータの改善

I/O以外にも、クエリ実行系の改善が多数含まれています。

• eager aggregation：結合前の段階で積極的に集約を進める最適化
• アンチジョイン最適化：NOT EXISTS / NOT IN 系のクエリが高速化
• インクリメンタルソートの適用範囲拡大
• 並列シーケンシャルスキャンの読み取り高速化
• IS DISTINCT FROM の簡略化
• LISTEN/NOTIFY のスケーラビリティ向上

EXPLAIN ANALYZEでI/O統計を可視化

性能検証の観点で見逃せないのが、EXPLAIN ANALYZE ... IO で非同期I/Oの統計を可視化できるようになった点です。どのノードでどれだけのI/Oが発生し、どれだけ非同期で処理されたかを把握できるため、「非同期I/Oはうちのワークロードに効くのか」を実際のクエリで確認しやすくなりました。

PG18 → PG19の性能・I/O面の違いまとめ

なお、参考として、PostgreSQLへのio_uring統合は学術検証でも最大約14%の追加改善が報告されています（arXiv 2512.04859）。I/O革新は PostgreSQL 18→19→今後と続く流れであり、一度検証ノウハウを蓄積しておけば、次のバージョンでも役立てられるでしょう。

運用・開発者が得する新機能——REPACK、並列Autovacuum、ON CONFLICT DO SELECTなど

PostgreSQL 19には、SQL/PGQや性能改善のような目玉以外にも、日々の運用と開発を地味に楽にする改善が数多く含まれています。ここではDBA（運用者）向けと開発者向けに分けて紹介します。

DBA向け：VACUUM・メンテナンスの進化

REPACKコマンドの新設は、運用者にとって朗報です。長年親しまれてきた pg_repack 拡張の機能が本体に統合され、REPACK CONCURRENTLY によりブロッキングを最小限に抑えたテーブル再編成が可能になります。テーブルの肥大化対策でメンテナンスウィンドウに頭を悩ませてきたチームには特に価値が大きいでしょう。

Autovacuumの並列化も入ります。autovacuum_max_parallel_workers という新設定により、autovacuumが並列で動作するようになり、加えてautovacuumスコアリングによるテーブル優先度付けで「必要なテーブルから先にvacuum」が実現します。大きなテーブルのvacuumが後回しになって膨張する、といった問題への対処が期待できます。

さらに、クエリ中にページをvisible化して将来のvacuum作業を自動削減する新しいストラテジーも搭載されています。

開発者向け：SQL構文の進化

ON CONFLICT DO SELECT は地味ながら非常に嬉しい改善です。「レコードがあれば取得、なければ挿入」を INSERT ... ON CONFLICT DO SELECT ... RETURNING の1文で書けるようになり、従来の「ダミー更新」テクニックや不可視タプルの問題を排除できます。UPSERT系の実装がシンプルになります。

その他の注目ポイントです。

• 行パターン認識（Row Pattern Recognition）：時系列データのトレンド・パターン検出をSQL標準構文で記述可能に
• FOR PORTION OF の UPDATE/DELETE 対応：テンポラル（期間）データの一部期間だけを更新・削除できる（PG18のテンポラル制約を補完）
• ALTER TABLE ... MERGE PARTITIONS / SPLIT PARTITIONS：パーティションのインプレース再編成
• GROUP BY ALL：SELECT列挙に合わせたグループ化を簡潔に記述
• jsonpath関数の拡張：lower/upper/initcap/replace/split_part/trim系を追加
• WAIT FOR LSN：レプリカでLSNまで再生を待ってからSELECTすることで、read-your-writes（自分の書き込みが確実に読める）を実現
• DDL再生成関数（ロール/テーブルスペース/DBのDDL取得）、random()の日付・タイムスタンプ対応、PL/Pythonのイベントトリガー対応
• pg_plan_advice / pg_stash_advice 拡張によるプランナ意思決定の安定化・制御

レプリケーション・フェデレーション面

運用の垣根を下げる改善も進んでいます。

• シーケンス値の論理レプリケーション：これまでオンラインアップグレード時の頭痛の種だったシーケンス同期が簡素化
• サーバ再起動なしで論理レプリケーションを有効化：wal_level=replica のままで動的有効化（effective_wal_level 追加）
• CREATE PUBLICATION ... EXCEPT、CREATE SUBSCRIPTION ... SERVER（外部サーバー経由での資格情報管理）
• postgres_fdwの配列演算プッシュダウン、外部テーブル統計の利用

新機能×対象者×便利さ一覧

このように、PostgreSQL 19は「目玉機能」だけでなく、運用コストと開発の手間を下げる改善の密度が高いバージョンです。自チームの課題と照らし合わせて、GA前に試しておく項目を選ぶとよいでしょう。

PostgreSQL 18/19 主要新機能比較表

ここまで紹介してきた内容を、PostgreSQL 18との比較として機能カテゴリ別に整理します。「うちの環境ではどのカテゴリに恩恵があるか」をざっと見渡すためのチェック用テーブルとしてご利用ください。

見方のポイントを3つ挙げます。

1. 性能系は「18の土台＋19の伸び」：非同期I/OはPostgreSQL 18の導入であり、19はその上の自動化・最適化です。18を経由せず17以前からの移行組織は、効果が二重に大きくなります。
2. 運用系の改善が充実：REPACK・並列Autovacuum・チェックサムオンライン切替と、これまで外部ツールやメンテナンスウィンドウ頼みだった作業が本体機能化されています。
3. 非互換行は移行計画の起点：JIT無効化・lz4・RADIUS削除・MD5警告は、移行判断で必ず確認すべき項目です（次章で詳述）。

なお、マテリアライズドビューについては、開発コミットで部分リフレッシュ・IVM（リアルタイム更新マテビュー）が候補機能として挙げられていました（日本PostgreSQLユーザ会資料）。GAまでの間に含まれるかは、正式なリリースノートでの確認をおすすめします。

移行判断はどうステップを踏む？——非互換変更とチェックリスト

新機能は魅力的ですが、実務で大切なのは「移行時に何が壊れるか」の把握です。ここではPostgreSQL 19の非互換変更・既定値変更を整理し、移行判断のステップを提示します。

PostgreSQL 19の主な非互換・既定値変更

• JIT（Just-in-Time compilation）が既定で無効化：JITの性能効果に依存しているワークロードは影響を受ける可能性があります
• default_toast_compression が lz4 に変更：pglz前提での圧縮率・CPU負荷の比較をしていた環境は再検証が必要です
• RADIUS認証のサポート削除：RADIUS連携で認証を行っているシステムは代替手段への移行が必須です
• MD5パスワード警告：PG18で非推奨化されたmd5認証は、PG19では認証成功後にクライアントへ警告が送られるようになります（md5_password_warnings、警告期間は既定7日）。MD5の完全排除は今後のリリースで見込み
• vacuumdb --analyze-only が既定でパーティション親テーブルもANALYZE

移行判断の4ステップ

ステップ1：ベータ版でワークロード検証

Beta 1・Beta 2が公開中の今こそ検証のタイミングです。手元の環境でビルドしてもよいですし、Amazon RDSのデータベースプレビュー環境でもPostgreSQL 19 Beta 1（SQL/PGQ、REPACK、論理レプリケーション動的有効化が確認済み）を試せます。代表クエリの実行計画・性能・EXPLAIN ANALYZE ... IO の統計を取っておきましょう。

ステップ2：非互換項目の棚卸し

自組織の構成と下表を突き合わせます。特にRADIUS利用とMD5認証は「動かなくなる」系の変更のため、最優先で確認が必要です。

ステップ3：拡張・ドライバの互換確認

利用中の拡張機能やアプリケーションドライバがPostgreSQL 19で動作するかを確認します。ベータ期間中はプロトコル互換性の問題を洗い出す「grease mode」キャンペーンが実施されており、ベータでの検証結果がコミュニティ全体の互換性向上に還元されます。サードパーティ拡張はGA直後よりも少し落ち着いたタイミングでの対応が進む傾向もあるため、依存拡張のリリース状況は要チェックです。

ステップ4：本番移行計画の策定

pg_upgrade による就地アップグレードに加えて、PostgreSQL 19では論理レプリケーションの動的有効化（サーバ再起動なし、wal_level=replica のまま）やシーケンス値の論理レプリケーションにより、論理レプリケーション経由のオンライン移行が格段にやりやすくなっています。ダウンタイム要件に応じて手法を選定しましょう。

flowchart TD
    A[ステップ1: ベータ版でワークロード検証] --> B[ステップ2: 非互換項目の棚卸し]
    B --> C{RADIUS / MD5 / JIT / pglz 依存あり?}
    C -->|あり| D[代替手段・再検証の計画立案]
    C -->|なし| E[ステップ3: 拡張・ドライバの互換確認]
    D --> E
    E --> F{互換性の問題は解消?}
    F -->|いいえ| G[ベンダー・コミュニティに確認<br>GA後の対応を待つ]
    F -->|はい| H[ステップ4: 本番移行計画<br>pg_upgrade or 論理レプリケーション]
    G --> H

非互換項目×影響×対策チェックリスト

移行のハードル自体は、非互換項目を事前に潰しておけば決して高くありません。むしろ論理レプリケーションまわりの改善により、ダウンタイム最小の移行手段の選択肢が広がったことを評価すべきバージョンです。

よくある質問（FAQ）——PostgreSQL 19についてよく検索される疑問

PostgreSQL 19に関する代表的な疑問をQ&A形式でまとめました。

Q1: PostgreSQL 19の正式リリースはいつ？

A: 2026年9月〜10月頃の見込みです。 PostgreSQLは例年9月末〜10月初に年次リリース（Annual Release Cycle）を行っており、PostgreSQL 19もBeta 1（2026年6月4日）→ Beta 2（2026年7月中旬）→ 追加ベータ・RC（リリース候補）を経て正式版（GA）に至る見通しです。正確な日程は公式ニュースをご確認ください。

Q2: SQL/PGQの登場でNeo4jは不要になる？

A: ユースケース次第です。 SQL/PGQにより、不正検知・レコメンド・関係分析など、PostgreSQL上のデータに対するグラフクエリは単体で可能になります。既存データをRDBに持ち、グラフクエリが必要な場面が限定的なら、PostgreSQL一本化でアーキテクチャを簡素化できるでしょう。一方、超大規模グラフの深い横断やグラフ特化の運用機能に強く依存しているケースでは、グラフDBにしかない優位性も残ります。「即座に置き換え」ではなく、まず自チームのグラフワークロードをSQL/PGQで検証してみるのが現実的です。

Q3: PostgreSQL 18からアップグレードで壊れるものはある？

A: 主に4点に注意が必要です。

1. JITが既定で無効化（JIT性能に依存する重いクエリ）
2. TOAST圧縮の既定がlz4に変更（pglz前提の検証・容量設計）
3. RADIUS認証のサポート削除（利用中なら代替認証への移行が必須）
4. MD5パスワード警告（認証は動くが警告表示。SCRAM移行を推奨）

いずれも事前の棚卸しと設定・設計変更で対処可能です。詳細は前章のチェックリストをご参照ください。

Q4: PostgreSQL 19に今すぐ移行すべき？

A: 本番はGA（2026年9〜10月頃）を待つのが基本です。 ベータ版は本番利用を想定していません。ただし、「待つ」のではなく、ベータ期間中に検証を進めるのがおすすめです。判断基準としては、

• 非互換項目（RADIUS/MD5/JIT/pglz）の該当有無
• 依存拡張・ドライバの対応状況
• SQL/PGQやREPACKなど、獲得したい機能の優先度

を確認し、GA後すぐに移行できる準備を整えておくと、リリース直後のキャッチアップが楽になります。

Q5: ベータ版を試す方法は？

A: 主に2つの方法があります。 1つは公式サイトからベータ版のソース・パッケージをダウンロードして自前環境に構築する方法。もう1つはAmazon RDSのデータベースプレビュー環境でPostgreSQL 19 Beta 1を利用する方法です（SQL/PGQ、REPACK、論理レプリケーション動的有効化が確認済み）。マネージド環境で手軽に試したい場合はRDSプレビューが便利です。プレビュー環境のデータは本番に持ち込めない点にはご注意ください。

まとめ——PostgreSQL 19が示す方向性

PostgreSQL 19の新機能を移行判断の観点から読み解いてきました。Beta 1（2026年6月4日）→ Beta 2（2026年7月中旬）と着実に安定化が進んでおり、正式版（GA）は2026年9月〜10月頃の見込みです。本記事の内容を、PostgreSQL 19が示す3つの方向性として整理します。

1. リレーショナルDBとグラフDBの融合

SQL/PGQの搭載は、単なる新機能追加以上の意味を持ちます。CREATE PROPERTY GRAPHとMATCHパターンにより、既存テーブルの上にグラフ構造を重ねてクエリできるようになったことで、RDBとグラフDBの二重運用というアーキテクチャの複雑さを解消する道が開けました。不正検知・レコメンド・関係分析といった用途で、PostgreSQL一本化を検討する価値が十分にあります。行パターン認識と組み合わせれば、時系列×関係性の分析表現力も一段と上がるでしょう。

2. 性能は「I/O革新の続き」

PostgreSQL 18が導入した非同期I/O（io_uring対応含む）の基盤を継承・拡張し、io_min/max_workersによる自動スケール、外部キー付きINSERT最大2倍、eager aggregation、アンチジョイン最適化といった成果が積み上がりました。EXPLAIN ANALYZE ... IOによるI/O統計の可視化も、性能検証の質を高めます。I/Oの非同期化は今後のバージョンでも続き得る流れであり、検証ノウハウは長期資産になります。

3. 運用の垣根を下げる

REPACK CONCURRENTLY、並列Autovacuum、データチェックサムのオンライン切替、そして再起動なしの論理レプリケーション動的有効化とシーケンス複製——いずれも「これまで外部ツールやメンテナンスウィンドウに頼っていた作業を、本体機能で柔軟にする」改善です。アップグレードやメンテナンスのダウンタイムは着実に小さくなりつつあります。

GA後に再確認すべきポイント

正式リリース後は、次の点を再確認しましょう。

• 正式リリースノートでの最終機能構成（特にマテリアライズドビューの部分リフレッシュ・IVMの収録有無）
• 非互換項目の最終確認（JIT・lz4・RADIUS・MD5の対応状況）
• 依存拡張・ドライバのGA対応状況
• 移行手法の選択：pg_upgradeか、論理レプリケーション（動的有効化＋シーケンス複製）を活用したオンライン移行か

PostgreSQL 19は、目玉機能の華やかさだけでなく、運用と開発の現場に届く改善の密度という点でも充実したリリースになりそうです。ベータ期間中に検証を進めて、GA後の移行判断をスムーズにしましょう。

関連記事

• PostgreSQL 19 Betaで切り拓く次世代データベース：非同期I/O・OAuth認証・JIT無効化が変えるデータ基盤の未来
• DuckDB 2.0が切り開くデータ基盤の新潮流：QuackプロトコルとDuckLakeが変える「インプロセスOLAP」の未来
• SQLite-Vectorが切り拓くエッジAIのベクターサーチ：組み込みデータベースで実現するプライバシーファーストなセマンティック検索