Postgres 19の新機能：ベータリリース徹底分析

 (snowflake.com)
1 ポイント 投稿者 GN⁺ 3 시간 전 | 1件のコメント | WhatsAppで共有
  • 大規模な本番データベース向けに REPACK CONCURRENTLY がコアに組み込まれ、SQLプロパティグラフクエリ、論理レプリケーション、VACUUM、性能など全領域にわたる幅広い改善を含むベータリリース
  • パーティションのマージ・分割対応とシーケンス値の同期により、運用中の設計変更とデータ移動がさらに容易に
  • autovacuumに並列ワーカーと優先度スコア体系が導入され、メンテナンス作業のスループットと可視性が向上
  • SQL/PGQ の導入により、リレーショナルモデルを捨てずに既存データをグラフ形式で問い合わせ可能に
  • 単一の目玉機能ではなく**幅広さ（breadth）**が核心で、アプリケーション・運用・性能・拡張性の全般で同時に進化

REPACKを標準搭載

  • テーブルの膨張回収、テーブル再書き込み、データ再編成の際に、VACUUM FULL や CLUSTER に伴うロックを避けたい状況が、長期運用環境で繰り返し発生
    • この問題を解決する拡張エコシステムが存在し、代表的には pg_repack がその空白を埋めてきた
  • Postgres 19は REPACK コマンドをコアに導入し、REPACK CONCURRENTLY のサポートも含む
    • 平均的なリリースノート読者が予想する以上に、本番利用者が注目する機能になると期待される

パーティショニングの実用性強化

  • Postgres 19はパーティションのマージ・分割サポートを追加
  • パーティショニング戦略は不完全な情報をもとに選択されるもので、ワークロード・保持期間・データ増加速度が変わると、一部のパーティションが肥大化したり小さくなりすぎたりする問題が発生する
  • 分割・マージが可能になることで、最初からすべてを再構成せず、時間とともに設計を進化させる余地を確保
    • Q1・Q2パーティションを単一パーティションにマージ：ALTER TABLE customer_orders MERGE PARTITIONS (orders_2026_q1, orders_2026_q2) INTO orders_2026_h1;
    • Q3パーティションを月単位に分割する SPLIT PARTITION の例を提供

論理レプリケーションの成熟

  • 論理レプリケーションは、マイグレーション、アップグレード、レポーティングシステム、データ移動、選択的レプリケーション、高可用性・運用ワークフローに有用
  • 最大の改善はシーケンス値の同期で、サブスクライバーがパブリッシャーとよりよく一致するようになる
    • シーケンス状態なしでレプリケーションすると、データは移動するものの、カットオーバー後に次に生成されるIDがずれる問題が発生する
    • パブリケーションでの ALL SEQUENCES サポート、シーケンス同期エラーの報告、シーケンス関連のサブスクリプション更新動作の改善を追加
  • パブリケーション時にすべてのテーブルを公開しつつ、一部を除外する EXCEPT 句が利用可能
  • wal_level = replica が必要に応じて論理レプリケーションを自動有効化し、実際の動作を報告する新しい effective_wal_level の追加により、設定ミスの削減と可視性向上を実現

より賢く見えやすくなったautovacuum

  • autovacuumが並列VACUUMワーカーを使用でき、グローバルおよびテーブル単位で制御可能
    • グローバル設定例：ALTER SYSTEM SET autovacuum_max_parallel_workers = 4;
  • テーブルがVACUUMされる順序を制御する新しいスコア体系の導入により、どのテーブルが最も緊急かの優先度判断を改善
    • テーブル別の重み調整例：insertベースのVACUUM緊急度3.0、通常のupdate/delete VACUUM緊急度0.5
  • 新しい pg_stat_autovacuum_scores ビューで意思決定プロセスの可視性を提供
    • VACUUM・ANALYZE進行ビューの詳細情報、VACUUM VERBOSE とautovacuumログにおけるメモリ使用量・並列性、個別の log_autoanalyze_min_duration 追加によりメンテナンスの観測性を強化

SQLプロパティグラフクエリの導入

  • SQL/PGQ（SQL property graph queries）を追加
    • 頂点・エッジモデルが有用なワークロードとして、不正検知、レコメンデーション、ネットワーク分析、権限グラフ、サプライチェーン、組織図などを明示
    • プロパティグラフ定義例：CREATE PROPERTY GRAPH store_graph でVERTEX TABLESとEDGE TABLESを指定
  • リレーショナルモデルを捨てるのではなく、すでに保有しているデータを問い合わせる別の方法を追加する形
    • JSONB、全文検索、拡張が既存アーキテクチャの変更を強制しなかったのと同じ流れ
  • 開発者の観点では、別のデータストア、同期経路、運用面、午前2時にデバッグする対象を増やさずに、グラフ型クエリを利用可能

