この記事は、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、複数の距離関数が説明されています。¹

いいところ

既存の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が説明されています。²

いいところ

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ではいちばん事故りにくいと思います。

参考