Postgres 19の展望

コンテンツをスキップブログ/オープンソース/Postgres 19の展望2026年6月18日/10分読Open Source Postgres 19の展望 Craig Kerstiens Postgresの各リリースには個性があります。あるリリースは一つの大きな目玉機能が特徴です。あるリリースは長年の課題を解消することに重点を置いています。またあるリリースは、アップグレードするまで完全にその価値を理解できないものの、アップグレードすると日々のワークフローが少しスムーズになる、といった「ああ、いいね」という改善が満載です。もちろん、ほとんどすべてのリリースには、いくつかのパフォーマンス改善がちりばめられています。Postgres 19は、あらゆる要素が少しずつ含まれているリリースのように感じられます。REPACK CONCURRENTLYは、大規模な本番データベースにとって大きなQoL（生活の質）向上であり、組み込まれています。大物機能もあります、はい。SQLプロパティグラフクエリは多くの注目を集めるでしょう。論理レプリケーションはさらに完成度を高めています。そして、VACUUM、EXPLAIN、COPY、パーティショニング、監視、パフォーマンス、プランナーの動作における着実な改善が、Postgresを派手ではない方法で、しかし「これは本番システムを運用するのに役立つ」という非常に実用的な方法で、より良くし続けています。ベータ版であるため、GAまでに詳細は変更される可能性があります。しかし、Postgres 19がベータ版に入った今、何が提供され、より重要なこととして、それがPostgres上で構築および運用する人々にとって何を意味するのかを検討する良い時期です。 すぐに使えるREPACK Postgresを十分に長く運用していれば、テーブルの肥大化を解消したり、テーブルを書き換えたり、データを再編成したいと思ったが、VACUUM FULLやCLUSTERに伴うロックを取りたくない、という瞬間に遭遇したことがあるでしょう。この問題に対しては、長年、pg_repackをはじめとする拡張機能のエコシステムが存在していました。それだけでわかることがあります。ユーザーは真のニーズを抱え、エコシステムがそのギャップを埋めていたのです。Postgres 19は、REPACK CONCURRENTLYのサポートを含め、新しいREPACKコマンドをコアに取り込みます。REPACK CONCURRENTLYは、Postgresの本番ユーザーが、平均的なリリースノート読者が期待する以上に重要視する機能の一つになると私は予想しています。 パーティショニングがより実用的になる Postgresのパーティショニングは長年にわたって大きく改善されました。「これを行うことはできるが、多くの内部構造と注意点を理解する必要がある」という状態から、はるかに親しみやすいものになりました。Postgres 19はこの作業を継続し、パーティションのマージと分割のサポートを提供します。これは簡単そうに聞こえますが、実際的な運用上の問題を解決します。パーティショニング戦略は、多くの場合、不完全な情報に基づいて選択するものです。当時は意味のあるパーティショニングスキームで始めます。しかし、ワークロードが変化したり、保持期間が変化したり、データ量が予想以上に速く増加したりすることがあります。あるいは、いくつかのパーティションが不自然に大きくなり、他のパーティションは非常に小さいという状況になることもあります。パーティションを分割したりマージしたりできることで、時間の経過とともに設計を進化させる余地が広がります。 -- Q1とQ2を単一のパーティションに結合する ALTER TABLE customer_orders MERGE PARTITIONS (orders_2026_q1, orders_2026_q2) INTO orders_2026_h1; -- Q3パーティションを月単位に分割する ALTER TABLE customer_orders SPLIT PARTITION orders_2026_q3 INTO ( PARTITION orders_2026_07 FOR VALUES FROM ('2026-07-01') TO ('2026-07-01'), PARTITION orders_2026_08 FOR VALUES FROM ('2026-08-01') TO ('2026-08-01'), PARTITION orders_2026_09 FOR VALUES FROM ('2026-09-01') TO ('2026-09-01') ); このような機能は重要です。なぜなら、最良のデータベース設計はめったに静的ではないからです。優れたシステムは進化します。Postgresが、すべてを一から再構築することなく調整する方法をより多く提供することは、Postgresを長期的に運用しやすくするための、まさに漸進的な改善です。 論理レプリケーションが成熟し続ける 論理レプリケーションは、過去数回のPostgresリリースにおいて、Postgres開発の最も重要な領域の1つでした。これは、マイグレーション、アップグレード、レポートシステム、データ移動、選択的レプリケーション、そしてますます高可用性と運用ワークフローに役立っています。Postgres 19は、いくつかの重要な点で論理レプリケーションを完成させ続けています。最大の点は、シーケンス値が同期されるようになり、サブスクライバーがパブリッシャーにうまく一致するようになったことです。シーケンスに依存するアプリケーションテーブルで論理レプリケーションを扱ったことがある人なら、これがなぜ重要かを知っているでしょう。シーケンスの状態なしでデータをレプリケートすると、切り替え後に厄介な問題が発生する可能性があります。データは移動しましたが、次に生成されるIDが必要な場所にない場合があります。Postgres 19は、パブリケーションのALL SEQUENCESサポート、シーケンス同期エラー報告、およびシーケンス周りのサブスクリプションリフレッシュ動作の改善も追加します。もう1つの良い改善点として、パブリケーションがALL TABLESをパブリッシュする際に、一部のテーブルを除外するためにEXCEPT句を使用できるようになりました。これは、人々が実際にシステムを運用する方法に合致します。多くの場合、「基本的にすべて、ただしこれら数点を除く」ということを望みます。それを容易にすることは良いことです。そして、wal_level = replicaが、必要に応じて論理レプリケーションを自動的に有効にする機能と、実際に何が起こっているかを報告する新しいeffective_wal_levelがあります。これはもう1つの実用的な改善です。Postgresがあなたのために何かをしているときに、設定上の落とし穴が減り、可視性が向上します。論理レプリケーションにはまだ微妙なニュアンスがあります。それは常にそうでしょう。しかし、すべてのリリースがそれを特殊な機能というよりも、通常のPostgres運用ツールキットの一部のように感じさせます。 Autovacuumがより賢く、見やすくなる Vacuumは最もPostgresらしいことの一つです。何年もPostgresを使っても内部に気を配らないことができます。しかし、ある日テーブルの肥大化が進み、ラップアラウンド警告が表示されたり、クエリのパフォーマンスが変化したりすると、突然あなたは非常に気にするようになります。Postgres 19には、ここでいくつかの改善があり、特筆に値します。Autovacuumは、グローバルおよびテーブルごとに制御される並列バキュームワーカーを使用できるようになりました。大規模なテーブルやインデックスの場合、これによりPostgresはメンテナンス作業に追いつく能力が向上します。 -- autovacuumプロセスでグローバルに最大4つの並列ワーカーを許可する ALTER SYSTEM SET autovacuum_max_parallel_workers = 4; また、テーブルが自動バキュームされる順序を制御する新しいスコアリングシステムもあります。これは、自動バキュームが常にトレードオフを行っているため重要です。どのテーブルが最も緊急か？次にどれに進むべきか？この優先順位付けをより賢くすることで、Postgresユーザーが助けを必要とするまさにその場所、つまりインシデントになる前にシステムを健全に保つことに役立ちます。 -- このテーブルのみ優先順位スコアリングを調整する： -- 挿入ベースのバキュームに非常に高い緊急度ブースト（3.0）を与え、 -- 行がめったに削除されないため、通常の更新/削除バキューム緊急度（0.5）を下げる。 ALTER TABLE application_logs SET ( autovacuum_vacuum_insert_score_weight = 3.0, autovacuum_vacuum_score_weight = 0.5 ); 新しいpg_stat_autovacuum_scoresビューは、その意思決定に対するより高い可視性を提供します。vacuumおよびanalyzeの進捗ビュー、VACUUM VERBOSEとautovacuumログのメモリ使用量と並列処理の詳細、そして個別のlog_autoanalyze_min_durationが追加され、Postgres 19はメンテナンスをより観測可能にしようとしているリリースだと感じられます。これは常に私が喜んで見るテーマです。データベースがバックグラウンドで作業を行うのは良いことです。データベースがその作業をより良く説明するのはさらに良いことです。 SQLプロパティグラフクエリがPostgresに登場 さて、より興味深い追加機能の1つとして、SQL/PGQ、つまりSQLプロパティグラフクエリがあります。グラフデータベースは長年にわたってその瞬間を迎えてきました。そして明確にするために言えば、頂点とエッジの観点から考えることが有用なモデルとなるワークロードは確かに存在します。不正検出、レコメンデーション、ネットワーク分析、権限グラフ、サプライチェーン、組織図、その他多数です。 -- サンプルプロパティグラフ CREATE PROPERTY GRAPH store_graph VERTEX TABLES ( customers LABEL customer, orders LABEL "order" ) EDGE TABLES ( customer_orders SOURCE customers DESTINATION orders LABEL placed_order ); しかし、Postgresにこれが導入されたことについて私が気に入っているのは、リレーショナルモデルを捨て去ることを求めていない点です。これは、Postgresがすでに持っているデータをクエリする別の方法を追加しているということです。これは非常にPostgres的です。