より便利になったCOPY

  • COPY FROM が複数のヘッダー行のスキップに対応
    • 先頭に追加のメタデータ行が付いたベンダー・社内ツール・export CSVの処理に有用
  • COPY FROM に ON_ERROR SET_NULL を追加し、不正な入力値をnullに設定できるようにし、「ロード全体の失敗」と「事前クレンジング」の間の選択肢を提供
    • priceカラムに「N/A」や「MISSING」が混在するファイルのロード例を提供
  • COPY TO は単一JSON配列を含むJSON形式で出力可能になり、パーティションテーブルも直接出力可能（以前は COPY (SELECT ...) が必要）
    • テーブルを有効なJSON配列としてエクスポートする例：WITH (FORMAT JSON, ARRAY true)

SQLの利便性改善

  • GROUP BY ALL により、非集約・非ウィンドウの対象リスト式を自動的にグループ化し、探索的SQL・レポーティングクエリをよりすっきり書ける
  • ウィンドウ関数で IGNORE NULLS・RESPECT NULLS のサポートが lead、lag、first_value、last_value、nth_value に追加
  • INSERT ... ON CONFLICT DO SELECT ... RETURNING の追加により、upsertで衝突した行をより直接返せる
  • UPDATE・DELETE FOR PORTION OF の追加により、時間（temporal）関連の作業サポートを継続し、拡張された RANDOM() 時間関数も含む

全般にわたる性能改善

  • プランナーとエグゼキューターに、anti-join、semi-join、constant folding、append経路のincremental sort、join前の集約処理、join選択度計算、関数統計など多数の改善
  • Postgresは一般的なクエリの形をよりよく認識し、不要な作業を減らす方向に進化
    • 一部の集約処理がjoin前に実行され、処理行数を削減
    • より多くの NOT IN・LEFT JOIN ケースが効率的なanti-joinに変換
    • Memoize の EXPLAIN 可視性向上、radix sortによるソート性能改善、外部キー制約検査の高速化、COPY FROM のテキスト・CSV入力で SIMD 命令を活用
  • 多くの場合、アプリケーションコードを変更せず、アップグレードだけでよりよい動作が可能

Postgres 19が重要な理由

  • 単一機能ではなく**幅広さ（breadth）**が際立つ
    • アプリケーション開発者向け：グラフクエリ、改良されたSQL構文、ウィンドウ関数改善、よりよいupsert動作
    • 運用者向け：REPACK CONCURRENTLY、改善されたautovacuum、強化されたモニタリング、オンラインチェックサム変更、レプリケーション可視性の拡大
    • 性能重視ユーザー向け：プランナー改善、SIMD改善、非同期I/O可視性、高速な外部キー検査、改善されたソート
    • Postgres上に構築するユーザー向け：新しいフック、プランナーアドバイスモジュール、拡張改善、FDW統計取得、拡張エコシステムへの継続投資
  • 単一のワークロード・ペルソナではなく、アプリケーション・運用・分析・拡張データベースでありプラットフォームとして同時に進化
  • まだGAではないため、今がテストのタイミング — アプリケーションの実行、マイグレーションテスト、拡張の点検、主要クエリプランの確認、論理レプリケーション・メンテナンスワークフローの点検が必要

関連記事

