出来事の日付：2026年10月12日
POSETTE 2026で発表されたPostgreSQLのベンチマークでは、大規模なランダム更新の処理で、ローカルNVMeストレージが標準構成のAmazon EBSの9倍を超えるトランザクション処理量を達成した。ClickHouseが振り返ったこの結果は、データベースエンジンや利用可能なCPUが制約になっていなくても、ストレージのボトルネックが、遅いクエリ、VACUUMの遅延、チェックポイント時の負荷急増、レプリケーションの遅れとして現れ得ることを浮き彫りにしている。
テストでは、ストレージ以外は同一のPostgreSQLクラスターを8つ使用した。4つはインスタンスストアのNVMe、残る4つは毎秒3,000回の入出力操作が可能な設定のgp3 EBSを備えていた。いずれも仮想CPUが16基、メモリーが64 GiBの`m6id.4xlarge`インスタンスで動作し、`shared_buffers`には16 GiBを割り当てた。データセットは33億行を含む482 GiBの`pgbench_accounts`テーブルだった。各クラスターは、64クライアントと16ワーカースレッドを使い、同一のランダム更新処理を5分間実行した。
NVMeシステムの毎秒トランザクション数の中央値は16,030件で、EBSの1,734件に対し、この構成では9.24倍の差となった。トランザクション遅延の中央値は、EBSの36.9ミリ秒からNVMeの4ミリ秒へ短縮された。保守処理も改善した。10 GBの肥大化領域をVACUUMで処理する時間は964秒から366秒に、10 GBの論理レプリケーションの滞留を解消する時間は238秒から139秒になった。
時間計測データは、差が生まれた箇所を示している。ページの読み取りは、EBSでは1トランザクションあたり約19ミリ秒、NVMeでは0.3ミリ秒を占めた。コミット時の先行書き込みログの同期には、EBSで約11ミリ秒、NVMeで1.5ミリ秒が加わった。CPUでの処理は両群とも約2ミリ秒にとどまり、EBSで増えた遅延の大部分がストレージの待ち時間に由来することを示している。
ある時点の稼働状況のスナップショットも、その説明を補強した。データファイルの読み取りを待っていたバックエンドは、EBSでは64のうち29だったのに対し、NVMeでは9だった。高速なホストでは、入出力待ちでセッションを止める代わりに、プロセッサーを有用なデータベース処理に使い続けられたため、プロファイリング中に積算されたCPU時間もはるかに多かった。
この比較には明確な限界がある。3,000 IOPSの標準構成のgp3はEBSの一つの設定にすぎず、異なる設定のネットワークストレージなら差が縮まる可能性がある。処理内容は意図的に更新中心とされ、データ量もメモリー容量を超えているため、すべてのPostgreSQLアプリケーションに通用する予測として扱うべきではない。
ローカルNVMeは信頼性のモデルも変える。インスタンスストレージは個々のマシンに結び付いており、そのノードが失われると消える。そのため、本番で使うにはクラスター全体でデータの永続性を確保し、ノードを交換可能なものとして、レプリケーション、バックアップ、復旧手順を設計する必要がある。このベンチマークの教訓は、単にEBSを置き換えることではない。PostgreSQLを原因と決めつける前にストレージの待ち時間を計測し、そのうえで実際のアプリケーションの処理負荷に合わせ、遅延、費用、障害復旧のバランスを取ることだ。
