この記事は、RAGで使うDBをPostgres、ClickHouse、専用ベクトルDBの3つで比べるメモです。どれが絶対に正解という話ではありません。小さく始める場合、ログ分析まで見る場合、ベクトル検索に寄せる場合で選び方が変わります。記述は2026年6月9日時点の公式情報をもとにしています。
はじめに
RAGを作ると、まずベクトル検索に目が行きます。
文書を分割する。embeddingを作る。近い文書を取る。LLMに渡す。
この流れは分かりやすいです。
でも、RAGを運用すると、ベクトル検索だけでは足りなくなります。
- どの文書が検索されたか
- 何位で返ったか
- その文書は回答に使われたか
- ユーザーは満足したか
- 失敗した質問にはどんな傾向があるか
- モデル変更後にコストや品質がどう変わったか
こうなると、DB選びは「ベクトルが検索できるか」だけでは決まりません。
この記事では、Postgres、ClickHouse、専用ベクトルDBを同じ軸で比べます。
比較する3つ
| 選択肢 | ざっくり |
|---|---|
| PostgreSQL + pgvector | 既存DBにベクトル検索を足す |
| ClickHouse | ログ分析とベクトル検索を同じ分析基盤で見る |
| 専用ベクトルDB | ベクトル検索に寄せる |
ここでは特定の専用ベクトルDB名には寄せません。
評価軸は次です。
| 評価軸 | 見ること |
|---|---|
| 小さく始めやすいか | 構成を増やさずに済むか |
| ベクトル検索 | HNSWやIVFFlatなどの近似検索を使えるか |
| メタデータ絞り込み | tenant、公開範囲、カテゴリで絞れるか |
| ログ分析 | 検索ログや評価ログを集計しやすいか |
| 既存DBとの相性 | アプリの正規データとつなげやすいか |
| 運用 | バックアップ、権限、監視を扱いやすいか |
PostgreSQL + pgvector
Postgresにpgvectorを入れる構成です。
pgvectorは、Postgresでベクトルを保存し、類似検索を行うための拡張です。READMEでは、exact / approximate nearest neighbor search、HNSW、IVFFlat、複数の距離関数が説明されています。1
いいところ
- 既存のPostgresに足せる
- 文書、メタデータ、embeddingを同じDBで扱える
- 権限やテナント情報とJOINしやすい
- 小さなRAGなら構成がシンプル
- Postgresの運用知識をそのまま使いやすい
つらいところ
- 大量ログ分析までPostgresに乗せると重くなる
- ベクトル検索と分析クエリが同居する
- インデックス設計やVACUUMなど、Postgres側の運用に影響する
- RAGの失敗ログを長期保存すると本体DBが太る
- ベクトル検索専用の機能だけを期待すると物足りないことがある
向いている場面
小さく始めたいときです。
社内FAQ、個人開発、小規模なRAG。文書量が大きくなく、既存のPostgresに乗せたいなら、自然な選択です。
ClickHouse
ClickHouseはOLAP向けの列指向DBです。
ログ分析に強く、近年はベクトル検索も扱えるようになっています。ClickHouse 25.8以降では vector similarity index が使えます。ドキュメントでは、現時点のインデックスタイプとしてHNSWが説明されています。2
いいところ
- RAG検索ログや評価ログを大量に集計しやすい
- メタデータ、ログ、ベクトルをSQLで一緒に扱いやすい
- モデル別コストやレイテンシを集計しやすい
- 失敗ログの傾向分析に向く
- Postgres本体から重い分析を逃がせる
つらいところ
- アプリの正規データを置くDBではない
- PostgresのようなOLTP用途には向かない
-
ORDER BYやパーティションの設計が必要 - ベクトル検索だけを極めたい用途では専用DBと比較が必要
- vector similarity index のメモリや更新負荷を見る必要がある
向いている場面
RAGの改善ログまで見たいときです。
検索が当たったか。回答に使われたか。評価が下がった質問はどれか。モデル変更後にコストがどう変わったか。
こういう分析をしたいなら、ClickHouseは置きやすいです。
専用ベクトルDB
専用ベクトルDBは、ベクトル検索に寄せた選択肢です。
HNSWなどの近似検索、フィルタ、分散、スケール、検索APIが整っているものが多いです。
いいところ
- ベクトル検索を中心に設計されている
- 検索APIが使いやすいことが多い
- 大規模なembedding検索に寄せやすい
- RAG基盤としてのサンプルやSDKが多い
- ベクトル検索担当として役割を分けやすい
つらいところ
- アプリの正規データとは別DBになる
- 検索ログや評価ログの分析は別基盤が必要になりやすい
- メタデータの複雑な集計は向かないことがある
- Postgresとの同期を考える必要がある
- 小さなRAGでは構成が大げさになることがある
向いている場面
ベクトル検索そのものが中心のプロダクトです。
大量のembeddingを高速に検索したい。検索APIをシンプルに使いたい。RAGの検索部分をアプリ本体から独立させたい。そういう場合は専用ベクトルDBが合います。
同じ軸で見る
| 観点 | PostgreSQL + pgvector | ClickHouse | 専用ベクトルDB |
|---|---|---|---|
| 小さく始める | 強い | やや重い | やや重い |
| ベクトル検索 | 小規模から中規模で扱いやすい | 分析と一緒に扱える | 強い |
| メタデータ管理 | 強い | 分析向き | 製品次第 |
| ログ分析 | 増えるとつらい | 強い | 別基盤が必要になりやすい |
| 正規データ | 強い | OLTP用途には向かない | 向かない |
| RAG改善 | 小規模なら十分 | 失敗分析まで見やすい | 検索品質に寄せやすい |
| 運用 | 既存Postgresに乗せやすい | 学習が必要 | サービスや製品次第 |
自分ならこう選ぶ
小さく始めるならPostgres
最初のRAGなら、Postgres + pgvectorでよいことが多いです。
文書、メタデータ、embedding、ユーザー情報を同じDBで扱える。構成が少ない。チームがPostgresに慣れている。
これは大きいです。
失敗ログまで分析したいならClickHouse
RAGは、検索できれば終わりではありません。
検索された文書、順位、スコア、回答、評価、再質問、離脱。ここまで分析したいなら、ClickHouseが効きます。
ClickHouseは、ベクトル検索のためだけに見るより、RAGの観測台として見ると使いどころが分かりやすいです。
ベクトル検索が主役なら専用ベクトルDB
embedding検索そのものがプロダクトの中心なら、専用ベクトルDBを検討します。
検索性能、検索API、分散、運用機能。ここを重く見るなら、専用DBのほうが合うことがあります。
ありがちな失敗
ベクトル検索だけ見てDBを選ぶ
RAGで本当に困るのは、検索できないことだけではありません。
検索された文書が悪いのか。LLMが使わなかったのか。そもそも文書が足りないのか。評価ログがないと分かりません。
最初から大きくしすぎる
小さなRAGに、Postgres、ClickHouse、専用ベクトルDB、キュー、CDCを全部入れると、運用が先に重くなります。
最初はPostgres。ログが増えたらClickHouse。検索が主役になったら専用ベクトルDB。
この順番でも遅くありません。
正規データと検索データを混ぜすぎる
ユーザーや権限は正規データです。
embeddingや検索ログは分析や検索のためのデータです。
同じ場所に置ける場合でも、役割は分けて考えたほうがいいです。
まとめ
RAGのDB選びは、PostgresかClickHouseかベクトルDBか、という単純な話ではありません。
小さく始めるならPostgres + pgvector。
RAGの失敗ログまで分析したいならClickHouse。
ベクトル検索そのものが主役なら専用ベクトルDB。
このくらいに分けて考えると、選びやすくなります。
自分なら、最初はPostgresで始めます。ログが増えて、改善のための集計が重くなったらClickHouseを足します。検索そのものが事業の中心になったら、専用ベクトルDBも比較します。
DB選びは、最初から正解を当てるゲームではありません。
どのデータが増えるか。どのクエリを何度も見るか。どこに整合性が必要か。
そこから決めるのが、RAGではいちばん事故りにくいと思います。