この記事は、PostgreSQLを使っているアプリにClickHouseを足す設計についてのメモです。Postgresを置き換える話ではなく、トランザクションはPostgres、重い分析はClickHouseに逃がす構成を考えます。本文は 2026年6月8日に確認したClickHouse公式ブログとGitHub情報をもとにしています。

はじめに

個人開発でも業務システムでも、最初のDBにPostgreSQLを選ぶのは自然です。

ユーザー、権限、課金、注文、設定。こういうデータはPostgresに置きたい。トランザクションが強くて、周辺ツールも多く、アプリケーションから扱いやすいからです。

ただ、プロダクトが育つと別のものが増えてきます。

イベントログ
監査ログ
検索ログ
AIの推論ログ
ダッシュボード用の集計
顧客ごとの利用状況
モデル別のコストやレイテンシ

ここまでPostgresだけで抱えると、だんだん苦しくなります。

最初はインデックスを足す。
次に集計用テーブルを作る。
そのうち read replica を作る。
でも、重い分析クエリが増えると、アプリ本体のDBに負荷が戻ってきます。

そこで「PostgresをやめてClickHouseに移る」と考えると、話が大きくなりすぎます。

自分が現実的だと思うのは、Postgresを捨てずにClickHouseを足す構成です。

この記事で言いたいこと

PostgresとClickHouseは競合というより役割分担しやすい
Postgresはトランザクションの記録元として残す
ClickHouseは大量ログ、集計、AI系の分析を受け持つ
CDCでPostgresの変更をClickHouseへ流すと、アプリを急に作り替えなくて済む
pg_clickhouseを使うと、Postgres側からClickHouseの分析クエリを呼ぶ選択肢も出てきた

Postgresだけで頑張ると何がつらいか

Postgresは強いDBです。

小さなアプリなら、しばらくPostgresだけでいけます。JSONも扱えるし、インデックスも豊富です。分析用のSQLも書けます。

でも、次のようなクエリが増えると、アプリ本体のDBとしてはつらくなってきます。

クエリ	つらくなる理由
過去90日のイベントをユーザー別に集計	読む行数が多い
AIリクエストのモデル別コストを集計	ログが増え続ける
失敗したtool callを原因別に集計	監査ログやJSONを大量に読む
顧客向けダッシュボードをリアルタイム更新	同時実行と集計が増える
日次、週次、月次のファネル分析	集計軸が増えやすい

こういう処理は、正しさよりも「大量に読んで速く集計する」ことが大事になります。

Postgresが悪いわけではありません。役割が違うだけです。

役割分担はこう考える

自分なら、最初にこう分けます。

役割	使うDB
ユーザー、権限、課金、注文	PostgreSQL
アプリケーションの正規データ	PostgreSQL
書き込み整合性が必要な処理	PostgreSQL
イベントログ	ClickHouse
AIの推論ログ、検索ログ、評価ログ	ClickHouse
顧客向けの重い集計	ClickHouse
社内ダッシュボード	ClickHouse

Postgresは「正」として残します。

ClickHouseは「あとから大量に読む場所」として足します。

この分け方にすると、アプリの中心は急に変えなくて済みます。既存のPostgresを守りながら、分析の負荷だけをClickHouseに逃がせるからです。

ClickHouse公式ブログでも、PostgreSQLはトランザクションの記録元、ClickHouseは分析を担当する、という組み合わせが紹介されています。¹

CDCでPostgresからClickHouseへ流す

PostgresのデータをClickHouseに移す方法はいろいろあります。

一番分かりやすいのは、定期バッチです。毎時、毎日、Postgresからデータを抜いてClickHouseに入れる。

ただ、リアルタイムに近い分析をしたいならCDCを使いたくなります。

CDCは Change Data Capture の略で、DBの変更を読み取って別の場所へ流す仕組みです。Postgresに入った変更をClickHouseへ流せば、アプリの書き込み先はPostgresのまま、分析用データだけClickHouseに持っていけます。

ClickHouse Cloudでは、ClickPipesのPostgres CDC connectorがGAになっています。PeerDBがClickHouse Cloudに統合され、PostgresからClickHouseへのCDCを支える形になっています。²

公式の振り返り記事では、PeerDBは2024年7月にClickHouseが買収し、ClickPipesのPostgres CDC connectorを動かすエンジンになったと説明されています。³

CDCを入れれば何も考えなくていい、という話ではありません。スキーマ変更、削除、重複排除、遅延、初回ロード、障害時の再開を設計する必要があります。

どのデータを流すか

全部流す必要はありません。

むしろ、最初は絞ったほうがいいです。

流す候補	理由
注文や決済の履歴	顧客別、期間別の分析に使う
イベントログ	アプリ本体DBに残すと膨らみやすい
AIリクエストログ	モデル別コスト、失敗率、レイテンシを見る
検索ログ	RAGや全文検索の改善に使う
監査ログ	あとから説明するために残す

逆に、次のようなものは慎重に扱います。

データ	注意点
個人情報	ClickHouse側で誰が見られるかを決める
APIキーやトークン	そもそも流さない
書き込み直後に厳密な整合性が必要なデータ	分析側に逃がすだけにする
頻繁に更新される小さなマスタ	ClickHouseに流す意味が薄い場合がある

ClickHouseは大量に読むところで強い。そこに寄せるデータを選ぶのが大事です。

pg_clickhouse という別ルート

もう1つ見ておきたいのが pg_clickhouse です。

pg_clickhouse は、PostgreSQLからClickHouse上のデータをクエリするためのPostgres拡張です。ClickHouse公式ブログでは、Postgres側のSQLやアプリケーションコードを書き換える負担を減らし、分析クエリの実行をClickHouseへ押し出すことを狙っていると説明されています。⁴

