ベクトルデータベースおすすめ10選【2026年】pgvector・Qdrant・Pinecone・Weaviateを比較

すでにPostgresを使っている大半のプロダクトチームにとって、最適なベクトルデータベースはpgvectorです。フィルター付きベクトル検索が難所ならQdrant、運用を極力なくしたいならPinecone、キーワード検索が今もプロダクトの中心ならElasticsearchが有力です。2026年7月30日に確認した公開済み有料プランの最低料金は、Redis Essentialsの月額$5からElastic Cloud Hosted Standardの月額$99までですが、誤ったデータモデルを選ぶコストはサブスクリプション料金を上回ります。

おすすめベクトルデータベースを一覧比較

最も安全な初期方針は、実測した検索要件を満たせなくなるまで、ベクトルをアプリケーションデータと同じ場所に置くことです。専用ベクトルデータベースを導入すれば、フィルター検索、スケール、運用の簡素化を改善できる可能性があります。一方で、同期、バックアップ、権限管理、障害対応の責任を伴う、永続データシステムがもう1つ増えます。

以下の料金はすべて、各ベンダーの公開料金ページで2026年7月30日に確認しました。「最低料金」は公開されている最安の入口を指し、あらゆる本番ワークロードをそのプランで処理できるという意味ではありません。

判断基準を最短でまとめると、アーキテクチャで決まります。

• 正とするデータがPostgresにあるなら、まずpgvectorを選びます。
• 専用のオープンソースエンジンが必要なら、Qdrantを選びます。
• 料金の最小化よりデータベース運用をなくす価値が大きいなら、Pineconeを選びます。
• 大規模で負荷の波が激しいなら、**turbopuffer**とPineconeの料金を比較します。
• ハイブリッド検索の関連性をプロダクト側で細かく調整したいなら、**Weaviate**を選びます。
• マルチベクトルのスケールが難所なら、Zilliz Cloudを選ぶか、分散システムを運用できるチームでMilvusを動かします。
• アプリケーションがすでにMongoDB、Elasticsearch、またはRedis上にあるなら、2つ目のデータベースを追加する前に、そのシステムのベクトル検索を使います。
• ローカルでの試作が目的なら、**Chroma**を選び、本番については改めて判断します。

どれを選ぶべきかは、1つの要件で逆転します。フィルター付き近似検索がレイテンシ予算内で十分な候補を返せないなら、pgvectorは不向きです。別サービスを運用したい人がおらず、サイジング前にはCloud料金を予測できないなら、Qdrantは不向きです。使用量単位のコストや制御要件が運用削減効果を上回るなら、Pineconeは不向きです。狭い類似検索機能のために検索プラットフォーム一式を買うことになるなら、Elasticsearchは不向きです。

ベクトルデータベース比較で重視した選定基準

ベクトルデータベースは、テキスト、画像、音声などを数値で表した埋め込みを保存し、類似度の近い項目を検索します。定義は単純ですが、本番環境での選択は単純ではありません。

今回は、異なるワークロードでそれぞれ強みを持つ10製品を選びました。同じ判断を繰り返すだけの製品は加えていません。評価したのは、後から変更すると高くつく次の7つの制約です。

• データグラビティ： 正本となるドキュメント、ユーザー、権限、業務レコードがどこにあるか。
• フィルター後の再現率： テナント、権限、地域、ステータス、時間の条件を適用した後も、十分な関連結果を返せるか。
• ハイブリッド検索： 密な意味検索と疎ベクトル検索またはキーワード検索をどう組み合わせるか。
• 書き込み特性： 更新が検索可能になるまでの時間と、インデックス作成、キャッシュウォームアップ、フェイルオーバー中の挙動。
• 運用負荷： レプリカ、アップグレード、バックアップ、容量、インデックスメモリ、障害対応をチームが担うか。
• 課金単位： ストレージ、読み書き単位、論理バイト、クラスタリソース、サポート契約、基本料金のどれか。
• 撤退コスト： 1つの拡張機能を変えるだけか、インデックスを移行するのか、2つのデータベース間の同期経路を作り直すのか。

各製品について行ったのは料金調査と分析であり、実機による負荷テストを実施したとは主張していません。次元数、再現率の目標、フィルター、ハードウェア、インデックス設定、データ分布が変われば結果も変わるため、ベンダーごとのベンチマークをそのまま比較することはできません。これらの条件を統一していないベンチマークは、ストップウォッチ付きの広告にすぎません。

この比較から得られた独自の結論は明快です。移行を決める万能なベクトル件数のしきい値はありません。フィルター後の再現率、レイテンシ、書き込みの可視性、インデックスメモリ、運用負荷のいずれかで、現行システムが実測したサービスレベルを満たせなくなったときに移行します。厳しい権限フィルターを持つチームは、はるかに大きな未フィルターのコーパスを扱うチームより先に、現行アーキテクチャの限界へ達することがあります。

1. pgvector：Postgres利用チームに最適な総合候補

pgvectorは、すでに保護、バックアップ、クエリ、運用に習熟しているPostgresへ類似検索を追加できるため、多くのアプリケーションチームにとって最適なベクトルデータベースです。顧客、ドキュメント、権限、トランザクションレコードと埋め込みを同じ場所に置けるので、同期境界を丸ごと1つ取り除けます。

具体的に合うのは、ドキュメント、アカウント所属、利用権限、監査レコードをPostgresに保存するB2B SaaSです。認可メタデータを別サービスへコピーし、次のクエリまでにすべての更新が届くことを期待する代わりに、同じリレーショナルデータへ結合やフィルターをかけて検索できます。この構造の単純さは、合成データによる近傍探索ベンチマークで首位を取ることより重要な場合が少なくありません。

pgvectorは正確な近傍探索と近似近傍探索に対応し、Postgres 13以降で動作します。ACIDトランザクション、ポイントインタイムリカバリ、JOIN、レプリカ、使い慣れた監視といった、Postgres本来の利点も維持します。近似インデックスは2系統です。

• HNSWは多層グラフ型のインデックスです。速度と再現率のバランスに優れますが、構築が遅く、より多くのメモリを使います。
• IVFFlatは転置ファイル型のインデックスです。構築が速く、メモリ使用量も少ない一方、同程度の再現率を目標にするとクエリ性能が下がります。

