搭建RAG系统的时候，向量数据库的选型往往是一个被草率决定、但后期付出代价最大的环节。很多人随便选一个能用就行，结果到了生产环境才发现问题------要么是成本失控，要么是性能瓶颈，要么是运维负担超出团队承受能力。
这篇文章不搞纸上谈兵，而是从真实业务场景出发，用实测数据和代码说话，帮你理清怎么选 、怎么测。
一、先搞清楚你要面对什么样的场景
选向量数据库之前，先回答三个问题：
- 数据规模多大？ 几千条、几百万条，还是上亿条？量级不同，选型逻辑完全不同。
- 团队有没有运维能力？ 有人能搞定etcd+MinIO+Milvus三件套的部署和调优，还是希望开箱即用？
- 数据合规要求？ 数据能不能出境？需不需要私有化部署？
这三个问题的答案，基本决定了你的候选范围。
二、四大主流方案横向对比
2.1 Milvus：功能最全，但学习曲线陡峭
Milvus由Zilliz（国内团队）开源，是CNCF毕业项目。它的核心优势是功能最全、规模最大------支持十亿级向量，支持IVF、HNSW、DiskANN、GPU等多种索引类型，LangChain、LlamaIndex等主流框架都有官方集成。
但这个强大是有代价的。部署Milvus需要etcd + MinIO + Milvus三个组件协同，第一次配置很容易踩坑。有开发者反馈，第一次部署花了大半天，还遇到过etcd版本不兼容的问题。
版本迭代快是另一个痛点。从2.3到2.4到2.5，API改了好几次。Milvus 2.4+默认启用Sparse+Dense混合检索，如果之前的项目用纯Dense，升级后需要重建collection。
适合场景：国内团队、需要私有化部署、数据量在亿级以上、有专门的运维人力。
2.2 Pinecone：省心但贵
Pinecone是完全托管的SaaS服务------不需要部署、不需要运维、不需要操心扩缩容。官方宣称p99查询延迟在20-50ms，实测数据基本吻合。
缺点只有一个字：贵。有开发者做过测算，100万条768维向量，Pinecone月费约70美元；换成Milvus自建，同等规模一台4核8G的ECS就能搞定，月成本不到15美元。
另外，Pinecone是闭源SaaS，数据需要传到美国服务器。如果业务涉及金融、政务等合规敏感场景，直接pass。
适合场景：原型验证、小团队无运维能力、对成本不敏感、无数据合规要求。
2.3 Chroma：开发体验最好，但别用它上生产
Chroma的设计目标就是让开发者最快上手 。pip install chromadb就能用，支持内存模式和持久化模式，5分钟内就能搭起一个可用的向量存储。
但Chroma有明显的性能特征需要注意：对10万条384维向量，热缓存下P50延迟约20ms，冷缓存下会飙升到650ms，相差32.5倍。这意味着服务重启后的首次查询会非常慢。
Chroma单collection限制在500万条记录，也不支持角色权限控制（RBAC）和分布式部署。
适合场景 ：本地开发、快速原型验证、个人项目。上生产要慎重。
2.4 Weaviate：混合检索是最大亮点
Weaviate是德国团队开发的老牌选手，最大的特色是原生支持混合检索------将BM25关键词检索与向量语义检索结合。对于包含技术文档、API参考、产品型号等内容的场景，混合检索比纯语义检索更精准。
Weaviate还内置了多个embedding模型模块（OpenAI、Cohere、HuggingFace等），可以直接塞文本进去，不用自己生成embedding。
缺点是启动慢、内存占用高，国内社区资料极少。
三、快速决策参考
| 场景 | 推荐方案 |
|---|---|
| 本地开发、原型验证 | Chroma |
| 小团队、不想管运维、数据合规无要求 | Pinecone |
| 国内团队、数据量大、需私有化部署 | Milvus |
| 需要混合检索（关键词+语义） | Weaviate |
| 追求极致性能、中小规模、英文项目 | Qdrant |
Pinecone、Weaviate、Milvus都支持亿级向量规模，Chroma目前不适合大规模生产。
四、动手做压测：用数据说话
选型不能靠感觉，要用数据说话。这里推荐两个工具：
- VectorDBBench：Zilliz开源的向量数据库压测工具，支持Milvus、Pinecone、PgVector等多种数据库对比测试。
- VSB（Vector Search Benchmark）：Pinecone开源的基准测试套件，支持自定义负载和并发场景。
4.1 使用VectorDBBench做对比测试
bash
# 安装
pip install vectordb-bench==0.0.22
# 启动Web界面
python -m vectordb_bench启动后在浏览器中打开Streamlit界面，可以：
- 选择要测试的数据库（Milvus、Pinecone、PgVector等）
- 配置连接信息（URL、认证等）
- 选择测试数据集（如Cohere 1M向量、768维）
- 选择索引类型（HNSW、GPU_CAGRA等）
- 运行测试，获取延迟、召回率、QPS等指标
4.2 手工压测：用Python模拟真实负载
如果不想用现成工具，也可以自己写压测脚本，更贴近真实业务场景：
python
import time
import numpy as np
from concurrent.futures import ThreadPoolExecutor
import statistics
def benchmark_search(index, query_vectors, top_k=10, num_requests=1000, concurrency=10):
"""
对向量数据库执行压测
index: 向量数据库索引对象
query_vectors: 查询向量列表
"""
latencies = []
errors = 0
def single_search(vec):
try:
start = time.perf_counter()
results = index.search(vec, top_k=top_k)
end = time.perf_counter()
return end - start
except Exception as e:
return None
# 并发执行
with ThreadPoolExecutor(max_workers=concurrency) as executor:
futures = [executor.submit(single_search, q) for q in query_vectors[:num_requests]]
for f in futures:
result = f.result()
if result is not None:
latencies.append(result)
else:
errors += 1
# 计算指标
sorted_lat = sorted(latencies)
p50 = sorted_lat[int(len(sorted_lat) * 0.50)]
p95 = sorted_lat[int(len(sorted_lat) * 0.95)]
p99 = sorted_lat[int(len(sorted_lat) * 0.99)]
qps = len(latencies) / sum(latencies)
print(f"请求数: {len(latencies)}, 错误数: {errors}")
print(f"P50延迟: {p50*1000:.2f}ms, P95: {p95*1000:.2f}ms, P99: {p99*1000:.2f}ms")
print(f"QPS: {qps:.2f}")
return {"p50": p50, "p95": p95, "p99": p99, "qps": qps, "errors": errors}4.3 压测的关键参数
使用VSB时，需要关注几个关键设计参数：
- 并发用户数（
--users）：模拟多客户端同时请求，生产环境通常是并发场景 - 请求速率（
--requests_per_sec）：定义目标负载，避免压垮客户端或服务端 - 召回率分布：p50召回率80%看起来不错，但如果p10召回率是0%，意味着10%的查询返回了无相关结果，这就是严重问题
五、一个踩坑实例
我曾经在一个项目里用Chroma快速搭了RAG原型，开发体验很好，demo演示效果也不错。上了预发布环境后，数据量涨到50万条，发现几个问题：
- 服务重启后首次查询慢到不可接受（冷缓存问题）
- 无法水平扩展，单节点成了瓶颈
- 没有精细的权限控制，多租户场景没法做
最终花了两个周末迁移到Milvus，重新设计了collection schema和索引策略。教训就是：原型阶段选最快的工具没问题，但要为迁移留好接口------把向量检索抽象成统一的Repository接口，迁移时只改实现层。
总结
选向量数据库这件事，没有标准答案，只有适合你场景的选择。
| 阶段 | 建议 | 理由 |
|---|---|---|
| 原型开发 | Chroma | 零配置、上手快、迭代灵活 |
| 生产部署 | Milvus / Pinecone | 规模、性能、稳定性有保障 |
| 特殊需求 | Weaviate（混合检索）/ Qdrant（极致性能） | 对症下药 |
核心原则：先跑通，再看规模，最后优化。把检索逻辑封装在清晰的接口后面，这样无论底层换什么数据库，上层代码都不受影响。