1. はじめに
2026 年の ClickHouse Open House で、ClickHouse が「Postgres managed by ClickHouse」をパブリックベータとして発表しました。公式は「RDS 比で毎秒トランザクション数 最大 5 倍」「ディスクバウンドなワークロードで最大 10 倍」と主張しています。
カラクリは NVMe をコンピュートと同じサーバに物理的に co-locate（同居）させる という点にあります。EBS のようなネットワーク接続ストレージと違い、ストレージへのアクセスがネットワークを介さないため、データが RAM に収まりきらない（disk-bound な）OLTP ワークロードで効く、という設計です。
co-locate（コロケート）: ここでは「ストレージをコンピュート（DB サーバ）と同じ物理サーバ内に置く」こと。RDS の標準構成（EBS = ネットワーク越しのストレージ）とは対照的に、ストレージ I/O がネットワークを経由しないぶん遅延が小さくなる、という発想です。
そこで本記事では、公式が GitHub で公開している再現可能なベンチマーク PostgresBench を使い、公式と完全に同じ手法で中規模構成（16 vCPU）の ClickHouse Postgres と Amazon RDS for PostgreSQL を実測し、「本当に速いのか」を自分の手で確かめます。
1.1. 今回の検証ゴール
| # | 検証項目 | 確認できれば OK の条件 |
|---|---|---|
| 1 | 中規模(16 vCPU)で CH Postgres と RDS の TPS を PostgresBench で実測し、公式 Large 値（約 3.5 倍）が再現するか | 両サービスで run.sh が 3 回完走し、TPS 比を公式値と並べて提示できる |
| 2 | NVMe co-located の優位が「disk-bound 前提」に依存することの裏取り | データサイズ > RAM(64GB) を確認し、p95 / p99 / stddev で効果を切り分ける |
| 3 | 「5 倍」主張を実測でどこに位置づけるか | 実測倍率を公式の幅(1.3〜4.5 倍)の中に位置づけ、ズレたら原因を切り分ける |
1.2. 結論（先出し）
- 絶対 TPS は公式 3.52 倍に対し、自実測は 2.03 倍（CH 16,019 / RDS 7,884）でした。公式ほどの差は出ていません。
- ズレの主因は CH 側が公開エンドポイント越し（NAT GW 経由）でネットワーク往復遅延がボトルネックになったこと。RDS は同一 VPC 内のプライベート接続で、公式値の 96.9% を再現しました（CH 側は公式値の 55.9%）。
- ただし テールレイテンシ（p95 / p99）で約 4〜5 倍、安定性で約 10 倍、CH が良好でした。RDS は GP3 の DiskQueueDepth がピーク 94 まで詰まり、レイテンシが大きく振れます。「絶対倍率」と「テールレイテンシ / 安定性」は別軸の優位として切り分けるのが本記事の結論です。
- なお、「両者を default で揃えたつもり」が実は崩れていた、という発見もありました（3.2 章）。
本記事のスコープは OLTP の TPS 比較のみです。ClickHouse Postgres の CDC（変更データキャプチャ）や ClickHouse 本体との統合（pg_clickhouse）は機会を見つけて・・
2. ClickHouse Postgres とは / 本記事のスコープ
2.1. ベータの概要
Postgres managed by ClickHouse (beta) によれば、本サービスは以下の特徴を持つマネージド PostgreSQL です。
- ベータ期間中は無料（本記事執筆時点で無料期限は 2026-06-15）。$300 のクレジットも付与されます
- 構成は 1 vCPU / 8GB / 59GB から 96 vCPU / 768GB / 60TB まで、NVMe ストレージ込み
- ClickPipes 経由で RDS / Aurora / Cloud SQL / Neon からの移行に対応
- HA は最大 2 スタンバイ（quorum レプリケーション）
2.2. NVMe co-locate のカラクリ
Fast, scalable, enterprise-grade Postgres natively integrated with ClickHouse によれば、性能の源泉は NVMe をコンピュートと co-locate する点にあります。これは裏を返すと、データが RAM に収まる（メモリバウンドな）ワークロードでは差が出にくいことを意味します。ストレージ I/O が発生して初めて co-locate の近さが効くからです。
そのため本検証では、後述のとおり データサイズを RAM より大きくして disk-bound にすることを公平性の最重要前提に置いています（3 章・4.4 章）。
2.3. 「5 倍」主張の構成依存性
公式の数値をよく見ると、「5 倍」という倍率は構成・スケール依存です。PostgresBench: A Reproducible Benchmark for Postgres Services の公開結果（SF 6849・約 100GB）を抜粋すると次のとおりです。
| サービス | 規模 | インスタンス | vCPU/RAM | ストレージ | 公式 TPS |
|---|---|---|---|---|---|
| ClickHouse Postgres | Large | m8gd.4xlarge | 16 / 64GB | 950GB NVMe | 28,668 |
| RDS for PostgreSQL | Large | db.m8gd.4xlarge | 16 / 64GB | 1000GB GP3 (16K IOPS) | 8,133 |
| Aurora PostgreSQL | Large | db.r6g.4xlarge | 16 / 128GB | 950GB NVMe | 12,628 |
| ClickHouse Postgres | Small | m8gd.xlarge | 4 / 16GB | 237GB NVMe | 6,172 |
| RDS for PostgreSQL | Small | db.m8gd.xlarge | 4 / 16GB | 1000GB GP3 (16K IOPS) | 4,882 |
- Large の CH/RDS 比 = 28,668 / 8,133 ≈ 3.52 倍
- Small の CH/RDS 比 = 6,172 / 4,882 ≈ 1.26 倍
つまり倍率は 1.3〜4.5 倍の幅があり、「5 倍」は別スケール（SF 34247 / 500GB）や高並列時の数字です。本記事はこの中でも差が大きく出る Large（16 vCPU）1 点を自分の手で再現し、自実測倍率がこの幅のどこに着地するかを示します。
3. 検証構成
3.1. ハードウェア・PostgreSQL バージョンの対称性
公平性を担保するため、CH Postgres と RDS、そして pgbench を打つ踏み台を、できる限り対称に揃えました。
| 項目 | ClickHouse Postgres | RDS for PostgreSQL | 揃い |
|---|---|---|---|
| PostgreSQL バージョン | 17.10 | 17.10 | OK |
| CPU アーキテクチャ | aarch64 (Graviton4 m8gd) | aarch64 (Graviton4 db.m8gd) | OK |
| vCPU / RAM | 16 / 64GB | 16 / 64GB | OK |
| ストレージ | 950GB NVMe (co-located) | 1000GB GP3 / 16K IOPS / 1000 MiBps | 本検証の差分 |
| クライアント踏み台 | m8g.4xlarge / AL2023 / 16 vCPU・64GB | 同左（同一インスタンスを使い回し） | OK |
| TLS | sslmode=require | sslmode=require | OK |
| Postgres 設定 | マネージド default のまま | default パラメータグループ | OK（と思っていた → 3.2 章） |
| 接続経路 | 踏み台 → NAT GW → CH 公開エンドポイント | 踏み台 → 同一 VPC の RDS プライベートエンドポイント | 経路非対称（3.4 章） |
PostgreSQL のバージョン文字列は厳密には次のとおりでした。
- CH:
17.10 (Ubuntu 17.10-1.pgdg22.04+1)（Ubuntu 22.04 + PGDG ビルド） - RDS:
17.10（RDS のSHOW server_versionは distribution 情報を返さず、プレーン文字列のみ）
メジャー・マイナーは 17.10 で完全に揃えています。ビルドは CH が Ubuntu/PGDG、RDS が Amazon ビルドという違いがありますが、RDS 側はバージョン文字列に distribution 情報を含めないため、ここまでが確認できる範囲です。
-
ClickHouse
-
RDS
3.2. 「default 設定で揃えた」前提が崩れていた
ここが本検証で予想外だった発見です。当初は「両者とも Postgres を独自にチューニングせず、出荷状態のまま使う」と考えていましたが、両 DB の pg_settings を取得して比較すると、どちらもマネージドサービスとしてチューニング済みの default で動いており、その内容が違っていました。
| 設定 | CH Postgres | RDS PostgreSQL | どちらに有利か |
|---|---|---|---|
random_page_cost |
1.1 | 4 | CH（NVMe 前提でプランナがランダムアクセスを安く見積もる） |
wal_level |
logical | minimal | RDS（WAL 書き込みのオーバーヘッドが小さい） |
shared_buffers |
13.5 GB | 15.4 GB | RDS（+14%） |
effective_cache_size |
48 GB | 30.7 GB | CH（+56%） |
wal_compression |
lz4 | zstd | アルゴリズム違い |
重要なのは、CH 有利な設定と RDS 有利な設定が混在していることです。どちらかが一方的にチューニングで下駄を履いているわけではありません。
3.3. PostgresBench の方針：default のまま比較する
設定が違うのに比較していいのか、という疑問が出ます。PostgresBench 公式は、ブログの "Default Postgres configuration" 節1で "We do not modify default PostgreSQL configurations across services; each system is tested using its out-of-the-box settings." と明記しており、ユーザーが手でチューニングしない状態（＝各ベンダーが出荷する default）でサービスを評価する方針を採っています。
多くのユーザーはマネージドサービスの default のまま使い始めるため、3.2 章の設定差は「測定の不備」ではなくマネージドサービスとしての品質の一部として比較に含める、という整理です。本記事もこれに従います。
3.4. 経路の非対称性（RDS 有利）
公平性の最大の崩れは接続経路です。
- RDS は同一 VPC 内のプライベートエンドポイントに直結（低 RTT）。
- CH Postgres はベータの公開エンドポイントのみで、踏み台からは NAT GW を経由して TLS で接続。
この非対称は RDS に有利です。CH 側は毎トランザクションでネットワーク往復のコストを余計に払うことになります。そのため本検証は「この不利な条件でも CH が勝てば、結論はより強くなる」という方針で進めました。
4. 計測結果
PostgresBench run.sh を SCALE_FACTOR=6849 / CLIENTS=256 / THREADS=16 / DURATION=600 で実行し、init → 3 回計測 → JSON 出力までを CH / RDS の両方で行いました（同一踏み台・同一パラメータ）。
4.1. TPS 比較
| 指標 | ClickHouse Postgres | RDS PostgreSQL | CH/RDS 比 | 公式 Large |
|---|---|---|---|---|
| TPS（3 run 平均） | 16,019 | 7,884 | 2.03× | 3.52×（28,668 / 8,133） |
| failed transactions | 0 | 0 | — | — |
実測の CH/RDS 比は 2.03 倍。公式 Large の 3.52 倍より小さく、2.3 章で示した幅（1.3〜4.5 倍）の下寄りに着地しました。なぜ公式ほど差が開かなかったのかは 5 章で切り分けます。
4.2. TPS の時系列波形
3 回計測（各 600 秒・30 秒ごとの進捗）の波形を見ると、両者の性格がはっきり分かれます。
- CH: 全 180 点が 14,630〜16,195 TPS の範囲に収まり、600 秒を通してほぼフラット。3 run 間の分散も ±0.4%。
- RDS: 180 点中 99 点（55%）が TPS < 8,000。本来の定常値は 5〜7k TPS。さらに run 1 だけ 開始 0〜60 秒で 19〜20k TPS の「キャッシュが温まった直後の山」があり、run 2 / 3 は最初から低い水準でした。
ここで興味深いのは、公式 RDS の 8,133 が、実測の run 1 平均（8,642）に近い点です。公式値も run 1 のような立ち上がりの山を含んだ平均値である可能性があります。
4.3. レイテンシ分布
絶対 TPS 以上に差が出たのがレイテンシの分布です。
| 指標 | ClickHouse Postgres | RDS PostgreSQL | RDS の悪化度 |
|---|---|---|---|
| 平均レイテンシ | 16.0 ms | 32.6 ms | 約 2× |
| p95 | 17.9〜18.4 ms（平均 18.1 ms） | 72.1〜73.8 ms（平均 73.0 ms） | 約 4× |
| p99 | 19.2〜19.7 ms（平均 19.5 ms） | 94.5〜98.4 ms（平均 96.6 ms） | 約 5× |
| run 内 stddev | 2.4〜2.7 ms | 22.9〜24.4 ms | 約 9〜10× |
CH は平均と p99 の差がごくわずか（16.0 → 19.5 ms）で、テールがほとんど伸びません。一方 RDS は平均 32.6 ms に対し p99 平均が 96.6 ms と、テールが 3 倍近くに伸びています。この差の原因は 6 章で掘り下げます。
4.4. disk-bound の裏取り（dataset > RAM）
NVMe co-locate の優位が出る前提（disk-bound）が成立していることを確認しました。
| db_size | pgbench_accounts | pgbench_history | |
|---|---|---|---|
| CH | 102 GB | 87 GB | 480 MB |
| RDS | 101 GB | 87 GB | 234 MB |
両者とも RAM(64GB) を大きく超えており、disk-bound 条件を満たしています。さらに accounts テーブルのサイズが 87GB で完全に一致しているため、データ量の面でも公平な比較になっています。
5. 公式値との対比と差分の解釈
実測が公式の 3.52 倍に届かず 2.03 倍だったのは、CH 側と RDS 側で「公式値の再現度」が大きく違ったためです。
| サービス | 公式 TPS | 自実測 TPS | 再現度 |
|---|---|---|---|
| RDS | 8,133 | 7,884 | 96.9% |
| CH | 28,668 | 16,019 | 55.9% |
5.1. RDS は物理天井をほぼ再現した
RDS は公式値の 96.9% を再現しました。RDS は同一 VPC のプライベート接続のためネットワーク経路がボトルネックにならず、GP3 16K IOPS という真の物理天井がそのまま効いた、と考えられます。実際、6 章で見るように RDS の ReadIOPS は通常時 5〜7K、ピークで約 10.94K と GP3 の上限近くまで張り付いていました。
5.2. CH はネットワーク往復で頭打ちになった
一方 CH は公式値の 55.9% にとどまりました。原因は 3.4 章の経路非対称、すなわち NAT GW 越しの公開エンドポイント接続によるネットワーク往復遅延だと考えられます。根拠は次のとおりです。
-
踏み台 → CH の RTT は約 2.4 ms。pgbench を
-c 1（単一クライアント）で回すと 1 トランザクションあたり約 14.4 ms かかりました。これは TPC-B の 1 トランザクションがおよそ 6 往復（6 RT × 2.4 ms ≈ 14.4 ms）することと整合します。 -
256 クライアント並列でネットワーク往復遅延だけで決まる理論上限は 256 / 14.4 ms ≈ 17,800 TPS。自実測の 16,019 TPS はこの理論上限のすぐ手前で、CH 側はネットワーク往復で頭打ちになっていると考えられます。
-
計測中の踏み台は CPU 使用率ピーク 11.7% / メモリ 0.66% にとどまり、踏み台 EC2 側がボトルネックになっているわけではないことを確認済みです。
-
init フェーズの内訳でも、踏み台側でデータを生成して DB に流し込む client-side generate で CH が大きく遅く、ネットワーク経路差がデータロードにも表れていました。
| Phase | CH (秒) | RDS (秒) | RDS / CH |
|---|---|---|---|
| total | 518.32 | 399.84 | 0.77× |
| drop tables | 1.12 | 0.00 | — |
| create tables | 0.01 | 0.01 | 1.00× |
| client-side generate | 390.92 | 257.89 | 0.66× |
| vacuum | 0.32 | 1.48 | 4.63× |
| primary keys | 125.95 | 140.46 | 1.12× |
client-side generate は踏み台 → DB へバルク INSERT する工程で、ネットワーク経路差が支配的に効きます。逆に server-side で完結する primary keys（インデックス構築）では CH のほうがやや速く、NVMe co-locate の優位が顔を出しています。vacuum は取得直後で空のため誤差レベルです。
補助的には、3.2 章の wal_level minimal（RDS 有利）による WAL オーバーヘッド削減も RDS の善戦に寄与している可能性がありますが、こちらは設定差からの推定で、単独の寄与度までは切り分けられていません。
つまり、実測の 2.03 倍は「CH の実力値」ではなく「公開エンドポイント越しの実用構成での値」 です。同一 VPC でプライベート接続できるようになれば、CH 側はまだ伸びる余地があると考えられます。
6. テールレイテンシと安定性で CH が圧勝する理由
絶対倍率では 2.03 倍にとどまった CH ですが、テールレイテンシ（p95 / p99）で約 4〜5 倍、安定性で約 10 倍と一貫して良好でした。ここには明確な物理的根拠があります。
6.1. RDS のテールを悪化させた決定的証拠
RDS 側の CloudWatch メトリクスに、テールレイテンシ悪化の直接証拠がありました。
-
DiskQueueDepth がピーク 94
I/O 要求がキューに 90 件以上積み上がっており、ストレージが捌ききれていません。
-
ReadLatency がピーク 4.24 ms まで悪化。
-
ReadIOPS はピーク 10.94K / 通常時 5〜7K。
GP3 の 16K IOPS 上限に近づき、キューが詰まっています。
GP3 はネットワーク接続ストレージのため、IOPS が上限に張り付くとキューイング遅延が一気に増え、これがそのまま p95 / p99 の伸びとして表面化します。
6.2. CH が安定する理由
対照的に CH は、TPS が 600 秒フラット（4.2 章）、run 内 stddev 2.4〜2.7 ms、3 run 間分散 ±0.4% と極めて安定していました。NVMe を co-locate しているため、キャッシュに乗らない読み出しが起きてもストレージ側の遅延が小さく、キューイング遅延が蓄積しにくいためだと考えられます。
6.3. 安定性の対比
| 指標 | ClickHouse Postgres | RDS PostgreSQL |
|---|---|---|
| 3 run 間の TPS 分散 | ±0.4% | ±9% |
| run 内レイテンシ stddev | 2.4〜2.7 ms | 22.9〜24.4 ms |
RDS は計測のたびにキャッシュの温まり具合が変わるため安定性が低く（±9%）、ベンチマークとして「同じ数字が出ない」傾向がありました。CH は何度回しても ±0.4% に収まり、SLA を引く観点でも予測可能性が高いと言えます。
7. RDS の立ち上がり急落パターン
検証の過程で得た、本筋を補強する観察を一点記録します。
RDS は run 1 の開始 60 秒で 19〜20k TPS の高い山を作り、キャッシュに乗らない読み出しが増えると 4〜7k へ急落して、IOPS が頭打ちになった定常状態に収束しました。GP3 16K IOPS を 1 トランザクションあたり約 4 IOPS で割ると 4〜6k TPS となり、観測値と整合します。
8. まとめと運用への示唆
| 観点 | 本検証の結論 |
|---|---|
| 絶対 TPS | 公開エンドポイント越しの実用構成では CH/RDS 約 2.0 倍。公式の 3.5 倍は同一 VPC など好条件での値と想定 |
| 公式値の再現 | RDS は 96.9% 再現（物理天井がそのまま）。CH は 55.9%（ネットワーク往復で頭打ち、実力はさらに上） |
| テールレイテンシ | CH が p95 で約 4 倍・p99 で約 5 倍良好。RDS は GP3 のキュー詰まり（DiskQueueDepth 94）が原因 |
| 安定性 | CH が圧勝（3 run 分散 ±0.4% vs RDS ±9%）。SLA を引くなら CH が予測しやすい |
| 設定の前提 | 「default で揃えた」は厳密には成立せず、両者の tuned default が混在（3.2 章） |
結論として、ClickHouse Postgres の「5 倍」は構成依存で、自分の環境で測るしかない数字です。公開エンドポイント運用なら絶対倍率は 2 倍前後が現実的ですが、テールレイテンシと安定性という別軸では明確に優位でした。同一 VPC 接続が選べるようになれば、絶対倍率も公式の 3 倍前後に近づく余地があります。
「速い」を一つの数字で語るのではなく、絶対スループット / テールレイテンシ / 安定性を分けて評価することの大切さが、今回の収穫でした。
参考
- Postgres managed by ClickHouse (beta) — pricing & beta terms
- Fast, scalable, enterprise-grade Postgres natively integrated with ClickHouse
- PostgresBench: A Reproducible Benchmark for Postgres Services
- ClickHouse/PostgresBench (GitHub)
- PostgresBench 公開結果サイト
- Managed Postgres | ClickHouse Docs
- pgbench — PostgreSQL Documentation