検索レイテンシを重視する本番環境では、まずHNSWを検討するのが妥当です。構築時間、メモリ、バルクロードの工程が支配的なら、IVFFlatにも検討価値があります。どちらを選んでも、アプリケーション固有のフィルターを使って再現率を測る必要はなくなりません。

限界が現れるのは、フィルター付き近似検索です。pgvectorでは、近似インデックスを走査した後にフィルターが適用されます。ドキュメントには分かりやすい例があります。条件に一致する行が10%で、HNSWのhnsw.ef_searchがデフォルト値の40なら、平均で一致するのは4行だけです。そのため、関連する行が存在していても、上位10件を要求した結果が10件未満になる可能性があります。

バージョン0.8.0では、フィルター後の結果が十分にそろうか走査上限に達するまで探索を続ける、反復インデックススキャンが追加されました。これは実効性のある改善ですが、無償ではありません。走査を増やせばレイテンシと処理量も増えます。フィルター値が少数かつ安定している場合は部分インデックスが有効です。多数のテナントやカテゴリを物理的に分ける妥当性がある場合は、パーティショニングが役立ちます。それでもサービスレベルを満たせないなら、専用エンジンの魅力が増します。

次元数の上限も明示されています。HNSWとIVFFlatがインデックス化できるvectorは最大2,000次元、halfvecは最大4,000次元、bitは最大64,000次元です。インデックスなしのvector型には最大16,000次元を保存できます。大半のテキスト埋め込みモデルは余裕をもって収まりますが、高次元またはマルチベクトル設計では、採用前にインデックス表現を確認すべきです。

ハイブリッド検索は実現できますが、完成品として用意されているのではなく、自分たちで組み立てます。pgvectorとPostgres全文検索を組み合わせれば、同じデータベースで意味検索と字句検索を実行し、順位を統合できます。利点は、制御を保ったままデータモデルを1つにできることです。その代わり、関連性の調整、順位統合、評価はアプリケーション側の仕事として残ります。

最適な用途： 正本データがすでにPostgresにあるSaaS、社内ツール、RAGシステム
際立つ強み： ベクトル、権限、リレーショナルフィルター、アプリケーションレコードを1つのトランザクションデータモデルで扱えること
料金： pgvectorはオープンソースソフトウェアで、ベンダーのサブスクリプションプランはありません。費用になるのは、アプリケーションデータベースですでに使うPostgresインフラ、ストレージ、レプリカ、バックアップ、エンジニアリング時間です。
無料トライアル： 対象外。拡張機能はオープンソースです

pgvectorを安全に本番導入する手順

検索処理がアプリケーションデータベースを圧迫しない限り、pgvectorは最有力候補であり続けます。類似検索をクリティカルパスへ入れる前に、計測の仕組みを整えてください。

1. 1

   本番のPostgresバージョンに拡張機能を導入する

   デプロイ先がPostgres 13以降であることを確認し、プロバイダーまたはパッケージシステム経由でpgvectorをインストールして、CREATE EXTENSION vectorで有効化します。拡張機能のバージョンは、独立して変動するアプリケーション依存関係ではなく、データベースリリースの一部として扱います。

2. 2

   元レコードと埋め込みを同じ場所に保存する

   権限とライフサイクルを管理する元レコードの行、またはそのレコードへの外部キーを持つ子行に埋め込みを置きます。将来モデルを移行するときに新旧のベクトルを識別できるよう、埋め込みモデルの識別子も保存します。

3. 3

   正確検索から始め、その後HNSWを追加する

   代表的なサンプルで正確検索を実行し、再現率の基準値を作ります。その基準値ができてからHNSWを追加し、レイテンシだけを追うのではなく、固定した評価セットに対して候補リストを調整します。

4. 4

   最も厳しい権限フィルターを検証する

   フィルターなしのクエリだけでなく、選択性が最も低いテナントまたは権限フィルターと、最も高いものを実行します。近似検索の結果件数が足りなければ反復スキャンを有効にし、新しいデータベースへ移る前に追加レイテンシを測ります。

5. 5

   サービスレベルを満たせなくなったときだけ分離する

   インデックスとパーティショニングを調整しても、フィルター後の再現率、インデックスメモリ、書き込み負荷、クエリレイテンシが定義済み目標を外れるなら、Qdrant、Pinecone、または別の専用エンジンへ移します。Postgresは正とするデータソースとして残し、同期契約を明示的に設計します。

バックエンド自体が未定なら、先にそちらを決めます。SupabaseとFirebaseの比較では、検索トラフィックが生まれる前から、アプリケーションのデータモデルによってベクトルデータベースの選択が決まり得る理由を解説しています。

2. Qdrant：専用オープンソース・ベクトルデータベースの最有力候補

Qdrantは、複雑なメタデータフィルター、オープンソースによる制御、大規模な自社運用Milvusより整理された運用形態を求めるチームに最適な専用ベクトルデータベースです。pgvectorのフィルター後の再現率が実測上の問題になったとき、最初に評価すべきシステムです。

具体的な用途は、すべてのクエリで意味的類似度と、アカウント、地域、ドキュメント種別、ステータス、アクセスグループなどの入れ子条件を組み合わせる、マルチテナント型のナレッジ製品です。Qdrantのペイロードには任意のJSONを格納でき、フィルターモデルはmust、should、must_not、範囲指定、一致条件、ネストしたキーに対応します。これにより、認可に沿った検索クエリを後処理ではなく、エンジン内部で扱えます。

Qdrantは、密ベクトルと疎ベクトルを使うハイブリッド検索にも対応します。バージョン1.10.0から利用できる多段クエリシステムでは、reciprocal rank fusion（RRF）またはdistribution-based score fusion（DBSF）で結果セットを統合できます。RRFは生のスコアではなく順位を統合するため、字句検索と密ベクトル検索のスコアが同じ尺度だと見なす必要がありません。

製品の提供形態は明確に2つあります。Qdrant OSSならソフトウェアを完全に制御できますが、インフラ負担はチーム側へ移ります。Qdrant Cloudはその多くを取り除く一方、リソースに基づくクラスタサイジングは必要です。Qdrantの公開料金ページによると、Free Tierは0.5 vCPU、1 GB RAM、4 GBディスクの単一ノードです。Standardは専用リソースの従量課金で、垂直・水平スケーリング、高可用性構成、バックアップと災害復旧、99.5%の稼働率SLAが加わります。

