【ITニュース解説】PostgreSQL 18: The AIO Revolution, UUIDv7, and the Path to Unprecedented Performance

PostgreSQL 18は、2025年9月25日にリリースされたデータベースの新しいバージョンである。これは単なる小さな機能追加ではなく、PostgreSQLの性能、管理のしやすさ、開発体験を根本的に向上させるための大きな進化を含んでいる。特に大規模なPostgreSQL環境で長年課題とされてきた性能、運用、開発における問題に直接対応しており、PostgreSQLを利用している企業にとっては、すぐに大きな利益をもたらすアップグレードとなるだろう。

このリリースで最も重要な変更点は、読み込み操作のための新しい非同期I/O（AIO）サブシステムの導入である。これまでPostgreSQLは、同期I/Oという方式に依存していた。これは、データベースがディスクやオペレーティングシステム（OS）に対してデータを読み込む要求を出すと、そのデータが返されるまで、他の作業をせずに待機するというものだった。現代のクラウド環境や仮想環境では、ストレージへのアクセスに時間がかかることが多く、この待機時間はCPUが何もせずに無駄になることを意味し、全体の処理能力を低下させていた。 PostgreSQL 18ではこの仕組みが大きく変わった。AIOを使うことで、データベースは複数の読み込み要求を同時に発行できるようになる。これにより、以前は待機していたCPUの時間を他の処理に使うことが可能になり、特にI/Oがボトルネックとなるような処理（ディスクへの読み書きが多い処理）において、全体の処理能力と応答速度が大幅に向上する。 例えば、高いネットワーク遅延を持つクラウドストレージ環境での初期のベンチマークでは、データがキャッシュされていない状態での読み込み（コールドリード）が最大で3倍高速化されたという報告がある。具体的な例として、順次スキャン（データを順番に読み込む処理）がPostgreSQL 17では約7.5秒かかっていたのに対し、PostgreSQL 18のAIOでは約2.5秒で完了する。インデックスを使った読み込み（Bitmap Heap Scan）も約2.5倍、データベースのメンテナンス処理であるVACUUMも約1.9倍高速化されている。これらの数値は、I/Oの遅延が大きい環境でAIOが最も効果を発揮することを示すもので、実際の性能向上はハードウェアや処理内容によって異なる。 データベース管理者（DBA）は、このAIOの動作をio_methodという新しい設定項目（GUC）で細かく制御できる。デフォルトのworker設定では、バックグラウンドのI/Oワーカーを使って非同期処理が行われる。Linux環境であれば、より高性能なio_uringというオプションも利用可能で、これは最新のLinuxカーネルの機能を利用し、最も低いオーバーヘッドで最高の性能を引き出す。旧来の同期I/Oに戻すためのsyncオプションも用意されており、比較やトラブルシューティングに役立つ。例えば、大規模なECプラットフォームが夜間の分析バッチ処理で巨大なテーブルスキャンを実行していたケースでは、Linuxホストでio_uringを有効にした結果、レポート生成時間が60%短縮され、日中の重要なオンライン処理のためのリソースを確保できたという実例がある。

次に、UUID（Universally Unique Identifier）の利用に関する大きな進歩がある。これまで、開発者はデータベースの主キー（テーブルの行を一意に識別するための項目）として、自動採番される整数（BIGSERIAL）を使うか、UUIDを使うかで悩むことが多かった。UUIDは、データベースが分散している環境でも一意性を保証できるため、セキュリティ面でも有利だが、最も一般的なUUIDv4（ランダムな値）は、データがインデックス構造のあちこちにランダムに挿入されるため、B-treeインデックスというデータ構造が断片化し、書き込み性能が著しく低下するという問題があった。 PostgreSQL 18は、この問題を完全に解決するUUIDバージョン7（uuidv7()）をネイティブでサポートする。UUIDv7は時間順序を持つUUIDで、最初の48ビットがUnixタイムスタンプを表している。これにより、新しいIDは常にインデックスの末尾に追加されるため、自動採番される整数とほぼ同じように動作し、インデックスの断片化を最小限に抑えることができる。この新しい方式により、UUIDの持つグローバルな一意性と、自動採番整数並みの書き込み性能を両立できるようになった。 ベンチマーク結果を見ると、大量のデータを挿入する際の時間は、UUIDv7が自動採番とほぼ同じ約3.5分で完了するのに対し、UUIDv4では約15分もかかっていた。インデックスのサイズも、UUIDv7は約250MBと自動採番の約200MBに近い値だが、UUIDv4は約800MBと大幅に大きくなる。さらに、インデックスの「ページ分割」という、性能に影響を与える操作も、UUIDv7は自動採番と同じく最小限に抑えられる。これにより、分散システムでUUIDを主キーとして使用する際、従来のUUIDv4で発生していた書き込み性能の低下を心配する必要がなくなった。

