PostgreSQL 17: 地味だが確実な進化
PostgreSQL 17は2024年9月リリースだが、KGAの本番環境への適用は2025年に入ってからだ。メジャーバージョンアップはリスクが大きいため、半年以上のバグフィックスリリースを待ってから移行するのがKGAのポリシーだ。PG17.2で十分に安定したと判断し、2025年3月に移行を実施した。
JSON_TABLE: SQLでJSONを表形式に展開
PG17の目玉機能の一つがJSON_TABLEだ。JSONデータをSQLのFROM句で直接テーブルとして扱える。これまでjsonb_to_recordsetやjsonb_array_elementsを組み合わせて複雑なクエリを書いていた処理が、標準SQL構文で簡潔に書けるようになった。
例えば、APIレスポンスをJSONBカラムに格納しているログテーブルから、ネストされたデータを抽出するクエリが劇的にシンプルになる。KGAの監視システムでは、JSON形式のメトリクスデータを集計するクエリのコード量が平均40%削減された。パフォーマンスも改善しており、同等のjsonb_to_recordsetクエリと比較して実行時間が15-25%短縮された。
インクリメンタルバックアップ
pg_basebackupでインクリメンタルバックアップがネイティブサポートされた。これまでpgBackRestやBarmanなどのサードパーティツールに頼っていた差分バックアップが、標準ツールで可能になる。
KGAの500GBのデータベースでの実測では、フルバックアップに45分かかっていたものが、インクリメンタルバックアップで平均8分に短縮された。バックアップストレージも1週間分のフル7個（3.5TB）から、フル1個+差分6個（700GB）に削減できた。ただし現時点ではpg_combinebackupで結合する必要があり、リストア手順がやや複雑になる点は注意が必要だ。
MERGE文の強化
PG15で導入されたMERGE文がPG17で強化され、RETURNING句のサポートとDOアクションの追加が行われた。UPSERT（INSERT ON CONFLICT）で対処していた処理の多くが、よりSQLらしいMERGE文で書けるようになった。
特にRETURNING句は、マージ処理の結果（INSERT/UPDATE/DELETEのどのアクションが実行されたか）を取得できるため、アプリケーション側のロジックが簡素化される。KGAのデータ同期バッチ処理では、MERGE ... RETURNINGで処理結果を直接取得し、後続の処理に渡すパイプラインを構築した。
パフォーマンス改善の実測
PG17ではVACUUMの改善が顕著だ。内部的なデータ構造の最適化により、大きなテーブルのVACUUM処理が最大20倍高速化されるケースがある。KGAの1億行テーブルでは、VACUUM FULLの所要時間が3時間から35分に短縮された。
B-treeインデックスのスキャン性能も改善された。特にIN句やANY配列を使うクエリで効果が大きく、KGAのベンチマークでは該当クエリの実行時間が10-30%改善した。
パラレルクエリの最適化も進み、hash joinのパラレル実行が改善された。work_memの適切な設定と組み合わせることで、大規模な結合クエリで30-50%の速度向上を確認した。
PG16からの移行手順
KGAの移行手順を記録する。Step 1: PG17をパラレルインストール（ポート5433）。Step 2: pg_upgradeで--checkオプションによる互換性確認。Step 3: 拡張機能の互換性確認（pgvector 0.7.xはPG17対応済み、PostGIS 3.4もOK）。Step 4: レプリカを先に移行し、1週間の動作確認。Step 5: 計画ダウンタイム（30分）でプライマリをpg_upgradeで移行。Step 6: ANALYZE実行で統計情報の再収集。Step 7: 1週間の集中監視。
実際に遭遇した問題は2つ。一つはpg_stat_statementsの統計情報がリセットされること（想定内だが、チームへの事前周知が必要）。もう一つは、特定のPL/pgSQL関数でinline最適化の動作が変わり、一部のストアドプロシージャの実行計画が変化したこと。これはfunction volatilityの明示的設定で解決した。
今後の展望
PG18のベータでは論理レプリケーションの大幅な改善が予告されている。KGAではPG17で十分安定した運用ができているが、マルチリージョンの論理レプリケーション構成を視野に入れ、PG18の動向を追い続けている。PostgreSQLのリリースサイクルは年次で安定しており、エンタープライズ環境での信頼性は依然として最高レベルだ。