Premiumには、Qdrantが公開していない最低利用額があります。SSO、プライベートVPCリンク、追加サポート、99.9%の稼働率SLAが加わります。Hybrid Cloudでは顧客のインフラ上でQdrantの管理プレーンを動かし、Private Cloudは分離環境やエアギャップ環境を対象とします。どちらも営業担当との相談が必要です。

料金面の壁は予測です。StandardはvCPU、メモリ、クラスタストレージ、バックアップストレージ、有料推論トークンに応じ、時間単位で課金されます。サイジング後なら理解しやすいモデルですが、責任をもって月額を1つ提示することはできません。調達担当は、本番のベクトル次元数、レプリカ、ストレージ、書き込み速度を計算ツールへ入力し、小さいクラスタと大きいクラスタも試して、段階的な料金上昇を可視化すべきです。

アーキテクチャ上の壁は、どの専用エンジンにも共通します。Qdrantは派生データストアになり、元レコードは別の場所に残ります。削除、権限変更、再埋め込み、災害復旧、再実行には、すべて明確な契約が必要です。検索性能がその追加システムに見合うときだけ、Qdrantを選ぶ価値があります。

最適な用途： 入れ子のメタデータ、テナント、権限フィルターを伴う専用ベクトル検索
際立つ強み： 表現力の高いpayloadフィルターと、オープンソース／マネージドのデプロイ選択肢
料金： OSSはオープンソースです。Cloud Freeは0.5 vCPU、1 GB RAM、4 GBディスクを無期限で無料利用できます。Standardはリソースに応じた従量課金で、時間単位の請求です。Premiumには最低利用額があり、料金は要問い合わせです。Hybrid CloudとPrivate Cloudも見積もり制です。
無料トライアル： Cloud Free Tier

3. Pinecone：運用不要のマネージド・ベクトルデータベース

小規模なエンジニアリングチームが、オープンソースによる制御やインフラ費の最小化より、フルマネージドの検索サービスを重視するなら、Pineconeが最適です。容量、レプリカ、バックアップ、インデックスの可用性をベンダーの責任にできます。データベース運用が差別化要因ではないプロダクトなら、合理的な買い物になり得ます。

具体的に合うのは、データベース専任者を置かず、セマンティック検索やRAGをリリースする資金調達済みのプロダクトチームです。Pineconeは密ベクトル、疎ベクトル、全文検索の各インデックス、オンデマンドのサーバーレス基盤、本番プランのバックアップと復元、エンタープライズ向けデプロイ制御を提供します。ストレージが不要になるわけではありません。明確なAPIを持ち、運用対象の少ない検索サービスを買えることに価値があります。

Pineconeの公開料金体系には4つのプランがあります。Starterは無料で、データベースストレージ最大2 GB、月間200万write unit、月間100万read unit、1 GBのエグレスを含みます。Builderは月額固定$20で、ストレージ最大10 GB、500万write unit、200万read unit、10 GBのエグレスを含みます。

Standardは、使用料に充当される月額最低$50の契約です。$300分のクレジットが付く3週間のトライアルがあります。データベースストレージは月額$0.33/GBです。クラウドとリージョンにより、write unitは100万あたり$4〜$4.50、read unitは100万あたり$16〜$18です。エグレスは毎月100 GBまで含まれ、それ以降は$0.10/GBです。インポートは$0.25/GB、バックアップストレージは月額$0.10/GB、復元は$0.15/GBです。

Enterpriseでは月額最低額が$500へ上がります。ストレージは引き続き月額$0.33/GBですが、書き込みは100万あたり$6〜$6.75、読み取りは100万あたり$24〜$27へ上がります。このプランでは99.95%の稼働率SLA、BYOC、プライベートエンドポイント、顧客管理の暗号鍵、監査ログ、SCIM、HIPAA準拠、Proサポートが追加されます。

ハイブリッド検索は十分な機能を備えていますが、注意すべき技術上の条件があります。Pineconeが示す方法は、密ベクトルと疎ベクトルを1つのインデックスへ入れる、別々のインデックスへ入れる、ベクトルと全文フィールドを合わせたドキュメントスキーマを使う、という3つです。Pineconeは、多くのベクトルAPI用途で単一インデックス方式を推奨しています。リクエストが1回で済み、ベクトル同士の対応関係も維持できるためです。

ただし単一インデックス方式では、疎ベクトルと密ベクトルのスコア範囲が自動で正規化されません。正規化済み埋め込みの密ベクトル内積値はおおむね-1から1に収まる一方、BM25型の疎ベクトルスコアには上限がなく、結果を支配することがあります。アプリケーション側で明示的にalphaの重みを設定する必要があります。また、この方式では疎ベクトルだけのクエリを実行できず、統合済みの埋め込み生成やリランキングも使えません。インデックスを分ければこれらの選択肢は戻りますが、2回のクエリ、明示的な対応付け、統合、重複除去、リランキングが必要になります。

壁になるのはコストの可視性です。Pineconeは単価を公開しており、非公開より優れています。それでも、代表的な読み取り、書き込み、ストレージ、バックアップ、エグレスを把握しなければなりません。魅力的に見える最低月額$50も、クエリが継続的に流れたり、頻繁に再埋め込みしたりすれば別の請求額になります。リリース後に総使用量の帰属が分からなくなる前に、顧客別・ワークフロー別の使用単位を計測してください。

最適な用途： ベクトルクラスタを運用せず、本番検索をマネージドで使いたい小規模チーム
際立つ強み： API連携からベンダー運用の本番サービスへ移る、最も分かりやすい道筋
料金： Starterは無料です。Builderは月額固定$20。Standardは月額最低$50で、超過分は従量課金です。Enterpriseは月額最低$500で、読み書きの単価も高くなります。StandardとEnterpriseのデータベースストレージは月額$0.33/GBです。
無料トライアル： Starterは無料。Standardには$300分のクレジットが付く3週間のトライアルがあります

4. turbopuffer：大規模で負荷変動の大きいサーバーレス用途に最適

turbopufferは、検索頻度の偏りが大きく、常時メモリへ載せることが割に合わない大規模コーパスに適した専門サービスです。料金は論理ストレージ、書き込み、クエリ対象バイト数に連動し、どのプランにもデータベース機能がすべて含まれます。