最初の公開時は v0.1.0 でした。GitHubのREADMEでは、PostgreSQL 13以降、ClickHouse v23以降をサポートするとされています。2026年6月8日時点では、GitHub上の最新リリースは v0.3.1 です。⁵

イメージとしては、こういう使い方です。

CREATE EXTENSION pg_clickhouse;

CREATE SERVER ch_analytics
FOREIGN DATA WRAPPER clickhouse_fdw
OPTIONS (
    driver 'binary',
    host 'clickhouse.example.com',
    dbname 'analytics'
);

CREATE USER MAPPING FOR CURRENT_USER
SERVER ch_analytics
OPTIONS (user 'default');

CREATE SCHEMA ch;
IMPORT FOREIGN SCHEMA analytics
FROM SERVER ch_analytics
INTO ch;

これでPostgres側からClickHouseのテーブルをforeign tableとして見られるようになります。

もちろん、何でも魔法のように速くなるわけではありません。pg_clickhouse は、分析クエリをClickHouse側へpushdownすることを狙った拡張です。pushdownされない処理はPostgres側に戻る可能性があります。ここは実際のクエリで確認が必要です。

構成としては3パターンある

PostgresとClickHouseを組み合わせるなら、大きく3パターンあります。

パターン	説明	向いている場面
バッチ連携	定期的にPostgresからClickHouseへ入れる	日次集計で足りる
CDC連携	Postgresの変更をClickHouseへ継続的に流す	リアルタイムに近い分析がほしい
pg_clickhouse	PostgresからClickHouseをクエリする	既存SQLやアプリの移行負担を減らしたい

最初から全部入れる必要はありません。

小さく始めるなら、まずイベントログを直接ClickHouseへ入れる。そのあと、Postgresの注文やユーザーデータが必要になったらCDCを考える。既存のPostgres向け分析SQLを動かしたいなら pg_clickhouse を検証する。

この順番が現実的だと思います。

AIアプリだと何がうれしいか

AIアプリでは、ログの量が増えやすいです。

1回のユーザー操作で、検索、rerank、model call、tool call、評価ログが出ます。モデルを変えれば比較したくなるし、プロンプトを変えれば前後の品質を見たくなります。

Postgresだけに全部入れると、アプリ本体のDBがログ置き場になってしまいます。

ClickHouseを足すと、次のような分析を逃がせます。

SELECT
    model,
    count() AS requests,
    quantile(0.95)(latency_ms) AS p95_latency_ms,
    sum(input_tokens + output_tokens) AS total_tokens,
    countIf(status != 'success') AS errors
FROM ai_request_logs
WHERE event_time >= now() - INTERVAL 7 DAY
GROUP BY model
ORDER BY requests DESC;

これはPostgresで絶対にできない、という話ではありません。

でも、ログが増え続けるなら、ログ分析に向いたDBへ逃がしたほうがアプリ本体を守りやすい。

ReplacingMergeTree の注意

CDCでPostgresの更新をClickHouseへ流すときは、重複排除や更新表現をどう扱うかが大事です。

ClickHouseのPostgres CDC振り返り記事でも、Postgresユーザーが ReplacingMergeTree の挙動を理解し、FINAL 句やより高度なパターンでdeduplicationを明示的に考える必要があると説明されています。³

つまり、CDCで流したらPostgresと完全に同じ感覚で読める、とは考えないほうがいい。

たとえば、注文データを分析するなら次を決めます。

ClickHouse側では最新行だけを見たいのか
更新履歴も分析したいのか
削除をどう表現するのか
FINAL を使うクエリを許容するのか
集計用のmaterialized viewで確定値を作るのか

Postgresの正規データとClickHouseの分析データは、同じものではありません。ClickHouse側は分析用の投影として扱うと事故りにくいです。

最初に見るチェックリスト

導入前に、次は見ておきたいです。

データ設計

どのテーブルをClickHouseに流すか
個人情報や秘密情報を流さない設計になっているか
更新履歴を残すか、最新状態だけを見るか
削除をどう扱うか
ClickHouse側のORDER BYをどう決めるか

CDC

初回ロードにどれくらい時間がかかるか
レプリケーション遅延を監視できるか
スキーマ変更をどう扱うか
障害時にどこから再開できるか
hard deleteを扱う必要があるか

クエリ

既存の分析SQLを書き換えるか
pg_clickhouse で逃がせるクエリがあるか
pushdownされないクエリをどう見つけるか
FINAL が必要なクエリを把握しているか
ダッシュボード用の集計テーブルを作るか

運用

Postgres側の負荷が増えすぎないか
ClickHouse側のストレージが増え続けないか
権限管理をPostgresとClickHouseでどう分けるか
監査ログをどれくらい保存するか
失敗したパイプラインを誰が直すか

まとめ

Postgresを捨てる必要はありません。

むしろ、トランザクションが大事なところはPostgresに残したほうがいいです。ユーザー、課金、権限、注文、設定。ここはPostgresが得意です。

一方で、ログ、集計、AIリクエスト、検索履歴、顧客向けダッシュボードまでPostgresだけで抱えると、だんだん苦しくなります。

そこでClickHouseを足す。

Postgresは正規データの記録元。ClickHouseは大量に読む分析基盤。CDCで橋をかける。必要なら pg_clickhouse でPostgres側からClickHouseを呼ぶ。

この構成は、派手ではありません。でも現実的です。

AI時代のDB設計は、何でも1つのDBに入れる話ではなくなってきています。Postgresを守るためにClickHouseを足す。そう考えると、使いどころが見えてきます。

参考