第5章: ベクトルDB比較 — pgvectorを本番で運用する

2026年のベクトルDBランドスケープ

ベクトルDB市場は2022〜2023年に専用製品（Pinecone、Qdrant、Weaviate、Chroma等）が爆発的に増え、 2024〜2026年にかけてpgvectorや既存の検索エンジン（OpenSearch、Elasticsearch）への回帰と統合が進みました。 2026年時点の主要プレイヤーは以下の6つです。

pgvector基礎 — PostgreSQLの拡張として動く

pgvectorは2022年にAndrew Kaneが公開したPostgreSQL拡張で、 2026年時点ではSupabase、Neon、AWS RDS、Google Cloud SQL、Azure Database for PostgreSQL、AlloyDBのすべてで標準サポートされる事実上の業界標準です。 既存のPostgresにベクトル検索機能を後付けできる手軽さが最大の強みです。

-- 拡張を有効化
CREATE EXTENSION IF NOT EXISTS vector;

-- テーブル定義（OpenAI text-embedding-3-small の1536次元）
CREATE TABLE documents (
  id BIGSERIAL PRIMARY KEY,
  content TEXT,
  metadata JSONB,
  embedding vector(1536)
);

-- HNSWインデックス作成（本番推奨）
CREATE INDEX ON documents
USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);

-- コサイン類似度で検索（<=> 演算子）
SELECT id, content, 1 - (embedding <=> $1::vector) AS similarity
FROM documents
ORDER BY embedding <=> $1::vector
LIMIT 5;

pgvector 0.8の新機能 — 本番運用を変えた3つの機能

2024年末にリリースされたpgvector 0.8.0は本番運用を一段階進化させました。特に重要な3つの機能を押さえておきましょう。

① Iterative Scan — フィルタ付き検索の救世主

「WHERE category = 'hr' + ベクトル検索」のようなフィルタ付きANNで、HNSWインデックスがoverfiltering（k件取れない）を起こす問題を解決する機能です。 初回スキャンで足りなければ自動的にインデックスを追加探索します。

-- 厳密な距離順（順序保持しつつ追加探索）
SET hnsw.iterative_scan = strict_order;

-- 緩和順（多少順序乱れるがRecall重視）
SET hnsw.iterative_scan = relaxed_order;

-- 追加探索の上限（デフォルト20000）
SET hnsw.max_scan_tuples = 20000;

② halfvec型 — 精度ほぼ維持で半分のサイズ

float32（4バイト）からfloat16（2バイト）に量子化するhalfvec型が追加されました。 Neonのベンチマークでは、ストレージを50%削減しつつ、コサイン類似度の結果がほぼ変わらないことが示されています。 OpenAI text-embedding-3-large（3072次元）のような高次元モデルで特に効果的です。

-- halfvec型でインデックス作成
CREATE INDEX ON documents
USING hnsw ((embedding::halfvec(3072)) halfvec_cosine_ops);

-- halfvecカラムとして保存（検索時のキャストも不要）
ALTER TABLE documents ADD COLUMN embedding_half halfvec(1536);
UPDATE documents SET embedding_half = embedding::halfvec(1536);

③ Binary Quantization + Rerank — 2段階検索で超高速化

ベクトルを1bit/次元に圧縮したbit型でざっくり候補を絞り、元のベクトルで再ランクする2段階検索パターンが実用化されました。 Jonathan Katzのベンチでは1536次元で空間削減19倍、p99レイテンシ29%減、Recall 95%前後を達成しています。

-- バイナリ量子化 + 元ベクトルでリランク
SELECT i.id, i.content FROM (
  SELECT id, content, embedding,
         embedding <=> $1 AS distance
  FROM items
  ORDER BY binary_quantize(embedding)::bit(1536)
           <~> binary_quantize($1)
  LIMIT 800  -- バイナリで粗く800件
) i
ORDER BY i.distance
LIMIT 10;  -- 元ベクトルで精度よく10件

HNSW本番チューニング実例

pgvectorでHNSWを本番運用する際、以下の3点を押さえれば大半のトラブルが避けられます。

メモリ設定が最重要

HNSWインデックスの構築は大量のメモリを食います。 maintenance_work_memがデフォルトの64MBのままだとディスクベース構築になり10〜50倍遅くなります。 目安は N × D × 4バイト × 2。 例: 5M行 × 1536次元 → 約60GB必要、という規模感です。

-- 構築時のセッション設定
SET maintenance_work_mem = '16GB';
SET max_parallel_maintenance_workers = 7;  -- 8並列

-- サーバ全体（postgresql.conf）
-- shared_buffers = 16GB       # RAM 64GBの25%
-- work_mem = 64MB
-- effective_cache_size = 48GB # RAM 64GBの75%

パラメータの実務値

Supabase公式ベンチマーク（DBpedia-1M、1536次元）から得られた実務的な数値です。

並列構築で80%時間短縮

pgvector 0.6.0からHNSW構築が並列化されました。 Stormaticsのベンチマークでは、1時間46分→20分と約80%短縮されています。 max_parallel_maintenance_workersを7（リーダー含め8並列）に設定するのが目安です。

pgvectorscale — DiskANN + SBQで大規模対応

Timescale（TigerData）が開発したpgvectorscaleは、 DiskANN論文ベースのStreamingDiskANNとStatistical Binary Quantization（SBQ）で、 pgvectorの大規模性能を劇的に引き上げます。

CREATE EXTENSION vectorscale CASCADE;

CREATE INDEX ON items USING diskann (embedding vector_cosine_ops)
WITH (
  storage_layout = 'memory_optimized',
  num_neighbors = 50,
  search_list_size = 100,
  num_dimensions = 768
);

主要ベクトルDB詳細比較

Pinecone — 運用ゼロの定番

2019年創業、a16zリードのSeries Bで評価額7.5億ドル。 Serverless（従量課金）とPod（定額）の2モードがあり、運用工数ゼロが最大の強み。 Morgan Stanley、Perplexity AI、Shopify Sidekickなど大規模採用事例が豊富。 一方、2025年の値上げで「コスト高い」という声が増え、pgvectorやQdrantへの移行事例も増加しています。

Qdrant — Rust製・フィルタ最強

2021年創業（ベルリン）、Apache 2.0 OSS + Cloud。 p50レイテンシ4msという最速級の性能と、Payloadフィルタの強力さが特徴。 HubSpotなど大企業採用も進んでおり、「OSSで自社ホスト」の第一候補です。

Weaviate — ハイブリッド検索の標準装備

2019年創業（オランダ）、BSD-3-Clause OSS。 BM25とベクトル検索の統合が最初から設計されており、GraphQLインターフェースでモジュール拡張が容易。 Morningstarなどが採用。Serverless Cloudの価格が明瞭なのも魅力。

Milvus / Zilliz — 大規模エンタープライズ

2017年創業（Zilliz、上海発→SF）、LF AI & Data FoundationのGraduatedプロジェクト。 十億〜数百億規模の検索に強く、GPU加速対応。エンタープライズ向けの重量級だが、 中立ガバナンス（ベンダー縛りなし）が気に入られて採用が広がっています。

実務選定マトリクス

次章では、ベクトルDBにデータを投入する前の工程、つまりRAGパイプライン設計について詳説します。 Gao et al.の3パラダイム、Chunking戦略の選択、Query変換、Rerankerといった「検索精度を決める工程」を体系的に学びましょう。