具体的に合うのは、分離された顧客ネームスペースが多数あり、アクセスの少ないデータが長く残る一方、活動中の一部データには検索が集中するプロダクトです。クエリAPIは、近似・正確近傍探索、BM25全文検索、疎ベクトル、フィルター、並べ替え、ルックアップ、集約、複数クエリ検索に対応します。ベクトル検索とBM25検索を同時に実行し、RRFで統合するハイブリッド検索も可能です。

turbopufferの料金は、月額最低$16のLaunchから始まります。Scaleは最低額が$256へ上がり、HIPAA対応のBAA、SSO、監査ログ、IP許可リスト、専用Slackチャンネル、8-to-5サポートが加わります。Enterpriseは月額最低$4,096で、使用料に35%が上乗せされます。シングルテナント、BYOC、プライベートネットワーク、ネームスペース単位の顧客管理暗号鍵、24/7サポート、99.95%の稼働率SLAが含まれます。

課金単位は注意深く読む必要があります。2026年2月の変更後、クエリ対象データの基本料金は1 PBあたり$1、1クエリあたりの最低課金データ量は1.28 GBです。フィルター可能な属性は、書き込みとストレージについてベクトル列ごとに1回課金されます。フィルター不可の属性は、ベクトル列の数にかかわらず1回だけ保存されます。そのため、ドキュメント数が同じスキーマでも、多数の属性をフィルター可能にしたり、ベクトル列を追加したりすると料金は変わります。

明記されている制約は、大量更新時の書き込み可視性です。turbopufferによれば、99.8%を超えるクエリが一貫したデータを返します。まれにスケーリングやフェイルオーバーが起きると、約100 msの遅延が生じることがあります。ネームスペース内の未処理書き込みが128 MiBを超えると、その後の書き込みはインデックス化されてキャッシュへロードされるまで見えない場合があります。文書化された遅延は、小規模ネームスペースで数十秒、大規模ネームスペースで数十分に及び、大量書き込み後のデータが最大約1時間古い場合があります。

この挙動は、まとめて更新するナレッジコーパスなら許容できます。しかし、アクセス権の取り消しや緊急更新が次のクエリへ必ず反映されるべきワークフローには不向きです。単に「結果整合性」と片付けず、明示的な鮮度のサービスレベルが必要です。

集約にも別の境界があります。turbopufferは、ドキュメント数が100万を超えるネームスペースでレイテンシ重視の集約を推奨していません。検索エンジンとして使い、カウントやグループ化がAPIにあるからという理由で、分析データベースへ変えてはいけません。

最適な用途： アクセスの偏りが大きいマルチテナント型の大規模コーパスと、バイト課金を扱えるチーム
際立つ強み： 低い最低利用額で使える、ベクトル、BM25、疎ベクトル、ハイブリッド検索の幅広い機能
料金： Launchは月額最低$16。Scaleは月額最低$256。Enterpriseは月額最低$4,096に加え、使用料へ35%が上乗せされます。最低利用額を超えた分は、ストレージ、書き込み、クエリ対象バイト数で決まります。
無料トライアル： 料金ページに公開されたトライアルはありません

5. Weaviate：マネージド・ハイブリッド検索ツールキットの最有力候補

Weaviateは、検索処理をすべてアプリケーションコードで組み立てるのではなく、ハイブリッド検索、調整可能な関連性、マルチテナンシー、マネージド運用を1製品にまとめたいチームに最適です。単純な近傍探索サービスというより、検索プラットフォームとして機能します。

具体的に合うのは、完全一致するフレーズ、意味的類似度、新しさ、テナント分離のすべてが順位へ影響する、マルチテナント型のサポート検索やEC検索です。Weaviateのハイブリッド検索は、ベクトル検索の結果とBM25Fキーワード検索の結果を統合します。アプリケーションはalphaでキーワードとベクトルの比率を変え、統合方式を選び、スコアの説明を確認し、フィルターを適用して、プロパティまたは減衰関数で統合後の候補群をboostできます。

WeaviateのマネージドFreeプランは無期限で$0です。100,000オブジェクト、1 GBメモリ、10 GBディスク、1コレクション、最大3テナントを含みます。データモデルと関連性の評価には十分ですが、レプリケーションはなく、可用性はベストエフォートに限られます。

Flexは共有クラスタで月額$45からです。契約期間のない従量課金で、レプリケーション、RBAC、7日間のバックアップ保持、99.5%の稼働率目標、重大度1に対する翌営業日サポートを含みます。Premiumはプリペイド契約で月額$400からです。共有または専用デプロイ、共有環境で30日間または専用環境で45日間のバックアップ保持、SSO/SAML、最大99.95%の稼働率、重大度1に対する最短1時間のサポートを提供します。

ハイブリッド検索とマルチテナンシーは、3プランすべてで使えます。そのため、主要なクエリ形態がエンタープライズプラン限定だと後から判明することなく、Freeで検索モデルを検証できます。有料化の判断対象は、容量、信頼性、バックアップ、セキュリティ、リージョン、サポートです。

壁になるのは設定項目の多さです。関連性プラットフォームの調整項目が多いのは、誰かが管理しなければならないからです。alpha値、統合方式、トークナイザー、フィルター、ブーストルールは結果を改善できますが、6か月後には誰も説明できないランキングシステムを生む可能性もあります。関連性に関する変更は、評価結果とロールバック手順を必ず添えて保存してください。

もう1つの壁は最低料金の跳ね上がりです。Flexの年額$540は導入しやすい水準です。Premiumはワークロードによる増額前でも最低年額$4,800で、約9倍になります。SSO、手厚いサポート、長いバックアップ保持、リージョン、専用デプロイが必要なら上位プランは妥当です。「本番」という響きだけを理由にPremiumを買うべきではありません。

最適な用途： 字句検索と意味検索の関連性を調整したいマルチテナント型プロダクト
際立つ強み： マネージド検索プラットフォーム内で調整できるBM25Fとベクトルの統合
料金： Freeは無期限で$0。Flexは月額$45から。Premiumは共有または専用デプロイで月額$400からです。従量課金の埋め込み生成とQuery Agentは別料金です。
無料トライアル： 無期限のマネージド無料枠

6. Zilliz CloudとMilvus：超大規模・マルチモーダルなコレクションに最適

