ベクトルデータベースの運用特性比較 – pgvector・Milvus・Weaviateの選定基準

生成AI関連ワークロードの実装が進む中、ベクトルデータベースの選定判断が実装チームに任される場面が増えている。しかし、公開されているベンチマーク結果は、多くの場合、単一のワークロードパターンでの相対比較にとどまり、実際の運用判断に必要な情報を提供していない。本稿では、pgvector・Milvus・Weaviateを、実務判断に関わる三つの軸で比較する。

インデックス方式の運用特性

ベクトル検索の性能は、インデックス方式の選択で大きく変わる。pgvectorは、IVFFlatとHNSWの両方をサポートするが、実装はPostgreSQLの拡張として構成される。既存のPostgreSQL運用ノウハウが活用できる一方、大規模なベクトル数(数億件超)では、単一ノード制約が支配的となる。Milvusは、分散アーキテクチャを前提とし、HNSW、IVFシリーズ、DiskANNなど複数のインデックスを提供する。ただし、分散システム固有の運用複雑性が加わり、小規模用途では過剰投資となる。

Weaviateは、HNSWを中心としたインデックスに加えて、モジュラーなプラグイン構造で埋め込み生成やハイブリッド検索を統合する。組み込みのハイブリッド検索(ベクトル検索と全文検索の融合)は、ユースケースが検索エンジンに近い場合、実装コストを大幅に削減する。他方で、SQL的な問い合わせを要求される場面では、Weaviateの独自クエリ言語が学習コストとして加算される。

既存データストア構成との統合コスト

ベクトルデータベースは、単独で稼働するケースよりも、既存のトランザクショナルデータベースと併用されるケースが多い。pgvectorは、PostgreSQLの拡張であるため、既存のPostgreSQL運用体制、バックアップ・レプリケーション設計、権限管理をそのまま流用できる。これは無視できない実装コストの削減である。

Milvus・Weaviateは、独立のデータストアとして構築するため、既存のトランザクショナルデータとの整合性維持のための同期層が要求される。同期層の実装は、単方向レプリケーション、変更データキャプチャ(CDC)、バッチ再構築のいずれかで行われるが、いずれも運用複雑性を追加する。既存データストアとベクトル検索を頻繁に組み合わせるワークロードでは、pgvectorの統合コスト優位は大きい。

エコシステム依存と将来の可搬性

ベクトルデータベースの選定は、しばしば数年間の技術負債を伴う決定である。pgvectorはPostgreSQLの生態系に組み込まれているため、将来的なマネージドサービス移行(RDS、Cloud SQL、Supabase等)の選択肢が広い。Milvusは、Zilliz Cloudをはじめとするマネージドサービスが存在するが、選択肢は限定的である。Weaviateは、Weaviate Cloud Servicesが主要な選択肢となる。

ただし、可搬性はエコシステムの成熟度だけでは決まらない。生成AI推論コストの構造分析 で議論した推論コストの動向を踏まえると、埋め込みモデルの世代交代に伴うベクトル空間の再計算コストは、いずれのデータベースでも共通に発生する。この再計算コストは、データベース選定よりも、埋め込みモデル選定と密接に関わる問題である。産業特化型ファンデーションモデルと汎用モデルの選定 と併せて議論する価値がある。