この記事は、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は分析を担当する、という組み合わせが紹介されています。1
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を支える形になっています。2
公式の振り返り記事では、PeerDBは2024年7月にClickHouseが買収し、ClickPipesのPostgres CDC connectorを動かすエンジンになったと説明されています。3
CDCを入れれば何も考えなくていい、という話ではありません。スキーマ変更、削除、重複排除、遅延、初回ロード、障害時の再開を設計する必要があります。
どのデータを流すか
全部流す必要はありません。
むしろ、最初は絞ったほうがいいです。
| 流す候補 | 理由 |
|---|---|
| 注文や決済の履歴 | 顧客別、期間別の分析に使う |
| イベントログ | アプリ本体DBに残すと膨らみやすい |
| AIリクエストログ | モデル別コスト、失敗率、レイテンシを見る |
| 検索ログ | RAGや全文検索の改善に使う |
| 監査ログ | あとから説明するために残す |
逆に、次のようなものは慎重に扱います。
| データ | 注意点 |
|---|---|
| 個人情報 | ClickHouse側で誰が見られるかを決める |
| APIキーやトークン | そもそも流さない |
| 書き込み直後に厳密な整合性が必要なデータ | 分析側に逃がすだけにする |
| 頻繁に更新される小さなマスタ | ClickHouseに流す意味が薄い場合がある |
ClickHouseは大量に読むところで強い。そこに寄せるデータを選ぶのが大事です。
pg_clickhouse という別ルート
もう1つ見ておきたいのが pg_clickhouse です。
pg_clickhouse は、PostgreSQLからClickHouse上のデータをクエリするためのPostgres拡張です。ClickHouse公式ブログでは、Postgres側のSQLやアプリケーションコードを書き換える負担を減らし、分析クエリの実行をClickHouseへ押し出すことを狙っていると説明されています。4
最初の公開時は v0.1.0 でした。GitHubのREADMEでは、PostgreSQL 13以降、ClickHouse v23以降をサポートするとされています。2026年6月8日時点では、GitHub上の最新リリースは v0.3.1 です。5
イメージとしては、こういう使い方です。
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を明示的に考える必要があると説明されています。3
つまり、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を足す。そう考えると、使いどころが見えてきます。
参考
-
PostgreSQL + ClickHouse as the Open Source unified data stack | ClickHouse Blog ↩
-
Postgres CDC connector for ClickPipes is now Generally Available | ClickHouse Blog ↩
-
Postgres CDC in ClickHouse, A year in review | ClickHouse Blog ↩ ↩2
-
Introducing pg_clickhouse: A Postgres extension for querying ClickHouse | ClickHouse Blog ↩