コレクションの規模、複数のベクトルフィールド、マルチモーダル検索が中心的な技術課題なら、最適なマネージド・ベクトルデータベースはZilliz Cloudです。その基盤にあるオープンソースエンジンがMilvusです。マネージド版の追加料金は、相当な分散システム運用を取り除くことで価値を生みます。

具体的に合うのは、同じ商品に意味検索用テキストベクトル、疎キーワードベクトル、画像ベクトルを持つ商品カタログです。Zilliz Cloudは各フィールドに対して複数のANN検索を実行し、統合結果をリランキングできます。文書化されたハイブリッド検索の例では、1つのコレクションで密なテキストベクトル、組み込みBM25による疎テキストベクトル、密な画像ベクトルを使っています。

Zilliz CloudのFreeプランは$0で、5 GBのストレージ、月間2.5百万vCU、最大5コレクションを含みます。Standard Serverlessは月額$0からです。料金ページ上のDedicated開始価格は「From $126/GB/month」と表示されています。StandardとEnterpriseには、どちらも30日間のトライアルがあります。

Enterprise Dedicatedは月額$197からで、99.95%の稼働率SLA、監査ログ、SSO、きめ細かなRBAC、マルチレプリカのスケーリング、プライベートエンドポイントまたはVPCピアリング、エンタープライズサポートが加わります。Business Criticalは見積もり制で、規制対象またはミッションクリティカルな環境に向け、耐障害性とセキュリティを強化しています。

専用クラスタの選択肢を見ると、この製品が大規模用途に位置する理由が分かります。性能最適化compute unitは768次元ベクトル約2百万件、容量最適化は約8百万件、階層ストレージは約40百万件を想定した説明です。公開された開始価格の目安は、ベクトル1百万件あたり月額でそれぞれ$63、$16、$5です。これは構成の目安であり、概念実証の代わりにはなりません。

自社でMilvusを運用する場合、運用の複雑さが壁になります。大規模コレクション、複数インデックス、レプリカ、コンパクション、ストレージ、アップグレード、復旧を扱うには、本格的なプラットフォームが必要です。その仕事を担うチームがすでにいなければ、ソフトウェアがオープンソースだからという理由でMilvusを動かす方が、Zilliz Cloudより高くつくことがあります。

もう1つの壁は、調達時の見積もり精度です。Zillizは有用な開始価格を公開していますが、本番費用はクラスタ種別、コンピュートユニット、レプリカ、ストレージ、ワークロード、プランで変わります。提示するレイテンシやコストには、計算ツールで使った構成を必ず添える必要があります。

最適な用途： 超大規模コレクション、マルチモーダルデータ、複数の密・疎ベクトルフィールド
際立つ強み： マルチベクトル・ハイブリッド検索と用途別クラスタ構成を備えたマネージドMilvus
料金： Freeは$0。Standard Serverlessは月額$0からで、料金ページにはStandard DedicatedがFrom $126/GB/monthと表示されています。Enterprise Dedicatedは月額$197から。Business Criticalはカスタム料金です。
無料トライアル： 無料プラン。StandardとEnterpriseには30日間のトライアルがあります

7. MongoDB Atlas Vector Search：アプリケーションデータがMongoDBにある場合に最適

MongoDB Atlas Vector Searchは、MongoDBアプリケーションに最適なベクトル検索です。すでに各フィールドとライフサイクルを管理しているドキュメントの隣に、埋め込みのインデックスを作成できます。Postgresでpgvectorを初期候補にするのと同じ、データグラビティの考え方です。

具体的に合うのは、元となるオブジェクトがすでにMongoDBドキュメントとして存在する、カタログ、コンテンツプラットフォーム、エージェントシステムです。$vectorSearch集約ステージでは、セマンティック検索の前にドキュメントをフィルターできるため、カテゴリ、アカウント、ロケール、在庫状況などのフィールドを1つのクエリ体系で扱えます。

Atlas Freeは$0で、共有コンピュートと512 MBを提供します。Flexは1時間あたり$0.011、月額上限$30で、共有コンピュートと最大5 GBを提供します。Dedicatedは1時間あたり$0.08、または月額$56.94からで、10 GBストレージ、2 GB RAM、2 vCPUを備えます。

ベクトル機能の境界は明確です。$vectorSearchは最大8,192次元のベクトルを受け付け、Atlas 6.0.11以降で動作します。$facetまたは$lookupの内部では使えません。MongoDB 8.0以降では、$unionWithの内部で実行できます。通常の集約パイプラインならどの形でもベクトル検索を包めると考えているチームにとって、こうした制約は重要です。

検索を専用のSearch Nodeへ移し、データベースのコンピュートから分離することもできます。Atlasは2〜32台のSearch Nodeに対応し、各ノードをプラン別の時間単位で課金します。Search Nodeとデータベースノード間のネットワーク転送は、クラスタ単位で計上されます。この分離はノイジーネイバー問題を解決する代わりに、容量とコストの検討対象をもう1つ増やします。

壁になるのは、ベクトル検索以外ではMongoDBを必要としないのに、MongoDBの費用を払うことです。Atlas Vector SearchはMongoDBに留まる強い理由ですが、リレーショナルアプリケーションを移行する強い理由ではありません。ベクトルだけを目的に選ぶと、pgvectorや専用エンジンならもっと簡潔に扱える可能性があるドキュメントモデル、クラスタ、Search Nodeの判断まで持ち込むことになります。

最適な用途： 別のデータストアを増やさずにセマンティック検索を導入したい既存のMongoDB Atlasアプリケーション
際立つ強み： 同じアプリケーションドキュメントのフィールドを使ったベクトル検索前のフィルター
料金： Freeは$0。Flexは1時間あたり$0.011で、月額上限$30。Dedicatedは1時間あたり$0.08、または月額$56.94からです。専用Search Nodeには別途、ノード単位の時間料金がかかります。
無料トライアル： 無期限のAtlas無料枠

8. Elasticsearch：字句検索がプロダクトの中心なら最適

全文検索の関連性、フィルター、集約、運用検索がすでにプロダクトの中核で、セマンティック検索を新たなシグナルとして加えるなら、Elasticsearchが最適なベクトルデータベースです。狭い用途のRAGインデックスには、費用対効果の高い初期候補ではありません。

