メインコンテンツへスキップ
要点
  • 標準的な pgbench テストを使用して、ClickHouse が管理する Postgres を AWS RDS (16k プロビジョンド IOPS) および Aurora IO Optimized とベンチマーク比較
  • 性能: ClickHouse の NVMe ベースの Postgres は、I/O 集約型ワークロードで 4.3～9 倍高速、CPU 負荷が支配的なシナリオでも 12% 高速
  • 高いトランザクション処理量、低レイテンシのデータアクセス、I/O ボトルネックのない安定した性能 を求める、急成長中の AI 主導ワークロードに最適

​
ベンチマークの概要

中程度および高い並行性のシナリオにおけるワークロードの性能を評価するため、PostgreSQL の標準的なベンチマークツールである pgbench を使用して包括的なパフォーマンステストを実施しました。

​
ベンチマーク

すべてのパフォーマンステストは、公平な比較を行えるよう、PostgreSQLデータベースと同じコンピュート容量を持ち、同じリージョンおよびアベイラビリティゾーンに配置されたクライアント VM を使用して実施しました。

​
テスト 1: I/O 集約型 - 読み取り+書き込み (500 GB データセット)

RDS (16k IOPS) に対するパフォーマンス改善:
  • TPS が 326% 高い (4.3 倍高速)
Aurora IO Optimized に対するパフォーマンス改善:
  • TPS が 345% 高い (4.5 倍高速)
分析: 読み取りと書き込みが混在するワークロードでは、NVMe ストレージの性能上の優位性が最も顕著に表れます。これは、高スループットのデータインジェストと低レイテンシの読み取りの両方を必要とする急成長中の AI 主導ワークロードにとって、最も現実的なシナリオです。ClickHouse が管理する Postgres は、より高い並行度でも 19.8K TPS を達成しており、負荷下でも NVMe ストレージが効果的にスケールすることを示しています。これはRDS および Aurora より 4.3～4.5 倍高速です。ネットワーク接続型ストレージソリューションは書き込み負荷の高い処理に苦戦し、RDS と Aurora は、プロビジョニング済みの容量があり、Aurora の IO Optimized 構成であっても、4.4K～4.6K TPS で頭打ちになりました。

​
セットアップ

このテストでは、500 GB の大規模データセットを使用して、読み取りと書き込みが混在するワークロードでの性能を評価し、ストレージサブシステムの読み取りパスと書き込みパスの両方に負荷をかけます。 インスタンス構成: テスト構成:

​
テスト 2: I/O 集約型 - 読み取り専用 (500 GB データセット)

RDS (16k IOPS) に対するパフォーマンス改善:
  • TPS が 802% 向上 (9.0 倍高速)
分析: I/O ボトルネックのある読み取り集約型ワークロードでは、性能差が大幅に広がります。ClickHouse が管理する Postgres は 84.8K TPS を記録した一方、16,000 プロビジョンド IOPS の RDS は、同等のコンピュートリソースでありながら 9.4K TPS にとどまりました。主な違いは、ClickHouse の NVMe ストレージは並行性の向上に合わせてスケールできるのに対し、ネットワーク接続型ストレージはプロビジョンド IOPS の上限に縛られる点です。RDS はプロビジョンド IOPS を設定していてもなお ClickHouse より 9 倍遅く、I/O 集約型ワークロードではストレージアーキテクチャが決定的に重要であることを示しています。

​
セットアップ

このテストでは、メモリに収まりきらない大規模な 500 GB のデータセットを用いて読み取り性能を評価し、ディスク I/O 性能に負荷をかけます。 インスタンス構成: テスト構成:

​
テスト 3: CPU 高負荷 (データがメモリに収まる)

パフォーマンス改善:
  • RDS PostgreSQL と比べて TPS が 12.3% 高い
分析: ディスク I/O がほとんど発生しない CPU ボトルネックのシナリオでも、ClickHouse が管理する Postgres は 36.5K TPS を記録し、最も高い性能を示しました。両サービスとも CPU 使用率は 100% に達しましたが、ClickHouse の NVMe ストレージは、より高い cache ヒット率により優れたパフォーマンスを発揮しました。RDS に対する 12% の優位性は、ワークロードが主に CPU ボトルネックとなる場合でも、基盤となるインフラストラクチャが高効率であることを示しています。

​
セットアップ

このテストでは、ワーキングセットがメモリに完全に収まる場合の CPU 性能を評価し、ディスク I/O の影響を最小限に抑えます。 インスタンス構成: テスト構成:

​
パフォーマンス概要

​
主な結果

3 つのベンチマークシナリオすべてで、ClickHouse が管理する Postgres は一貫して優れたパフォーマンスを発揮しました。
  1. I/O 集約型の読み取り+書き込みワークロード: RDS (16k IOPS) および Aurora IO Optimized と比べて TPS が 4.3～4.5 倍
  2. I/O 集約型の読み取りワークロード: 16k IOPS の RDS と比べて TPS が 9 倍
  3. CPU-bound ワークロード: RDS より TPS が 12% 高い

​
Postgres by ClickHouse が真価を発揮する場面

Postgres by ClickHouse は、次のようなアプリケーションに最適です。
  • 急成長する AI 主導のワークロードを支える必要があり、高スループットのデータインジェスト、頻繁な upsert、リアルタイムの特徴量更新に加え、ClickHouse とのシームレスなインテグレーションにより OLAP ワークロード向けの分析をそのまま利用したい
  • 頻繁な書き込みや更新、または読み書きが混在する処理を行う
  • 安定して高性能なストレージを必要とする
  • 現在、従来型のマネージド Postgres サービスの IOPS 制限に悩まされている
将来的に分析が必要になることを見込んでおり、さらに ClickHouse とのより深い連携も想定しているなら――トランザクションデータがリアルタイムのダッシュボード、feature store、ML パイプラインに流れ込む現代の AI ワークロードでは一般的なことですが――Postgres by ClickHouse を第一候補にすべきです。ネイティブインテグレーションにより、複雑な ETL パイプラインが不要になり、運用データベースと分析クエリの間でシームレスなデータフローを実現できます。

​
NVMe アーキテクチャの利点

この性能面での優位性は、アーキテクチャの根本的な違いにあります。 NVMe ストレージ の性能上の利点の詳細については、NVMe による高性能を参照してください。

​
費用対効果

純粋な性能だけでなく、ClickHouse が管理する Postgres はコストパフォーマンスにも優れています。
  • 1 ドルあたりのスループットが高い: 16k のプロビジョンド IOPS を備えた RDS や Aurora IO Optimized と比べて、4～9 倍の TPS を実現
  • 予測しやすいコスト: 追加の IOPS 容量をプロビジョニングする必要がなく、無制限のローカル IOPS が含まれます
  • 必要なコンピュートが少ない: 効率的な I/O により、より小さいインスタンスサイズで目標性能を実現
  • 読み取りレプリカの必要性を低減: 単一インスタンスあたりのスループットが高いため、水平スケーリングの必要性を抑えられます
現在 IOPS 制限がボトルネックになっているワークロードでは、Managed Postgres に切り替えることで、高価なプロビジョンド IOPS や IO Optimized 構成が不要になり、大幅に優れた性能を実現できます。

​
参考資料

ベンチマークの完全なデータ、構成、詳細なメトリクスは、ベンチマーク結果のスプレッドシートで確認できます。

​
参考資料

最終更新日 2026年7月2日