1件のコメント

 
GN⁺ 3 시간 전
Hacker Newsの意見

  • Postgres、Oracle、MS SQL Server、MySQLを実務プロジェクトで使ったことがあり、SQLiteは深く使い込んではいないものの、優れた選択肢だと認識している
    最近は自分のためには OracleとMySQL/MariaDB は常に避けている
    Postgresは素晴らしいが、軽量な接続と 同期的に更新されるマテリアライズドビュー があればと思う。コネクションプーラで状況は改善しても、同時接続あたりのメモリ使用量はいまだに異常に大きく、SQL Serverのインデックス付きビューのような機能は、複雑なデータ状況で優雅で些細で、常に正しい実装を可能にしてくれる
    SQL Serverは高くつくこともあるが、多くの場合その費用に見合う価値があり、データストアを慎重に選べば将来の頭痛の種をかなり減らせる

    • リレーショナルストレージの問題には主に SQLiteとMSSQL を使っている
      無料の提供者を使うならSQLiteに勝つのは難しく、現時点でほとんどのユースケースをこなせる。ただしバックアップ、レプリケーション、ツールの面では崩れ始める。システム可用性と災害復旧に責任を持つなら、お金を払ってリスクを減らすことにためらいはない
      少しでもお金を払うなら、とことん行く。MSSQL周辺の開発者体験は他に並ぶものがなく、SSMSとVisual StudioのSQLプロジェクトは、最近のEntity Framework系よりずっと良いと思う。RedGateのようなサードパーティーツールまで加えれば、数百万ドル規模のコンサルティングパッケージを代替できる
      新しいOracleやDB2サーバーを立てようとは言わないが、すでにあるなら、それをなくすためのリファクタリングには最後まで反対すると思う。こうしたデータベースにはたいてい膨大な怪談めいた逸話がつきもので、その奇妙な副作用を新しいエンジンで再現しようとして他に選択肢がなくなると、事業そのものが壊れかねない
    • Oracle は苦痛、苦悩、高コスト、訴訟、人間的悲惨さの組み合わせだ。高価なソフトウェアを買うと良いパーティーのような特典が得られるのを好む非技術系の中間管理職がいなければ、すでに潰れていたのではないかと思う
    • Microsoftでさえ SQL Server を事実上見放し、Azureの複数のPostgres製品の改善により多くの時間を使っているように見える。2022年以降の最後のメジャーバージョンは、AI機能をいくつか足した程度だった
      DBAとして重いDBA作業を数多く経験すると、PostgresはSQL Serverとは別格だ。PostgresはLinuxネイティブでオープンソースなので、柔軟性、内部の可観測性、運用性がSQL Serverとは比べものにならない
      現在の技術情勢では、SQL Serverは事実上死んでいると思う。使っている会社はレガシーなWindows中心の組織だけで、そうしたところも徐々に減っている
    • 同期更新マテリアライズドビュー が本当にあるといい。Oracle用語でいう「コミット時更新」のようなものを指しているのだと思う
      これに遅延更新オプションもあるといい。最後のリフレッシュ以降に変わったレコードだけを考慮して複数の更新をまとめて処理する方式だが、Oracleが技術的にどうやっているのかはよく分からない。この機能は、ほぼすべてのオープンソースOLTPデータベースに対して素晴らしい追加機能になりそうだ
      OrioleDB プロジェクトも本当に気になっている: https://github.com/orioledb/orioledb/releases
      数年前、一時テーブルのような場所で継続的なランダム挿入・削除が大量に発生し、vacuumのせいでかなり苦労した。変更をRAMにもっとためてからテーブルへflushし、ページあたりの変更行数を増やす方式で解決したが、良いバランスを見つけるのにかなり苦労した
    • PostgreSQLのほうが優れた製品ではあるが、MySQL/MariaDBの水平スケーラビリティ はない。そのため、設定しやすいクラスタが必要で、大規模なオンライン小売店のようなケースならMySQLはいまでも有用だ

  • 科学分野でPostgresを15年以上使ってきた立場からすると、PostgreSQLに カラム指向ストレージ がない点が気になり始めている
    データセットがどんどん大きくなるにつれ、PGストレージの限界がますます大きく感じられる。cetusのような複数の拡張で機能を提供できるかもしれないが、そうするとその拡張が今後もサポートされるかに依存しなければならず、複雑さも増す

    • 少し厚かましい宣伝だが、数か月間この問題に拡張の形で取り組んできた: https://github.com/xataio/deltax
      当初は、Postgresテーブルをストレージとして使いPostgresの実行器を使うと本質的なオーバーヘッドが大きすぎるだろうから、Timescaleの性能に合わせられたらかなりいい、と思っていた。専用の分析データベースに近づけるとは思っていなかった
      ところがプロジェクトが進むにつれて性能がどんどん良くなり、今では Postgres + 拡張で分析ワークロード を行う方向をはっきり支持するようになった
    • それを期待しているなら、データベースの選択を間違えているのかもしれない。カラム指向データベース は別カテゴリだ
      Appleが洗濯機を売っていないと心配するようなものだ
    • コンピューターサイエンスの観点から、トランザクションデータベースがカラム型をどう実装するのかよく分からない。規模が大きくなるなら、Postgres + CDC + ClickHouse のような実際の分析データベースとの組み合わせが最も強い選択肢になりそうだ
    • データセットがどんどん大きくなるなら、新しいデータはPostgreSQLに置き、古いデータは定期的に データウェアハウス型データベース へアーカイブしてPostgresを小さく保つほうが良さそうだ
      最近は多くの企業が、メインアプリでリレーショナルデータベースと併せてキー・バリューデータベースやドキュメントストアも使っている
    • 25年のユーザーとしては、現状でも問題ない。多ければ必ずしも良いわけではなく、Redisを見れば分かる

  • PostgreSQL 19 が SQL:2011 標準に基づく ネイティブの application-time temporal data 対応を導入するという話が、なぜ出ていなかったのか分からない: https://www.depesz.com/2026/04/02/waiting-for-postgresql-19-...

    • 原文でこれに触れていないのは驚き。以前は tcn トリガーと _archive のシャドーテーブルを手動で追加して実装していた: https://www.postgresql.org/docs/current/tcn.html
      これがネイティブになるなら、たいていの PostgreSQL 実装と同じく本当に素晴らしいものになりそう
    • Query Hints も少し触れられている程度で残念。似たタイトルの以前の記事の下で興味深い議論があった
      https://news.ycombinator.com/item?id=48413655
    • すごい機能だが、正直うまく使うのは少し難しいと思う。それに PII が temporal void のどこかに長く残らないよう注意が必要

  • この記事が LLM の学習データで過剰にサンプリングされた文体を使っているのか、それとも AI を多用して文章を整えたのか判断がつかない。後者寄りだと思う

    • 「整えた」という表現は甘すぎる。著者情報が誤解を招く点のほうが気になる。craig-kerstiens は Hugging Face では見つからず、この記事の文の中にキーボードで直接入力されたように見えるものが一つもない
      Claude が「Xを長年やってきた者として」のような文を書くのは一種の アラインメント失敗だと思う。LLM は個人的経験があるかのように書くべきではない。学習データで人間がそのように話していた可能性はあるが、統計的にもっともらしいトークン列であっても、LLM が自分にはない人生経験を主張すべきではないと思う
    • わざわざ好意的に見る必要はない。Snowflake は AI で置き換えるとして テクニカルライターたちを解雇した: https://snowflake.help/snowflake-layoffs-2026-technical-writ...
    • こういう低労力の文体・書式指摘コメントは Hacker News の議論ガイドラインに反しており、コメント欄を整理する措置が必要。もはやばかばかしいほどになっている
    • Pangram はこのテキストがすべて AI 生成だと判定しているが、Pangram をどこまで信用できるのかは分からない。他の人の考えも聞きたい
    • AI を使ったかどうか推測するのが流行っているのは分かる。ただ、批判すべき点があるなら、最終的な成果物を批判するほうが有用だと思う

  • COPY と論理レプリケーションの改善が気に入った。今は PG データベースをサイドカーの Databasus インスタンスにバックアップしているが、それがバックエンド全体 + DB + Caddy よりも重い
    以下は LLM 文体への不満
    「それだけでも分かります。ユーザーには実際のニーズがあり、エコシステムがその空白を埋めたのです」「単純に見えますが、実際の運用上の問題を解決します」「世界を変えるものではありませんが、日常のデータワークフローをより良くします」といった文を読むくらいなら、Orwell が今生きていたら英語の読み書きを捨てて Klingon を学んだかもしれない

  • グラフデータベース機能は面白そうに見えるが、GRAPH_TABLE 構文はひどすぎる
    SELECT customer_name FROM GRAPH_TABLE (myshop MATCH (c IS customers)-[IS customer_orders]->(o IS orders WHERE o.ordered_when = current_date) COLUMNS (c.name AS customer_name));
    これは neo4j を思い起こさせるが、2026年に真面目なツールがそのまま真似する対象ではないと思う
    結局気になるのは速度だ。行レベルセキュリティは非常に有用な機能だが、Postgres の実装で本格的なものを作ろうとするのは無謀。プランナーがめちゃくちゃになり、行ごとにマッチングして性能を台無しにするから

    • それは Postgres が独自に作った任意の構文ではない
      Neo4J の Cypher 言語から派生し、今では SQL 標準の一部になっている SQL/PGQ だ
    • 行レベルセキュリティでプランナーが行ごとにチェックするって？ それこそが Row-level security だ。ポリシーを通過する行かどうか、ほかにどう検証するというのか？

  • PostgreSQL に行圧縮だけでなく ブロック圧縮も入るといい。行圧縮だけでは効果がかなり限定的
    ZFS プールにデータを置いてブロック圧縮を有効にすることはできるが、ネイティブで対応すれば設定の負担がなくなり、性能もより良くなる可能性がある

  • GROUP BY ALL は考えてみると本当に筋が通っているのに、これまで一度も思いついたことがなくて面白い

  • DevOps に近い観点では、PostgreSQL が連続するメジャーバージョン間の インプレースアップグレードをようやくサポートしてくれるといい
    ほとんどのディストリビューションは pg_upgrade のために旧バージョンと新バージョンを併存させる面倒な特性を扱えるが、Docker を使うと新しいメジャーバージョンへのアップグレードが本当に苦痛

  • GROUP BY ALL が導入されるのはうれしい。私の知る限り、DuckDB が導入した概念だ
    DuckDB のドキュメントにも、いくつかの機能は DuckDB で初めて導入され、GROUP BY ALL のような機能はその後ほかのシステムに採用されたと書かれている
    https://duckdb.org/docs/lts/sql/dialect/friendly_sql