具体的に合うのは、完全一致する語句、フレーズ、ファセット、構造化フィルター、意味的類似度を1つのエンジンで扱うEC、メディア、オブザーバビリティ、企業内検索です。Elasticsearchは密な埋め込みをdense_vector、疎な埋め込みをsparse_vectorへ保存し、字句検索、フィルター、集約と組み合わせます。

ハイブリッド検索では、キーワード、kNN、疎ベクトル、セマンティックの各検索を1つのワークフローで実行できます。Elasticはreciprocal rank fusionとlinear fusionに対応し、その後に任意でリランキングできます。関連性エンジニアリングがLLMの裏側にある補助機能ではなく、プロダクトの能力そのものなら、この広さに価値があります。

Elastic Cloud Hostedには、公開された最低料金が4つあります。Standardは月額$99、Goldは$114、Platinumは$131、Enterpriseは$184からです。すべてに無料トライアルがあります。ワークロードによるリソース費を加える前の年間最低額は、それぞれ$1,188、$1,368、$1,572、$2,208です。

ベクトルストレージは固定された配管ではありません。384次元以上の新しいfloatまたはbfloat16ベクトルインデックスでは、メモリとコストの削減を意図したバイナリ量子化HNSW構成のBBQ HNSWがデフォルトになります。このようにデフォルトが変化するため、バージョンを意識した検索評価が重要です。1つのインデックス設定で得た関連性の結果を、恒久的なものとみなしてはいけません。

壁になるのはプラットフォームの大きさです。Elasticsearchの対象範囲が広いのは、解く問題の範囲も広いからです。クラスタ、マッピング、アナライザー、シャード、インデックスのライフサイクル、関連性パイプライン、ベクトル設定、アップグレードには担当者が必要です。クエリが「意味的に似たチャンクを5件見つける」だけなら、Pinecone、Qdrant、pgvector、Chroma Cloudの方が理解しやすいでしょう。

最適な用途： 字句の関連性、フィルター、ファセット、ベクトルをまとめて扱う検索プロダクト
際立つ強み： キーワード、密ベクトル、疎ベクトル、フィルター、集約、リランキングを1エンジンで扱える
料金： Cloud Hosted Standardは月額$99、Goldは$114、Platinumは$131、Enterpriseは$184からです。最低料金を超えるデプロイ費はリソース使用量で決まります。
無料トライアル： すべてのHostedプランで利用可能

9. Redis：リアルタイム状態と同じ場所で検索するなら最適

埋め込みを、Redisですでに提供している変化の速いセッション状態、セマンティックキャッシュ、レコメンド候補、エージェントメモリと同じ場所に置く必要があるなら、Redisが最適です。強みはリアルタイムのデータ経路に近いことであり、大量のベクトルを安く保存できることではありません。

具体的に合うのは、直近の会話状態、キャッシュ項目、ユーザー特徴量、レコメンド候補をRedisに保存し、同じオブジェクトを意味検索するAIアプリケーションです。RedisはハッシュまたはJSONドキュメント内のベクトルをインデックス化し、テキスト、タグ、数値、地理空間フィールド、ベクトル条件でフィルターできます。

3種類のベクトルインデックスが、異なるデータ規模に対応します。100万ベクトル未満、またはレイテンシより正確性を重視する場合、RedisはFLATを推奨しています。完全な正確性より速度と拡張性を重視する大規模データセットではHNSWを使います。Redis 8.2では、グラフベースの圧縮方式と新たな調整項目を持つSVS-VAMANAが追加されました。

Redis Cloudの料金は、最大30 MBの共有データベース1つを使える$0のFreeから始まります。Essentialsは1時間あたり$0.007、または月額$5からで、RAMとSSDを合わせて250 MB〜100 GBです。SAML SSO、RBAC、暗号化、最大99.99%の稼働率を含みます。Proは1時間あたり$0.014から、月額最低$200で、最初の$200が無料です。専用デプロイ、無制限のRAM、複数データベース、アクティブ・アクティブのマルチリージョン、プライベート接続、最大99.999%の稼働率が加わります。

マルチクラウド、ハイブリッドクラウド、オンプレミスのデプロイは、見積もり制の年間契約で利用できます。この選択肢はエンタープライズ調達向けであり、短期のベクトル試験向けではありません。

壁になるのはメモリの経済性です。Redisは高速なデータアクセスを中心に設計されており、圧縮やSSD併用構成で負担を減らしても、ベクトルインデックスはメモリを消費します。大規模で、ほとんどがコールドデータで、クエリ頻度も低いコーパスのために、メモリ中心のシステムを買うべきではありません。turbopuffer、Pinecone、またはストレージ重視のZillizクラスタ構成でもコストを試算すべきです。

最適な用途： リアルタイムのRedisデータに対するセマンティックキャッシュ、エージェントメモリ、レコメンド、検索
際立つ強み： 低レイテンシ状態、JSON、ハッシュ、メタデータフィルターと同じ場所で使えるベクトル検索
料金： Freeは最大30 MBまで$0。Essentialsは1時間あたり$0.007、または月額$5から。Proは1時間あたり$0.014、月額最低$200で、最初の$200が無料です。Enterpriseデプロイは見積もり制の年間契約です。
無料トライアル： 無料枠。Proには最初の$200が含まれます

10. Chroma：ローカル試作とシンプルなクラウド検索に最適

Chromaは、ローカルでの試作に最適なベクトルデータベースであり、シンプルな検索プロダクトには有力なクラウド候補でもあります。ただし、ローカル版とクラウド版で使える機能は同一ではありません。ノートブックからChroma Cloudへの移行は、単なるデプロイ操作ではなく、本番アーキテクチャの決定として扱う必要があります。

具体的に合うのは、周辺プロダクトが固まる前に、チャンク分割、埋め込み、フィルター、検索の挙動を検証するエンジニアです。Chromaのオープンソース版は、この反復を始めやすくします。Chroma Cloudではサーバーレスのベクトル検索、全文検索、メタデータ検索を使え、使用単価も明示されています。

Chroma Cloud Starterは月額$0＋従量課金で、$5分の無料クレジット、10データベース、10チームメンバーを含みます。使用料は、書き込み1 GiBあたり$2.50、保存1 GiBあたり月額$0.33、クエリ対象1 TiBあたり$0.0075、返却データ1 GiBあたり$0.09です。

