ベクトルDB / ストレージ

ClickHouse可観測性

追記が中心で値の種類が多いデータ——モデル呼び出しごとに1行を記録し、後からモデル名やコスト、エラーで絞り込む——に向いた列指向エンジンです。Langfuseは2024年12月にトレースの保存先をPostgreSQLからClickHouseへ移し、2026年1月にはClickHouseがLangfuseを買収したため、セルフホストの可観測性基盤を組むと下層にこれが入る構成が増えています。一方でトランザクション処理には向かず、更新や削除は行の書き換えではなく列パート単位の再作成になるため、アプリケーションの状態を書き込む先ではなく、エージェントの実行記録が着地する場所として扱ってください。

MilvusベクトルDB

ストレージと計算を分離し、インデックス構築とクエリを独立にスケールさせる設計です。数十億ベクトル規模で必要になるアーキテクチャがここにあります。その能力は運用負荷と引き換えであり、数百万ベクトル未満の規模ではより単純な選択肢のほうが適しています。

FaissベクトルDB

中心にあるのは、ベクトル集合を保持して検索する索引です。索引構造が何十種類も存在するのは、トレードオフが実在するからです。検索時間、結果の質、1ベクトルあたりのメモリ、構築にかかる時間、そして学習用データが必要かどうかが互いに競合します。一部の方式は圧縮表現だけを保持し元のベクトルを持たないため、1台のサーバーで数十億件規模に届きます。サーバー機能、絞り込み、アクセス制御はここにはありません。それらは、この上に築かれたデータベースが足している部分です。

QdrantベクトルDB

Rust製で、メタデータによる絞り込みを検索後ではなく検索中に適用する設計です。大規模なコレクションのうち狭い範囲だけをエージェントが検索する場面で、結果の正しさを保てるかどうかがこの違いに現れます。ローカル開発用の単一コンテナから分散クラスタまで、同じ構成で拡張できます。

ChromaベクトルDB

検索を動かすまでの摩擦が最も少ない選択肢です。サーバーの構築もクラスタのサイジングも不要です。そのためプロトタイプや小規模な本番負荷には非常に適しています。一方で、どの規模で手狭になるかは、遭遇してから慌てるのではなく事前に計画しておくべき論点です。

pgvectorベクトルDB

ベクトルが列の型になり、そこから先はPostgresがすでにできることがそのまま使えます。近傍検索はORDER BYとLIMIT、絞り込みは同じプランナが評価するWHERE句、埋め込みとその元になる行は1つのトランザクションで書かれ、既存のバックアップ・レプリカ・ロールがベクトルにも適用されます。引き換えに手放すのは、専用エンジンが備える運用機構です。コレクションのシャーディングやテナント分離はここにはなく、索引の構築は同じマシン上で他の処理と資源を奪い合います。

WeaviateベクトルDB

素の索引との違いは3点あります。オブジェクトを属性ごと保存するため絞り込みが検索の一部になり、後段のフィルタではなくなること。ベクトライザーモジュールが書き込み時に埋め込みを生成でき、ずれがちな別パイプラインを持たずに済むこと。そしてマルチテナンシーが正式な構成要素で、テナントごとに専用のシャードを持ち、停止状態やオブジェクトストレージへの退避を選べることです。ただし自分で運用するデータベースではあります。1プロセス内に埋め込む索引が欲しいだけなら、必要以上の機構になります。