向量数据库选型指南：FAISS / Chroma / pgvector / Qdrant / Milvus 怎么选？

适用人群：准备做 RAG 或向量检索，但面对一堆「向量数据库」不知道选哪个的开发者

先纠正一个核心误区：FAISS 不是数据库

很多人把 FAISS 和 Milvus 并列比较，其实是概念混淆。

FAISS（Facebook AI Similarity Search）是 Meta 开源的向量检索算法库，只解决一个问题：怎么快速找到最相似的向量。它：

• ❌ 没有 CRUD（更新基本靠重建索引）
• ❌ 没有持久化（宕机数据就没了，得自己加一层）
• ❌ 没有分布式（单机为主）
• ❌ 没有标量过滤（不能像 SQL 那样带条件查询）
• ❌ 没有事务、权限、高可用

有意思的是，Milvus 底层正是用 FAISS（以及 DiskANN、HNSWLib）作为索引引擎，再套上分布式、持久化、CRUD 这些数据库能力。两者的关系更像「发动机 vs 整车」。

六款主流方案速览

方案	本质定位	适用规模	典型场景
FAISS	向量检索库（Meta 开源）	百万~千万	算法研究、单机快速检索、要自己造轮子、需要 GPU 加速
Chroma	轻量级向量数据库	< 100 万	快速原型、Demo、学习 RAG、个人知识库
pgvector	PostgreSQL 扩展	百万级	已有 PG 栈、不想引入新组件、业务数据和向量同库
Qdrant	Rust 高性能向量数据库	千万级	中等规模生产、资源敏感、需要灵活过滤（原生支持 BM25）
Milvus	云原生分布式向量数据库	亿级+	大规模企业级生产、高可用、水平扩展
Weaviate	混合检索向量库	百万~千万	重度混合检索（BM25+向量+元数据一次查询）

选型决策框架：四步走

第一步：明确数据规模

• < 10 万向量：Chroma 或 PGVector 足够
• 10 万 ~ 1000 万：Qdrant 性价比高
• > 1000 万：Milvus 是必经之路

第二步：评估性能要求

• 延迟敏感（< 50ms）：Qdrant、Milvus（配置合理）
• 吞吐优先：Milvus 分布式部署
• 开发体验优先：Chroma

第三步：考虑运维能力

• 团队小、不想专门维护 DB：Chroma（进程内）或云托管
• 有专门 DB 团队：Qdrant 或 Milvus 自建
• 已有 Postgres：PGVector 是低摩擦选项

第四步：检查生态兼容性

• 用 LangChain / LlamaIndex：所有选项都支持
• 需要复杂过滤：Qdrant 和 Milvus 支持更好
• 需要混合检索：Qdrant 原生支持 BM25，Milvus 2.4+ 支持稀疏向量

推荐演进路线（分阶段）

阶段	选型	原因
阶段一：POC 验证（0-1 个月）	Chroma	数据量小、并发低、部署简单，快速验证 RAG 效果
阶段二：小规模生产（1-6 个月）	Qdrant	文档超 5 万份、并发超 10 人时 Chroma 出现瓶颈；Qdrant Docker 部署成熟，单机支撑百万级
阶段三：大规模生产（6 个月后）	Milvus	向量突破 500 万、或需要多副本高可用

不想自己运维：云托管——Zilliz Cloud（Milvus 云托管）、Qdrant Cloud、Pinecone（完全托管，成本较高）。云托管免运维，但要评估数据安全合规要求。

避坑指南

1. 坑一：一开始就用 Milvus——企业级方案学习曲线陡峭、资源消耗大；10 万条向量以下用 Chroma 或 Qdrant 更轻量
2. 坑二：选型后才发现不支持过滤——很多场景要按条件过滤（时间/类别/部门）；Chroma 过滤能力较弱，Qdrant/Milvus 支持更好
3. 坑三：忽视向量维度——不同 Embedding 输出不同维度（768d/1024d/1536d），高维向量显著增加存储和检索成本，注意数据库的维度上限
4. 坑四：低估索引构建时间——千万级向量索引构建可能需数小时甚至数天；Milvus 的 DiskANN 可在有限内存下处理大规模索引，但需额外配置

总结

向量数据库选型没有「最好」，只有「最适合」：

• 开发测试 → Chroma
• 小规模生产 → Qdrant（或 PGVector）
• 大规模生产 → Milvus
• 不想自己运维 → 云托管

从 Chroma 开始、在 Qdrant 上规模化、到 Milvus 进阶，这条路径适合大多数团队。另外记住：向量检索不是万能搜索，生产 RAG 往往需要 metadata filter、MMR、BM25 和 rerank 配合。