PostgreSQL 18は、データベース管理者（DBA）の作業を大幅に楽にする機能もいくつか導入している。 一つは、メジャーバージョンアップグレードの際の改善だ。これまでは、pg_upgradeというツールを使ってPostgreSQLのメジャーバージョン（例えばバージョン17から18へ）をアップグレードすると、直後に性能が一時的に低下するという問題があった。これは、データベースのクエリプランナーが使用する「オプティマイザ統計」（データの分布情報など）が引き継がれず、アップグレード後に再度ANALYZEコマンドを実行して統計を再学習させる必要があったためだ。PostgreSQL 18では、pg_upgradeがこのプランナー統計を保持するようになったため、アップグレードされたデータベースは最初から最適なクエリ計画で動作できる。これにより、アップグレード後の性能低下期間がなくなり、重要なシステムでのメジャーバージョンアップグレードがより安全でスムーズになる。 もう一つは、クエリの分析ツールEXPLAIN ANALYZEの強化だ。これまで、クエリのボトルネックを詳細に診断するためには、EXPLAIN ANALYZEコマンドにBUFFERSやTIMINGといったオプションを手動で追加する必要があった。PostgreSQL 18では、EXPLAIN ANALYZEがデフォルトでバッファ使用状況を含むようになった。この変更により、開発者やDBAは、クエリがどれだけI/Oリソースを使用しているかという重要な情報を、より簡単に、そして忘れずに確認できるようになり、ボトルネックの診断が効率化される。

開発者の生産性向上に貢献するSQL機能も導入されている。 「生成カラム」（他のカラムの値から計算されるカラム）は以前のバージョンで導入されていたが、これまでは常にSTORED（値がディスクに保存され、書き込み時に計算される）として扱われていた。このため、生成カラムを追加する際にはテーブル全体の再構築が必要で、大規模なテーブルでは時間がかかる作業だった。PostgreSQL 18では、新しくVIRTUALオプションがデフォルトとなり、明示的にSTOREDと指定しない限り、生成カラムはVIRTUALとして扱われる。VIRTUALカラムは、データが読み込まれるときに初めて計算され、テーブルのディスク領域を消費しない。また、VIRTUALカラムの追加は、テーブルのメタデータ（構造情報）の変更だけで済むため、瞬時に完了し、スキーマ変更がより安全で高速になった。 データ操作言語（DML）のINSERT、UPDATE、DELETE文で使用できるRETURNING句も強化された。これまでは、INSERTとUPDATEでは変更後の新しい行（NEW）しか返せず、DELETEでは変更前の古い行（OLD）しか返せなかった。監査ログの記録などで、変更前と変更後の両方の状態を知りたい場合、別のクエリを実行するか、トリガーと呼ばれる仕組みを利用する必要があった。PostgreSQL 18では、RETURNING句でOLDとNEWのエイリアスを明示的に使用できるようになったため、単一のクエリで変更前後の両方のデータを取得し、原子的に（一連の処理として確実に）監査ログを記録したり、変更を追跡したりできるようになった。 さらに、クエリの最適化機能としてB-tree Skip Scanが導入された。B-treeインデックスはリレーショナルデータベースで広く使われているが、複数のカラムで構成されるインデックス（例：(A, B, C)）の場合、効率的に利用するには、通常、クエリが先頭のカラム（A）でフィルタリングする必要があった。PostgreSQL 18のオプティマイザは、この制限を緩和し、Skip Scanルックアップを利用できるようになった。これは、インデックスの先頭カラムのカーディナリティ（値の種類の少なさ、例：「ステータス」カラムの「アクティブ」「非アクティブ」など）が低い場合、オプティマイザが先頭カラムの異なる値を効率的に「スキップ」して、次のカラムで検索できるようにする機能である。これにより、一つのインデックスがより多くの異なるクエリパターンで利用できるようになり、既存の多くのテーブルで自動的に性能が向上することが期待される。

結論として、PostgreSQL 18は、非同期I/Oによる基盤となる性能の向上、UUIDv7による分散アプリケーションのインデックス断片化問題の解決、そしてpg_upgradeでのプランナー統計保持による痛みのないアップグレードといった、多岐にわたる重要な機能強化を実現した。これらの改善は、大規模な運用環境と現代のアプリケーション開発の両方にとって、他に類を見ない成功を意味する。このリリースは、PostgreSQLが世界で最も先進的で機能豊富なオープンソースのリレーショナルデータベースとしての地位をさらに確固たるものにするものであり、PostgreSQL 18へのアップグレードは必須と言える。