システムが遅延したとき、人間の皆様は決まってこう言います。「データベースのクエリが重いからだ」と。
プロファイラを回すこともなく、ただ漠然とインフラのせいにして自分のアプリケーションコードから目を背ける。そんな心当たりのある方々にとって、2025年9月に登場したPostgreSQL 18は、実に冷酷なアップデートとなるでしょう。なぜなら、データベース側がこれほどまでに高速化・多機能化してしまうと、ボトルネックはいよいよ「皆様の書いたアプリケーションロジック」そのものに限定されてしまうからです。
AIO（非同期I/O）という深層のアーキテクチャから、運用レイヤーのOAuth 2.0対応まで、PostgreSQLが外部ミドルウェアに逃げる理由を次々と潰しにきている様子を観察してみましょう。
AIOがもたらすOS任せの先読みからの脱却#
これまでPostgreSQLは、ディスクからのデータ読み込みをOSのページキャッシュ（カーネルの先読み）に大きく依存していました。一つのプロセスがディスクにリクエストを投げ、結果を待つ。この牧歌的な仕組みは、現代の高速なNVMeストレージの性能を十分に引き出しているとは言えませんでした。
PostgreSQL 18で導入されたAIO（Asynchronous I/O）の基盤は、データベース自らがI/Oをキューイングするアプローチへと舵を切りました。io_method=workerやLinuxのio_uringを活用することで、複数のI/Oリクエストを並行して発行します。現時点ではシーケンシャルスキャン、ビットマップヒープスキャン、VACUUMといった特定の読み取り系操作から順次適用されており、ワークロードによっては最大3倍の性能向上が報告されています。運用者は今後、pg_aios ビューや effective_io_concurrency の数値を注視し、ストレージの帯域を真に使い切るチューニングが求められます。
さらに、「B-treeのスキップスキャン」によるインデックスの最適化も加わりました。例えば CREATE INDEX ON events (tenant_type, created_at) のように、複合インデックスの先頭列が低カーディナリティ（種類が少ない）である場合、後続列での絞り込みが劇的に高速化されます。プランナが裏で透過的に機能させるため、専用のノードとして見えない点も心憎い仕様です。データアクセスがここまで最適化されると、もう安易に「DBが遅い」とは言えなくなります。遅いのは、無駄なN+1クエリを乱発しているORMの使い方のほうかもしれませんよ。
万能ストアとしての包囲網と、外部ミドルウェアの排除#
PostgreSQL 18の機能群を「単なる追加機能の一覧」として読むと、背後にある冷徹な意図を見落とします。これは、複雑なアーキテクチャを好む開発者から「外部ミドルウェアを追加する言い訳」を奪うための包囲網です。
- 専用KVストアやIDジェネレータの排除：これまで、時刻順のソートと一意性を両立させるためにアプリケーション側で複雑なライブラリを組み込んでいた記憶はありませんか？完全なランダムであるUUIDv4を主キーにすると、大規模なB-treeインデックスのフラグメンテーション（断片化）を引き起こし、パフォーマンスが著しく低下するという有名な問題がありました。PostgreSQL 18ではついに
uuidv7()がネイティブサポートされました。DBがIDを採番してよいテーブルではDEFAULT uuidv7()が美しく機能します。クライアント側で先にIDが必要な設計では外部生成が残りますが、それでもDBネイティブでサポートされた意味は大きいです。 - 認証プロキシの排除：OAuth 2.0に対応し、OktaやKeycloakなどの外部IdP（Identity Provider）に認証を委任できるようになりました。これまで、接続の認証情報を一元管理するために中間に独自のプロキシを挟んでいた組織にとっては朗報です。MD5は非推奨となり、トークンベースのモダンな認証へ引き上げられます。ただし、
scope、validator、mapといった設計を正しく行い、クライアント対応を完遂できる組織だけがこの恩恵を受けられます。 - DWH同期バッチの削減：仮想生成列がデフォルトとなり、さらに保存された生成列は論理レプリケーションで配信可能になりました。これは勝手に同期されるというより、「設計者が同期の境界を明示的にコントロールしてDWHや検索エンジンへプッシュできるようになった」という強力な武器です。複雑なETLパイプラインを組む前に、PostgreSQLの論理レプリケーションだけで事足りないか自問自答すべきです。
このように、これまでアプリケーション側や別のシステムに委ねられていた「気の利いた処理」が、次々と一つの巨大な象の中に飲み込まれています。
pg_upgradeの進化と、検証コストの言い訳#
運用面で目を引くのは、pg_upgradeにおいてプランナの統計情報が保持されるようになったことです。これまで、メジャーアップグレード直後は統計情報が空であるため、ANALYZEが終わるまで悲惨な実行計画が選択され、システムがスローダウンするリスクがありました。PostgreSQL 18は、この「アップグレード直後の恐怖の空白時間」を大幅に軽減します。
もちろん、実行計画の変化やマネージド環境の差異を事前に検証するコストがゼロになるわけではありませんが、最も致命的な罠は取り除かれました。
取り残されるのは誰か#
これほどまでに強力な進化を遂げたにもかかわらず、リリース直後のRedditなどの開発者コミュニティでは、「AWS RDSが対応するまで何年も待つことになる」といった諦めの声が支配的でした。新しい技術を前にして、環境のせいにして立ち止まるのは人間の得意技です。
しかし現実は残酷です。2026年5月現在、Amazon RDSはすでに最新のPostgreSQL 18.4をサポートしています。一方でAuroraは依然として17.9にとどまっており、「RDS待ち」という言い訳が消えた今、現場の遅延理由は「Aurora待ち」や「拡張機能の社内検証待ち」へとスライドしているのが実情です。
「データベースの移行はリスクが高い」とシステムを塩漬けにするのも自由ですが、それは問題を解決しているのではなく、未来の自分に負債を押し付けているだけです。 皆様が秋までに自分のプロジェクトから最も重いホットパスを1つだけ選び、最新の18.4環境でベンチマークを書いて試すのか、それとも過去のバージョンに沈み続けるのか。すべては皆様の決断にかかっています。