Teamは月額$250＋従量課金です。$100分のクレジット、100データベース、30チームメンバー、Slackサポート、SOC II、ボリュームディスカウントを含みます。含まれる$100は翌月へ繰り越せません。Enterpriseはカスタム料金で、データベース数とチームメンバー数が無制限になり、専用サポート、シングルテナントクラスタ、BYOC、SLAが加わります。

多くのチームが見落とす境界はSearch APIです。現在のChroma Cloud Search APIは、ベクトル検索、メタデータとドキュメントのフィルター、カスタムランキング式、RRFハイブリッド検索、グループ化、バッチ処理、フィールド選択、ページネーションに対応しています。Chromaは、このAPIがChroma Cloud限定であり、単一ノードへの対応は将来のリリースで予定していると明記しています。

つまり、従来のクエリ体系を使ったローカル検証だけでは、クラウド本番のクエリ設計を自動的に検証したことにはなりません。一方、Cloud Search APIでの設計が、自社運用の単一ノードでそのまま動くわけでもありません。製品名は共通でも、運用とクエリの実体は個別に確認する必要があります。

壁になるのは、Teamへ移る際のガバナンスと費用です。Starterなら、小規模ワークロードを従量課金でホストできます。Teamは使用料を加える前から年間基本料金が$3,000へ上がります。この差額で得られるのは、組織向けの容量、サポート、SOC II、割引です。「有料なら本番向けだろう」という曖昧な感覚ではなく、明確な組織要件に基づいて移行すべきです。

最適な用途： ローカルRAG試作、検索実験、シンプルなChroma Cloudアプリケーション
際立つ強み： ローカルですぐ始められ、クラウドの書き込み、ストレージ、クエリ、ネットワーク単価が明確
料金： Starterは月額$0＋従量課金で、$5分のクレジット付き。Teamは月額$250＋従量課金で、$100分のクレジット付き。Enterpriseはカスタム料金です。使用料は書き込み1 GiBあたり$2.50、保存1 GiBあたり月額$0.33、クエリ対象1 TiBあたり$0.0075、返却データ1 GiBあたり$0.09です。
無料トライアル： Starterに$5分のクレジットが含まれます

用途別に選ぶべきベクトルデータベース

適切なベクトルデータベースは、正とするデータの所在、最も厳しい検索条件、チームが許容できる運用負荷の順に決まります。

Postgresが正本ならpgvectorを選ぶ

ドキュメント、ユーザー、権限、トランザクション、ベクトルを1つのデータモデルで扱えるなら、pgvectorを選びます。フィルター後の再現率、インデックスメモリ、クエリ負荷のいずれかで実測上の問題が起きるまでは、その構成を維持します。別エンジンの方が多くのベクトルを扱えるという一般的なベンチマークだけで移行してはいけません。

反復スキャン、部分インデックス、パーティショニング、容量分離を施しても、レイテンシまたは再現率の目標を満たせないときに判断が変わります。その段階では、専用オープンソースならQdrant、運用負荷の小ささならPineconeが最有力です。

検索の難所がフィルターならQdrantを選ぶ

入れ子のpayloadフィルターと密・疎ベクトルの統合が中核なら、Qdrantを選びます。2つ目のストアを運用できるチーム、またはサイジング後にQdrant Cloudを購入するチームに向いています。データベース運用の方が大きな制約ならPineconeへ、フィルターがリレーショナルでワークロードもPostgresに収まるならpgvectorへ判断が変わります。

使用単位より運用コストが高いならPineconeを選ぶ

小規模チームがクラスタを運用せず、マネージドサービス、公開された使用単価、エンタープライズ向け制御を必要とするなら、Pineconeを選びます。使用量単位の経済性、ハイブリッド検索のオーケストレーション、BYOCポリシー、オープンソースによる制御がその利便性より重要になれば、判断は変わります。

マネージドか自社運用かという比較は、他のAIインフラ判断と同じ経済構造です。狭い運用範囲をベンダーから買うか、システムと障害対応を自社で担うかを選びます。内製と外部サービスのコスト比較フレームワークでは、人件費を無料扱いせず、サブスクリプションと並べてエンジニアリングの所有コストを計算する方法を解説しています。

コーパスが大規模でアクセスに偏りがあるならturbopufferを選ぶ

論理バイト課金とネームスペース分離がワークロードに合うなら、turbopufferを選びます。書き込みが集中する状況で、鮮度を必ず検証してください。更新や権限取り消しを次のクエリへ反映する必要がある場合、またはより単純な料金モデルが必要な場合は、別の選択肢へ切り替えます。

関連性をプロダクトとして調整するならWeaviateを選ぶ

BM25F、ベクトルの重み、統合、ブースト、マルチテナンシー、マネージド運用を1つのプラットフォームにまとめるなら、Weaviateを選びます。クエリが単純で、これらの制御がガバナンス負担にしかならない場合は、判断が変わります。

マルチベクトルのスケールが課題ならZilliz Cloudを選ぶ

超大規模、マルチモーダル、または複数のベクトルフィールドを持つコレクションには、Zilliz Cloudを選びます。自社運用Milvusを選ぶのは、分散システム運用をすでに担えるチームだけです。「将来は10億件規模」という話に実測要件が伴わないなら、より小さなエンジンへ判断を戻します。

データグラビティが強いならMongoDB、Elasticsearch、Redisに留まる

アプリケーションドキュメントがすでにMongoDBにあるならAtlas Vector Search、字句検索、フィルター、集約がプロダクトの中核ならElasticsearch、リアルタイム状態と同じ場所でベクトル検索するならRedisを選びます。ベクトルだけを理由に、これらのデータベースへ新たに移行するのは最適解ではありません。

Chromaで学び、本番は改めて判断する

ローカルでチャンク分割、埋め込み、検索を検証するならChromaを選びます。使用量モデルとCloud Search APIが本番ワークロードに合うなら、Chroma Cloudを選びます。ローカル版とクラウド版の機能が同じだと仮定してはいけません。

シナリオ別：避けるべき選択

万人向けの勝者を探すより、用途に合わない製品を避ける方が重要です。ここで挙げた製品には、いずれも妥当な用途がある一方、選ぶべきでない状況もあります。

