この記事は、PostgreSQLとClickHouseをLLMログ分析の観点で比べるメモです。どちらかを雑に持ち上げる話ではありません。2026年6月9日時点の公式ドキュメントと公開情報をもとに、同じ評価軸で見ます。
はじめに
LLMアプリを作ると、ログが増えます。
ユーザーの質問、モデル名、トークン数、レイテンシ、エラー、検索された文書、tool call、評価結果。最初は全部PostgreSQLに入れても困りません。むしろ、アプリの本体DBがPostgresなら、同じ場所に置くのが自然です。
でも、ログが増えてくると気になります。
- モデル別のp95レイテンシを見たい
- 日次のトークン消費を見たい
- 顧客ごとの利用量を出したい
- プロンプト変更後の失敗率を見たい
- RAGの検索件数と回答失敗率を見たい
こういうクエリを本番DBに投げ続けてよいのか。
そこでClickHouseが候補に入ります。
ただ、ここで「ClickHouseのほうが速いから全部移そう」と言うと雑です。PostgresにはPostgresの強さがあります。ClickHouseにも弱いところがあります。
この記事では、PostgreSQLとClickHouseを同じ数だけ褒めて、同じ数だけ注意します。
比較する前提
想定するのは、LLMアプリのログ分析です。
| 列 | 例 |
|---|---|
| event_time | リクエスト時刻 |
| tenant_id | 顧客や組織 |
| user_id | ユーザー |
| model | モデル名 |
| route | chat、rag、agent |
| status | success、error、timeout |
| latency_ms | レイテンシ |
| input_tokens | 入力トークン |
| output_tokens | 出力トークン |
| cost_usd | 推定コスト |
評価軸は次にします。
| 評価軸 | 見ること |
|---|---|
| 書き込み整合性 | アプリの正規データを安全に扱えるか |
| 大量集計 | ログを期間やモデルで集計しやすいか |
| 運用の慣れ | チームが扱いやすいか |
| AIログ分析 | モデル、トークン、失敗率を追いやすいか |
| スケール | データ量が増えたときに伸ばしやすいか |
| 事故りにくさ | 使い方を間違えたときの痛み |
PostgreSQLのいいところ
1. アプリの正規データを置きやすい
ユーザー、権限、課金、注文、設定のようなデータはPostgresに置きやすいです。
トランザクションが必要な処理、外部キーを張りたい処理、更新と参照が混ざる処理では、Postgresのほうが自然です。PostgreSQLのドキュメントでも、トランザクションは複数の処理をまとめて「全部成功するか、全部なかったことにする」ための基本機能として説明されています。1
LLMアプリでも、ユーザーや課金まわりをClickHouseに寄せる理由はあまりありません。
2. 小さく始めやすい
最初からDBを2つ持つと、運用が増えます。
Postgresだけで始めると、アプリの構成がシンプルです。ログが少ないうちは、モデル別の集計や日次コストくらいならPostgresでも十分できます。
3. SQLと周辺ツールに慣れている人が多い
Postgresは使える人が多いです。
ORM、マイグレーション、管理ツール、バックアップ、監視。チームに経験があるなら、最初の運用コストは低くなります。
4. JSONもベクトルも扱える
Postgresは json / jsonb 型を扱えます。PostgreSQLのドキュメントでは、jsonb は分解されたバイナリ形式で保存され、処理時に再パースが不要で、インデックスも使えると説明されています。2 pgvectorを入れれば、ベクトルを保存して類似検索もできます。pgvectorはHNSWとIVFFlatのインデックスをサポートしています。3
小さなRAGなら、Postgresだけで文書、メタデータ、embedding、検索ログをまとめる構成も現実的です。
5. 一貫性を保ちやすい
ログとアプリデータが同じDBにあると、トランザクション境界を考えやすいです。
たとえば、課金イベントとLLM実行ログを同時に確定したい場合、同じPostgresに置くほうが分かりやすい。
6. 失敗したときに直しやすい
Postgresは運用知見が多いDBです。
変なクエリを書いた。インデックスを貼り忘れた。VACUUMが詰まった。こういう問題に対して、調べる先も相談できる人も多いです。
PostgreSQLのつらいところ
1. 大量ログの集計を本番DBに投げたくない
LLMログは増えます。
モデル別p95、日次コスト、テナント別利用量、失敗率。こういう集計を本番DBに投げ続けると、アプリ本体の読み書きに影響する可能性があります。
Postgresが悪いのではなく、役割が重くなりすぎる。
2. インデックス設計がログ分析に引っ張られる
分析用のクエリが増えると、インデックスも増えます。
event_time、tenant_id、model、route、status。見る軸が増えるほど、どこまでインデックスを貼るか悩みます。書き込みも重くなります。
3. ログ保存期間を伸ばしにくくなる
90日で足りたログが、あとから1年ほしくなることがあります。
LLMの品質改善では、過去のプロンプト変更やモデル変更の影響を見たくなるからです。Postgresに長期ログを抱え込むと、バックアップやメンテナンスも重くなります。
4. 顧客向けダッシュボードが怖い
社内の分析なら、重いクエリを避ける運用もできます。
顧客向けダッシュボードはそうはいきません。複数のユーザーが同時に開き、似た集計を何度も投げます。本番DBに直接当てるのは怖いです。
5. 列指向DBの読み方には勝ちにくい
LLMログ分析では、特定の列だけを大量に読みます。
event_time、model、latency_ms、input_tokens、output_tokens。このような集計では、列指向DBであるClickHouseの読み方が合います。ClickHouseは列ごとにデータを保存し、分析クエリで必要な列だけを読みやすい設計です。4
6. ログ分析とトランザクションを同居させると境界が曖昧になる
Postgresに全部入ると、最初は楽です。
でも、アプリ本体のDBなのか、ログ基盤なのか、分析基盤なのかが曖昧になります。境界がないと、あとで分離したいときに大変です。
ClickHouseのいいところ
1. 大量ログの集計に向いている
ClickHouseはOLAP向けの列指向DBです。
LLMログのように、増え続けるイベントを期間、モデル、テナントで集計する用途に合います。
2. MergeTree の並びをクエリに合わせられる
ClickHouseでは、多くの場合 MergeTree 系のテーブルを使います。
ORDER BY はデータの並びやスパースインデックスに効きます。公式の説明でも、ClickHouseの主キーは各行ではなく一定粒度の位置を指すスパースな仕組みとして説明されています。4
LLMログなら、event_time、tenant_id、model などをよく使うクエリに合わせて設計できます。
3. 日次集計を作りやすい
よく見る集計はmaterialized viewに逃がせます。
たとえば、日別、モデル別、ルート別にリクエスト数、エラー数、トークン数、コストをまとめる。ClickHouseのmaterialized viewは、挿入時にSELECT結果をtarget tableへ書く用途で使えます。5
4. ログ保存を伸ばしやすい
ClickHouseは大量データを読む用途に寄せやすいです。
生ログは90日、日次集計は1年、個人情報を含まない統計はさらに長く残す。こういう設計をPostgres本体から切り離して考えられます。
5. AIログとRAGログを同じSQLで見やすい
モデル別レイテンシ、RAG検索件数、tool call回数、失敗率。
これらを同じテーブルや近いテーブルで見られると、改善が速くなります。検索が悪いのか、モデルが悪いのか、ツールが遅いのかを切り分けやすい。
6. Postgresを守れる
これが一番大きいです。
ClickHouseを足す目的は、Postgresを捨てることではありません。アプリの正規データを持つPostgresに、重い分析まで背負わせないことです。
ClickHouseのつらいところ
1. PostgresのOLTP用途の置き換えではない
ClickHouseはOLAP向けです。
ユーザー、課金、注文、権限のようなデータを置く場所としては、Postgresのほうが自然です。ClickHouseは、増え続けるイベントやログを分析する側に置いたほうが使いやすいです。
2. ORDER BY を雑に決めると効きにくい
ClickHouseは速いです。
でも、何も考えずに速くなるわけではありません。よく見る条件に合わせて ORDER BY を決めないと、期待したほど効かないことがあります。
3. 更新や削除の感覚がPostgresと違う
ログ中心なら問題になりにくいです。
ただ、Postgresの更新データをCDCで流す場合は、削除、重複、最新行の見方を考える必要があります。ReplacingMergeTree や FINAL の理解が必要になる場面もあります。
4. 学習コストがある
ClickHouseにはClickHouseの作法があります。
MergeTree、パーティション、ORDER BY、materialized view、LowCardinality、TTL。Postgresだけを触ってきたチームなら、最初に覚えることはあります。
5. 小さなアプリでは過剰になる
ログが少ないなら、Postgresだけで十分です。
DBを増やすと、監視、バックアップ、権限、障害対応も増えます。小さい段階で無理にClickHouseを入れると、速さより運用の重さが勝つこともあります。
6. 正規データと分析データのズレを受け入れる必要がある
PostgresからClickHouseへ流す構成では、分析側が少し遅れることがあります。
顧客向けの集計なら許容できる場合もあります。請求確定や権限判定では許容できない場合もあります。この線引きが必要です。
まとめると
| 観点 | PostgreSQL | ClickHouse |
|---|---|---|
| 正規データ | 得意 | 苦手 |
| トランザクション | 得意 | OLTPの置き換えには向かない |
| 少量ログ | 十分 | やや過剰 |
| 大量ログ集計 | つらくなる | 得意 |
| ダッシュボード | 本番DBに当てると怖い | 分析用に置きやすい |
| RAGログ分析 | 小規模なら十分 | 増えるほど向く |
| 運用の慣れ | 人が多い | 学習が必要 |
自分ならこう分ける
| データ | 置き場所 |
|---|---|
| ユーザー | PostgreSQL |
| 権限 | PostgreSQL |
| 課金 | PostgreSQL |
| LLMリクエストログ | ClickHouse |
| RAG検索ログ | ClickHouse |
| tool callログ | ClickHouse |
| 日次集計 | ClickHouse |
| 顧客向け分析画面 | ClickHouse |
Postgresはアプリの記録元。
ClickHouseはログと分析の逃がし先。
この分け方が、いちばん事故りにくいと思います。
終わりに
PostgreSQLとClickHouseは、どちらが上かで選ぶものではありません。
Postgresは、アプリの正規データを守るDBです。ClickHouseは、増え続けるログを読んで集計するDBです。
LLMアプリでは、ログが増えます。モデル、プロンプト、RAG、tool call、評価。見たい軸も増えます。
その分析をPostgresだけで抱え続けるか、ClickHouseへ逃がすか。
判断は「速そう」ではなく、どのクエリを誰が何回見るのかで決めたいです。