什么是向量数据库？为什么 RAG 需要它？

向量数据库专门存储和检索高维向量（embedding）。在 RAG 中，文档被转换为向量后存入向量数据库，用户查询时先把问题转为向量，然后在数据库中找到最相似的文档向量，再把这些文档作为上下文发给 LLM。核心操作是'近似最近邻搜索'（ANN），传统数据库做不了这个。

PgVector 和专用向量数据库的核心差距在哪？

两个差距：1) 性能——专用向量数据库（如 Qdrant）在 100 万向量上的 QPS 通常是 PgVector 的 3-5 倍；2) 索引能力——专用数据库支持 HNSW、IVF、DiskANN 等多种索引，PgVector 目前主要支持 HNSW 和 IVF-Flat。但 PgVector 的优势在于零额外运维——如果你已经在用 PostgreSQL，加一个扩展就完事了。

Qdrant 为什么性能最好？

三个原因：1) Rust 实现，没有 GC 暂停；2) 内存映射（mmap）索引，可以利用操作系统的页缓存；3) 量化和索引优化——支持标量量化、乘积量化和二值量化，可以用更少的内存达到相近的精度。在单节点场景下，Qdrant 的 P99 延迟通常是最低的。

Weaviate 的混合搜索是什么？

混合搜索指同时使用向量搜索（语义相似）和关键词搜索（BM25 精确匹配），然后用加权融合或重排序合并结果。Weaviate 原生支持这个功能——你不需要维护两套搜索引擎。在 RAG 场景中，混合搜索通常比纯向量搜索的检索准确率高 15-20%，因为它能捕获向量遗漏的精确关键词匹配。

什么规模以上需要分布式向量数据库？

经验法则：500 万向量以下（1536 维）用单节点就够了（约 30GB 内存）。500 万到 1 亿向量需要考虑分片——Qdrant 和 Weaviate 都支持多节点分片。超过 1 亿向量需要真正的分布式方案——Milvus 是目前唯一经过超大规模验证的选择，支持存算分离和自动分片。

向量数据库 2026 选型：Milvus vs Qdrant vs Weaviate vs PgVector 终极对比

为什么这篇测评现在有意义

2024 年向量数据库赛道有 20+ 个选手，到 2026 年格局已经清晰：

四强确立：Milvus（企业级）、Qdrant（性能优先）、Weaviate（开发体验）、PgVector（零运维）

其他选手：Pinecone（纯 SaaS 但锁定严重）、Chroma（太简单不适合生产）、FAISS（库而非数据库）

本文基于真实的 100 万条 1536 维向量（text-embedding-3-large 生成）进行实测。

测试环境

项目	配置
服务器	AWS c6a.4xlarge (16 vCPU, 32 GB RAM, 500 GB NVMe SSD)
向量	1,000,000 条, 1536 维, float32
数据来源	Wikipedia 英文段落, text-embedding-3-large
索引类型	HNSW (ef_construction=200, M=16)
查询	1000 条随机查询, TopK=10

所有数据库使用相同的硬件和数据，只调整各自推荐的默认配置。

性能对比

插入性能

数据库	100 万条插入耗时	插入 QPS	索引构建时间
Milvus	180s	5,556	120s（单独触发）
Qdrant	95s	10,526	实时（插入即索引）
Weaviate	140s	7,143	实时
PgVector	320s	3,125	280s（CREATE INDEX）

Qdrant 插入最快，实时索引意味着数据写入后立即可查。PgVector 最慢且索引构建是阻塞操作。

查询性能（TopK=10, Recall@10 ≥ 95%）

数据库	QPS	P50 延迟	P99 延迟	内存占用
Milvus	3,200	0.8ms	3.2ms	8.5 GB
Qdrant	4,800	0.5ms	2.1ms	7.2 GB
Weaviate	2,800	1.1ms	4.5ms	9.8 GB
PgVector	1,200	2.3ms	12ms	11 GB

Qdrant 查询性能第一，P99 延迟只有 2.1ms。PgVector 的 P99 延迟是 Qdrant 的 6 倍，但对于大多数 RAG 应用仍然足够（12ms 对用户不可感知）。

过滤查询（向量搜索 + 元数据过滤）

在 RAG 中经常需要”在特定分类下搜索”：

-- 伪代码：在 category='技术' 的文档中搜索相似向量
SELECT * FROM docs
WHERE category = '技术'
ORDER BY vector <-> query_vector
LIMIT 10;

