埋め込みベクトルをPostgreSQL拡張機能pgvectorで保存すべきか、それとも専用のベクトルデータベースに任せるべきか？技術ガイドは原理的な議論ではなく、性能測定によってこの問いに答えようとし、pgvectorとQdrantを比較している。
二つのアーキテクチャ、同じ目標
pgvectorはPostgreSQLのオープンソース拡張機能で、公式GitHubリポジトリによるとバージョン0.8.6、PostgreSQL 13以降と互換性がある。データベースにベクトル専用の列型と、厳密および近似最近傍検索を追加する。具体的には、embedding（コンテンツの数値的表現であるベクトル）を、関連するデータと同じテーブルに保存し、通常のSQL言語で問い合わせることができる。コサインや内積を含む5種類の距離関数が提供されている。
一方、専用ベクトルデータベースは、独自のストレージエンジンを備えた別個のサービスで、ベクトル検索を中心に設計されている。ガイドでは特にPinecone、Qdrant、Weaviate、Milvus、ChromaDBを挙げている。このアーキテクチャの選択は、追加のシステムをデプロイ、監視、バックアップし、参照データを含むデータベースと同期を維持することを意味する。
小規模、そして大規模での測定
ガイドは、Docker、Python 3.10以降、約8GBの空きRAMを備えたノートパソコンでの再現可能なテストを提案している。データセットは合成的：10万個の1536次元ベクトル（一般的な埋め込みモデルのサイズ）を、同じHNSWインデックスパラメータで両システムにロードする。著者によれば、このようなハードウェアでは、使用可能なプロセッサとメモリによって大きく変動するが、レイテンシは数ミリ秒から数十ミリ秒の範囲にある。このボリュームは、本番環境での結論を引き出すにはまだ小さすぎる。
この問いに対して、ガイドはTiger Dataが公開した研究に依拠している。それは768次元のCohere埋め込み5000万個を対象とし、AWS r6id.4xlargeマシン（16 vCPU、128GB RAM）で、ANN-Benchmarksツールの修正版を用いてテストされた。ガイドは重要な点を強調している：テストはpgvector単体ではなく、Timescaleの拡張機能であるpgvectorscale（別のインデックスタイプStreamingDiskANNを追加する）と組み合わせたpgvectorで実施された。
これらの結果によると、再現率99%において、pgvectorscaleを組み合わせたPostgreSQLは1秒あたり471.57クエリを達成し、Qdrantの41.47に対して優位だった。中央値レイテンシはほぼ同等で、31.07 ms対30.75 msだった。一方、Qdrantは極端なレイテンシで際立っている：そのp99は38.71 msで、74.60 msに対して優れており、インデックスの構築時間は3.3時間で、11.1時間に対して優れていた。ガイドによれば、両システムは測定された全てのパーセンタイルで100 msを下回っている。
ワークロードに応じた選択
ガイドは、pgvectorが約500万から1000万ベクトルまでのボリューム、中程度のクエリ同時実行性、およびチームが既にPostgreSQLを習熟している場合に適していると評価している。また、リレーショナルデータとベクトル間のトランザクション一貫性にも言及し、ドキュメントとそのベクトルを同一トランザクション内で更新できる利点を強調している。
逆に、記事によれば、専用データベースは数億から数十億ベクトルというボリューム、または高度にフィルタリングされた検索で極端なレイテンシに厳しい制約がある場合（ここでQdrantは測定された優位性を示す）、正当化される。MilvusはGPUによる高速インデックス作成で、Pineconeは内部での管理を必要としない完全マネージドサービスとして言及されている。