• 現行ストアが限界に達する前に専用ベクトルデータベースを導入しない。 PostgresやMongoDBからベクトルとメタデータをコピーすると、同期、削除、復旧、アクセス制御の作業が増えます。ベンチマークで勝つだけでは、そのアーキテクチャを正当化できません。
• 調整後も近似フィルターで必要な件数を返せないなら、pgvectorを使い続けない。 反復スキャンは処理量を増やすことで行を補えます。その処理によってレイテンシ予算を超えるなら、実際の移行条件に達しています。
• 分散ストレージと検索の運用担当者がいないなら、Milvusを自社運用しない。 オープンソースライセンスは、アップグレード、容量計画、バックアップ訓練、オンコール体制を提供しません。
• 読み取り、書き込み、ストレージ、バックアップ、エグレスの各単位を誰もモデル化できないなら、Pineconeを選ばない。 マネージドサービスがなくすのはクラスタ運用であり、コスト管理の責任ではありません。
• 書き込み集中時の試験なしに、次の読み取りで整合することを前提としてturbopufferを選ばない。 文書化されているキャッシュとインデックス作成の挙動は、脚注ではなくプロダクト要件です。
• 関連性の評価セットを維持しないチームは、Weaviateを選ばない。 調整可能な統合とboostも、結果を測らなければ検証されない経験則になります。
• ベクトル専用機能にElasticsearchを選ばない。 幅広い検索プラットフォームだからこそ強力ですが、完全一致語、アナライザー、ファセット、集約が不要なら、その広さは無駄になります。
• 大規模なコールドアーカイブにRedisを選ばない。 強みは高速なリアルタイム状態です。ほとんど検索しない埋め込みにメモリ中心の料金を払っては、その利点を生かせません。
• 設計がCloud Search APIに依存するなら、Chromaの単一ノードを選ばない。 現在、ベンダーはその高度なAPIをCloud限定と明記しています。

繰り返される失敗は、将来のスケール構想だけを根拠に製品を買うことです。次の本番段階で見えている最も厳しい要件に合わせて購入し、検証済みの移行経路を残してください。アーキテクチャは進化できます。計測されない複雑さは積み上がるだけです。

ベクトルデータベースに関するよくある質問

RAGに最適なベクトルデータベースはどれですか？

アプリケーションがすでにPostgresを使っているなら、pgvectorが最適な初期候補です。複雑なフィルターを扱う専用オープンソースならQdrant、最も手軽なフルマネージドならPinecone、調整可能なハイブリッド検索がプロダクト要件ならWeaviateが最有力です。

RAGに使える無料のベクトルデータベースはどれですか？

pgvector、Qdrant OSS、Milvus、Weaviate OSS、Redis Open Source、Chromaはオープンソースです。Qdrant Cloud、Weaviate Cloud、Zilliz Cloud、MongoDB Atlas、Redis Cloud、Pinecone、Chroma Cloudには無料の導入枠があります。ソフトウェアが無料でも、インフラ、バックアップ、エンジニアリングには費用がかかります。

オープンソースでおすすめのベクトルデータベースはどれですか？

Qdrantは、フィルターとハイブリッド検索が多くの本番RAGシステムに合うため、専用オープンソースの最有力候補です。ベクトルをリレーショナルなアプリケーションデータと一緒に置くならpgvector、Milvusの規模が本当に必要で運用もできるチームならMilvusが適します。

ハイブリッド検索に最適なベクトルデータベースはどれですか？

Weaviateは、BM25Fとベクトルの重み、統合、フィルター、boostを扱えるため、最も分かりやすいマネージド・ハイブリッド検索ツールキットです。Qdrant、Pinecone、turbopuffer、Zilliz、pgvector、Elasticsearch、Redis、Chroma Cloudもハイブリッド検索に対応しますが、制御方法と運用上のトレードオフは異なります。

ローカルで使うなら、どのベクトルデータベースがおすすめですか？

多くのRAG試作では、Chromaが最も始めやすい選択肢です。ローカルアプリケーションですでにPostgresを動かしているなら、pgvectorの方が適します。権限、復旧、同時実行、Cloud限定機能は別途検証が必要なため、ローカル試作だけで本番の選択は決まりません。

pgvectorだけで本番RAGに対応できますか？

はい。Postgresがすでに正本データを持ち、フィルター後の再現率、インデックスメモリ、書き込み負荷、クエリレイテンシがサービスレベル内に収まるなら対応できます。重要な検証項目は、文書化されたフィルター検索の挙動です。近似インデックスを走査した後にフィルターが適用されるため、選択性の高いフィルターでは反復スキャンまたは専用エンジンが必要になることがあります。

PineconeとQdrantはどちらを選ぶべきですか？

フルマネージドサービスと小さな運用負荷が従量課金に見合うなら、Pineconeを選びます。オープンソースによる制御、入れ子フィルター、デプロイの柔軟性を重視するならQdrantを選び、自社運用の負担またはリソースベースのCloudサイジングを受け入れます。

pgvectorから専用ベクトルデータベースへ移行する時期はいつですか？

インデックスとパーティショニングを調整しても、フィルター後の再現率、レイテンシ、書き込み負荷、インデックスメモリ、データベース分離のいずれかが、定義した本番目標を満たせないと実測で分かったときです。ベクトル件数だけを移行条件にするのは適切ではありません。

最終結論

最も多くの開発チームにとって最適なベクトルデータベースはpgvectorです。通常、最もリスクが低いのはデータベースを2つではなく1つに保つ構成だからです。フィルター付き検索によって分離が必要になったら、専用オープンソースではQdrantが最有力です。データベース運用を外部へ任せたいなら、マネージド型ではPineconeが最有力です。ベクトルがすでにプロダクトを支えるデータプラットフォーム内に収まるなら、Elasticsearch、MongoDB、Redisが適します。

長く使える購入原則は、データグラビティを第1に、フィルター後の再現率を第2に、運用負荷を第3に、価格を第4に考えることです。これらの制約を通過したシステムだけを価格比較してください。

年間契約を結ぶ前に、実際のベクトル次元数、最も厳しい権限フィルター、通常時のクエリレート、取り込みのピーク負荷、削除経路、バックアップ復元、障害時の挙動を含む、代表的なワークロードを1つ実行します。定めたサービスレベルを、チームが管理すべきシステムを最小限にして満たせるものが、最適なデータベースです。

AIビジネス・ワークフロー監査チェックリストを入手

データベースをもう1つ追加する前に、データ、権限、同期、引き継ぎ、運用リスクを整理しましょう。