数据库	过滤 QPS	过滤后 Recall	过滤机制
Milvus	2,800	95%	预过滤
Qdrant	4,200	96%	预过滤（Payload Index）
Weaviate	2,500	94%	预过滤
PgVector	800	93%	后过滤（WHERE 子句）

PgVector 的过滤是”先搜索再过滤”（后过滤），可能导致结果不足 TopK。其他三个都支持”先过滤再搜索”（预过滤），结果更准确。

部署和运维

部署复杂度

数据库	单节点部署	分布式部署	依赖组件
Milvus	`docker-compose`（4 个服务）	Helm Chart（Kafka/MinIO/etcd）	复杂
Qdrant	`docker run`（单容器）	`docker-compose`（分片）	简单
Weaviate	`docker run`（单容器）	Helm Chart	中等
PgVector	`CREATE EXTENSION vector`	PostgreSQL 集群（Citus/Patroni）	极简

PgVector 最简单——如果你已经有 PostgreSQL，一条 SQL 就完事。

Milvus 最复杂——完整部署需要 etcd（元数据）+ MinIO（存储）+ Kafka（消息队列）+ 多个 Milvus 组件。

运维成本（月均估算，100 万向量）

数据库	AWS 实例	存储	托管服务可选	月均成本
Milvus	c6a.2xlarge	200 GB EBS	Zilliz Cloud	$180 (自托管) / $300 (云)
Qdrant	c6a.2xlarge	100 GB EBS	Qdrant Cloud	$150 (自托管) / $250 (云)
Weaviate	c6a.2xlarge	150 GB EBS	Weaviate Cloud	$160 (自托管) / $280 (云)
PgVector	已有 PostgreSQL	+20 GB	Amazon RDS	$0-50 (已有 PG)

PgVector 的成本优势碾压——如果你已经在用 PostgreSQL，增量成本接近于零。

生态集成

LangChain / LlamaIndex 支持

数据库	LangChain	LlamaIndex	Dify	官方 SDK
Milvus	✅	✅	✅	Python, Go, Java, Node
Qdrant	✅	✅	✅	Python, Rust, Go, JS
Weaviate	✅	✅	✅	Python, Go, Java, JS
PgVector	✅	✅	✅	通过 PostgreSQL 驱动

四款数据库在主流 AI 框架中的集成都很完善。

特色功能

功能	Milvus	Qdrant	Weaviate	PgVector
混合搜索（向量+BM25）	✅	✅ (2024+)	✅（原生）	❌（需额外配置）
多向量搜索	✅	✅	✅	❌
动态 Schema	✅	✅	✅	✅（PostgreSQL）
全文搜索	✅	✅	✅（BM25）	✅（tsvector）
GraphQL API	❌	❌	✅	❌
存算分离	✅	❌	❌	❌
多租户	✅	✅	✅	✅（Schema 隔离）

选型决策树

你的向量数据量级是多少？
  ↓
< 50 万且已有 PostgreSQL？
  → PgVector ✅ 零运维零成本

50 万 - 500 万？
  ↓
  需要混合搜索（向量 + 关键词）？
    → Weaviate ✅ 原生混合搜索最成熟
  ↓
  追求极致查询性能？
    → Qdrant ✅ 单节点性能之王
  ↓
  需要 GraphQL API？
    → Weaviate ✅

500 万 - 1 亿？
  → Qdrant 或 Milvus（看团队运维能力）
  → 运维强选 Milvus（真分布式）
  → 运维弱选 Qdrant（简单分片）

> 1 亿？
  → Milvus ✅ 唯一经过超大规模验证的方案

我的推荐

80% 的 RAG 应用：用 PgVector。理由——大多数 RAG 应用的文档量在 10 万到 100 万之间，PgVector 完全够用，而且不需要额外的运维和成本。

需要极致性能：用 Qdrant。如果你的应用对延迟敏感（如实时推荐、搜索），Qdrant 的 Rust 实现和 mmap 索引提供了最低的尾延迟。

需要混合搜索：用 Weaviate。它的 BM25 + 向量搜索融合是四款中最成熟的，配合重排序可以显著提升 RAG 的检索准确率。

超大规模企业：用 Milvus。存算分离架构是超过 1 亿向量后的唯一可行方案，Zilliz Cloud 提供的托管服务可以降低运维压力。

别被性能基准迷惑——对于 RAG 场景，2ms 和 12ms 的检索延迟差距远小于 LLM 推理的 1-3 秒延迟。选最简单的，直到它不够用为止。