世界を動かす技術を、日本語で。

Postgres 19の展望

2026年6月30日原文(snowflake.com)

概要

  • Postgres 19 は多彩な新機能と改善を含むリリース
  • REPACK CONCURRENTLY など運用性向上のための機能がコアに追加
  • パーティショニングや論理レプリケーション の実用性がさらに進化
  • SQL/PGQ(プロパティグラフクエリ) など新しいクエリ機能の搭載
  • パフォーマンスとメンテナンス性 の全体的な向上

Postgres 19の特徴と全体像

  • Postgres 19 は「多様な改善が詰まった」リリース
    • 大規模な新機能、運用性向上、細かなQoL改善がバランス良く含まれる
  • REPACK CONCURRENTLY のコア組み込み
    • テーブルバルクの解消やデータ再編成の際、従来必要だったロックを回避
    • 以前は pg_repack 等の外部拡張に頼っていた課題の解決
    • 大規模本番DB運用者にとって大きな恩恵

パーティショニングの実用性向上

  • パーティションの結合・分割 がサポートされる
    • 運用中に設計変更やデータ量の変動へ柔軟に対応可能
    • 例: Q1とQ2パーティションの結合、Q3パーティションの分割
  • 設計の進化性 を担保し、全再構築不要で運用継続が容易に

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

  • シーケンス値の同期 が可能に
    • レプリケーション後のID不整合問題を解消
  • ALL SEQUENCES対応EXCEPT句 による柔軟な公開範囲指定
  • wal_level の自動設定と effective_wal_level による動作可視化
  • 運用ツールキットの一部 としての論理レプリケーションの進化

Autovacuum(自動バキューム)の強化と可視化

  • 並列バキュームワーカー の導入
    • 大規模テーブルのメンテナンス効率向上
  • テーブルごとの優先度スコア 設定による賢い順序制御
  • pg_stat_autovacuum_scores ビュー等で意思決定過程の可視化
  • メンテナンス作業の透明性 と運用性の向上

SQL/PGQ(プロパティグラフクエリ)の追加

  • SQL/PGQ により、リレーショナルデータのままグラフ的な探索が可能
    • 顧客-注文などの関係をグラフ形式で定義・クエリ可能
  • 既存データモデルを壊さず 新しい分析手法を追加
  • 新たなデータストアや運用負担の増加無し で複雑な分析ニーズに対応

COPYコマンドの改善

  • COPY FROM で複数ヘッダー行のスキップや ON_ERROR SET_NULL 対応
    • 外部CSV等の不整形データも柔軟に取り込み可能
  • COPY TO でJSON形式・配列出力やパーティションテーブルの直接エクスポート
  • 日常的なデータ連携・移行作業の効率化

SQLのQoL(Quality of Life)向上

  • GROUP BY ALL による自動グルーピング
  • ウィンドウ関数のNULL制御(IGNORE/RESPECT NULLS) 対応
  • INSERT ... ON CONFLICT DO SELECT ... RETURNING による柔軟なアップサート
  • UPDATE/DELETE FOR PORTION OF など時系列データへの対応強化

パフォーマンスの全体的な向上

  • プランナー/エグゼキュータの最適化 (アンチジョイン・セミジョイン・定数畳み込み等)
  • インクリメンタルソート・集約処理・関数統計 など多方面での高速化
  • SnowflakeのTom Lane らによる貢献

まとめ

  • Postgres 19 は運用者・開発者双方にとって「日々の困りごと」を着実に解消するリリース
  • 大規模本番DBの運用性向上新しい分析手法への対応 が両立
  • 地味だが確実な進歩 が、Postgresを長期運用する上での安心感に直結

Hackerたちの意見

PostgreSQL 19がSQL:2011標準に基づいたネイティブなアプリケーション時間の時系列データサポートを導入するって話、聞いたことある? https://www.depesz.com/2026/04/02/waiting-for-postgresql-19-...

クエリヒントについての言及があったけど、似たようなタイトルの投稿の下で面白い議論があったよ。 https://news.ycombinator.com/item?id=48413655

すごい。OPでこれが言及されなかったのが信じられない。俺はtcnトリガーを使って、"_archive"というシャドウテーブルを手動で追加してやってたけど、ネイティブでできるのはほとんどのPostgreSQLの実装にとって素晴らしいことになるね。

いい機能だけど、正直言ってうまく使うのはちょっと難しいと思う。あと、PIIがどこかの時間の空白に長いこと残ってるのには気をつけてね :-)

この人の書き方が、LLMのトレーニングで過剰に代表されてるスタイルなのか、AIを使って文章を整えたのか、どっちか決められないな。後者の方に傾いてるけど。

AIが使われたかどうかを議論するのが流行ってるのはわかるけど、もっと有益なのは、最終的な成果物に対して批判的になることだと思う。批判があるならね。

Pangramはこのテキストが完全にAI生成だって言ってるけど、Pangramがどれだけ信頼できるかはわからないな。(他の人の意見も聞いてみたい。)

スタイルやフォーマットについての低レベルなコメントが続いてるのは、Hackernewsのディスカッションガイドラインに反してるし、コメント欄をきれいにするために何かしないといけないね。もうおかしなことになってる。

「整える」って表現はちょっと甘すぎるな。著者情報が誤解を招くのがもっとイライラする。craig-kerstiensはHuggingfaceにいないし、この記事のどの文もキーボードで打たれたようには見えない。Claudeが「Xをやってきた人として」とか書くと、これも一種の整合性の失敗だと思う。LLMは個人的な経験があるかのように書くべきじゃない。トレーニングデータの中で誰かが言いそうなことだけど、LLMは持っていない人生経験を主張すべきじゃないと思う。たとえそれが統計的にありそうなトークンの並びでも。

優しさはいらないよ、SnowflakeはAIを理由に技術ライターを解雇したんだから。 https://snowflake.help/snowflake-layoffs-2026-technical-writ...

真剣なプロジェクトでPostgres、Oracle、MsSql Server、MySqlを使ったことあるけど、Sqliteにはあまり詳しくないな。すごいプレイヤーだって知ってるけど。最近は自分のためにOracleとMySql/MariaDBは避けるようにしてる。Postgresは素晴らしいし、私が欲しいと思う二つの大きな機能は、1. 軽量な接続;接続バウンサーで少し改善されるけど、同時接続ごとのメモリ使用量が異常に高い。2. 同期的に更新されるマテリアライズドビュー(Sql Serverではインデックス付きビューと呼ばれる)。これは複雑なデータ状況で素晴らしいツールだよ。あるプロジェクトが複雑な技術的実装に苦しんでるのを見たけど、インデックス付きビューがあれば優雅で簡単、しかも常に正確にできたはず。Sql Serverはコストがかかるけど、多くの場合、その提供するメリットはコストに見合う価値がある。データストアを慎重に選ぶことで、将来のトラブルをたくさん防げるよ。

SQL Serverのインデックス付きビューが輝く例を教えてくれない?俺の目には、OLTPシステムでは高いパフォーマンスオーバーヘッドがかかるトリガーと似ていて、開発者からは敬遠されてると思う。OLAPシステムではカスタムETLコードの方がパフォーマンスが良さそうだね。

Hacker Newsで議論の続きを見る