RAG 系统的瓶颈往往不在大模型，而在检索层。很多团队 POC 阶段随便选 Chroma，上线直接翻车；已有 Postgres 的团队盲目上 Milvus，引入一堆中间件，运维成本爆炸。
本文聚焦RAG 业务场景，横向拆解 Milvus、Chroma、Qdrant、PGVector 四款开源方案，从底层架构、检索能力、规模上限、运维成本、坑点逐一分析，最后给出可直接落地的决策树。
四款产品基础定位总览
| 项目 | 底层定位 | 开发语言 | 核心适用向量规模 | 部署形态 | 许可证 |
|---|---|---|---|---|---|
| Chroma | 轻量嵌入式向量库 | Python | ＜100 万向量 | 进程内嵌入 / 简易服务 | Apache2.0 |
| PGVector | PostgreSQL 扩展插件 | C | ＜500 万向量 | 复用现有 Postgres 数据库 | PostgreSQL 协议开源 |
| Qdrant | 专用单节点 / 分布式向量引擎 | Rust | 100 万～数千万向量 | 单二进制 Docker、K8s 集群 | Apache2.0 |
| Milvus | 云原生分布式向量数据库 | Go/C++ | 千万～十亿级向量 | K8s 集群，依赖 etcd、MinIO | Apache2.0 |
逐个拆解（RAG 视角）
1. Chroma：POC 原型神器，不推荐正式生产
Chroma 的核心优势是零依赖嵌入模式，一行代码即可启动，LangChain、LlamaIndex 默认集成，非常适合快速验证分块策略、Embedding 模型效果，本地 Demo 首选。 RAG 优势
- 嵌入模式无需单独启动服务，直接在 Python 进程内运行，开发调试效率极高
- API 极简，仅增删查改，快速搭建最小 RAG 原型
- 自带基础持久化，小体量文档直接跑通知识库问答
致命短板（生产踩坑重点）
- 千万向量规模性能断崖下跌，索引能力弱，不支持复杂元数据过滤
- 企业级能力缺失：高可用、主从复制、备份恢复、多租户隔离能力薄弱
- 没有原生混合检索（BM25 关键词 + 向量融合），只能单独向量检索
- 并发能力差，多用户 RAG 查询场景容易卡顿
✅适合场景：本地 Demo、实验分块策略、课程演示、内部小知识库（文档总数＜10 万） ❌禁止场景：公网线上 RAG、多用户并发、大规模企业知识库
2. PGVector：已有 Postgres 团队最优解，关系数据 + 向量一体化
PGVector 不是独立数据库，是 Postgres 的扩展插件，向量和业务结构化数据存在同一张表，SQL 和向量检索可以在同一个事务中完成，这是它独有的核心竞争力。
RAG 优势
- 无需新增独立服务，复用现有 PG 的权限、备份、事务、行级安全 RLS
- 向量检索 + 业务 WHERE 条件（租户、文档类型、时间范围）原生 SQL 联动，适合业务数据和文档切片强绑定场景
- 学习成本低，开发人员直接写 SQL，不用学习新 SDK
- 支持 HNSW、IVFFlat 索引，支持 halfvec、sparsevec，适配稠密 / 稀疏向量
短板
- 不是为向量检索原生设计，向量规模超过 500 万后，HNSW 索引构建占用大量内存，查询延迟明显上涨
- 无原生混合检索，关键词 BM25 需要搭配 Postgres tsvector 手动实现，分数融合需要自己开发，召回效果不如专用向量库
- 不支持横向分片扩容，单库上限受限于 Postgres 单机能力
- 大索引创建会占用大量数据库 IO，容易影响原有业务库性能
✅适合场景：
- 业务已经全栈 Postgres，不想引入新中间件
- 向量切片需要和业务数据 JOIN 查询、租户权限行级隔离
- 向量规模在 500 万以内、并发中等的私有化 RAG 项目
❌不适合：亿级知识库、高并发公网 RAG、重度混合检索场景
3. Qdrant：RAG 生产环境均衡之选，过滤性能极强
Rust 编写的专用向量数据库，在带元数据过滤的 ANN 检索上是四款里最强的，也是当前中小规模企业 RAG 落地最热门选型。
RAG 优势
- Rust 底层，内存占用低，单节点性能优秀，支持 payload 预过滤 HNSW，过滤后召回衰减很小（RAG 高频场景：按租户、文档分类、时间筛选再做语义检索）
- 原生支持稠密向量 + 稀疏向量混合检索（Hybrid Search），直接内置 BM25，不用额外组件，RAG 召回提升明显
- 部署极简：单二进制文件，Docker 一键启动，分布式集群配置成本远低于 Milvus
- 支持动态数据写入，增量更新、删除不会锁索引；支持向量分段合并，线上更新不影响检索服务
- 丰富的 payload 类型，数组、数值、字符串标签，非常适合 RAG 文档元信息管理
短板
- 分布式集群能力弱于 Milvus，亿级海量向量场景运维压力上升
- 生态和企业多租户能力弱于 Milvus，缺少成熟冷热分层存储方案
✅适合场景： 100 万～数千万向量，企业知识库、客户客服 RAG、私有化文档问答；RAG 带大量元数据过滤，混合检索需求强烈。 绝大多数中小团队生产 RAG，优先推荐 Qdrant。
❌不适合：十亿级海量向量、需要冷热分层存储、大规模多租户 SaaS 平台
4. Milvus：海量企业级分布式方案，重架构，高上限
CNCF 毕业项目，原生分布式云原生架构，为超大规模向量检索设计，2.6 版本完善原生 BM25 混合检索、冷热数据分层。
RAG 优势
- 真正水平扩容，十亿级向量稳定支撑，支持存算分离，冷数据下沉对象存储，降低存储成本
- 完善多租户能力，数据库、Collection、Partition 三级隔离，适合 SaaS 化 RAG 平台
- 索引种类齐全：HNSW、IVF、DiskANN，支持 GPU 加速检索，海量向量下召回稳定
- 原生混合检索，稠密 + 稀疏向量统一查询，支持大规模批量导入、实时增量写入
- 完善监控、告警、集群高可用方案，企业级运维体系成熟
短板（最大痛点：运维复杂度极高） Milvus 集群依赖 etcd、MinIO、消息队列等一堆组件，整套系统维护成本高。小规模知识库使用 Milvus 属于典型过度设计，资源开销大，小团队维护难度高。
✅适合场景： 亿级向量、SaaS 多租户 RAG 平台、海量文档检索、需要冷热分层、高吞吐大规模检索业务，配备专职运维 / 云原生团队。
❌不适合：百万级小规模知识库、团队无 K8s 运维能力、轻量化私有化部署
RAG 核心能力横向对比表
| 对比维度 | Chroma | PGVector | Qdrant | Milvus |
|---|---|---|---|---|
| 元数据过滤 | 弱 | 强（SQL WHERE） | 极强（payload 预过滤） | 强 |
| 原生混合检索（BM25 + 向量） | ❌ | ❌需要手动集成 | ✅原生支持 | ✅原生支持 |
| 增量更新 / 删除 | 差 | 一般 | 优秀 | 优秀 |
| 多租户隔离能力 | 弱 | RLS 行级权限 | 中等 | 企业级完整隔离 |
| 单节点向量上限 | 100 万 | 500 万 | 数千万 | 十亿级（集群） |
| 部署复杂度 | 极低 | 极低 | 低 | 极高（K8s 多组件） |
| 内存开销 | 低 | 中等 | 很低 (Rust) | 较高 |
| 生产环境成熟度 | 原型级 | 中等 | 高 | 极高 |
核心选型决策树（直接套用）
- 仅本地 POC、Demo 验证 Embedding / 分块 → Chroma，快速跑原型，上线必须迁移
- 已有 PostgreSQL，向量＜500 万，向量和业务表强关联，不想新增中间件 → PGVector
- 生产 RAG，向量 100 万～数千万，大量元数据过滤、需要混合检索，团队小不想复杂运维 → Qdrant（优先推荐）
- SaaS 平台、十亿级海量文档，多租户，专职云原生运维团队 → Milvus
RAG 落地避坑要点（硬核踩坑总结）
- 不要盲目追求分布式：很多百万级知识库强行上 Milvus，架构复杂度翻倍，稳定性反而下降，Qdrant 单节点完全够用。
- PGVector 最大坑：HNSW 索引构建非常吃内存，向量量大的时候不要在线创建索引，低峰期后台执行。超过 500 万向量，召回与延迟会明显劣化。
- 过滤陷阱：很多 RAG 查询是先过滤租户 / 文档类型，再做向量检索。Chroma 过滤性能差，大规模过滤场景直接排除。Qdrant 的预过滤 HNSW 是 RAG 高频场景杀手锏。
- 混合检索是提升 RAG 召回核心：PGVector 没有原生 BM25，自己做分数融合调试成本很高，有混合检索需求优先 Qdrant/Milvus。
- 数据冷热分层：Milvus 的 DiskANN 适合冷文档；Qdrant、PGVector 冷数据存储方案薄弱，海量冷文档场景慎重选择。
结尾总结
向量数据库选型本质不是选 "性能最强"，而是匹配向量规模、业务查询模式、现有技术栈、运维人力。
- 原型：Chroma
- PG 生态小体量 RAG：PGVector
- 绝大多数企业生产 RAG：Qdrant，平衡性能、运维、检索能力
- 超大 SaaS 海量知识库：Milvus
RAG 系统，检索质量优先于极限 QPS；带过滤的语义检索、混合检索，才是真实业务最核心的指标，而不是单纯的单机最高检索速度。