做 RAG 项目时，「向量存到哪里」很容易被讨论成产品站队：有人看到分布式架构就想直接上集群，也有人因为业务已经用了 PostgreSQL，就认定永远不需要专用向量库。
这两种说法都把选型做反了。向量数据库不是按品牌挑，而是按约束挑：现有技术栈是什么、查询是否带复杂权限过滤、需要什么可用性、团队愿意承担多少运维责任、未来迁移有多难。
本文对比 PGVector、Qdrant、Milvus、Weaviate 和腾讯云 VectorDB，但不提供脱离数据集与硬件的“万能规模线”。没有真实压测产物的精确 QPS、延迟和容量数字，看起来很专业，实际上最容易误导决策。
1. 先把问题拆对：你选的不只是“向量检索”
RAG 的基础流程很简单：文档切片后经过 Embedding 模型转成向量；用户提问也转成向量；系统查找相似片段，再把结果交给大模型生成回答。
真正进入生产后，向量检索之外通常还要处理：
- 权限与结构化过滤：只查某个租户、部门、产品线或时间范围；
- 关键词与语义混合检索：既要理解语义，也不能漏掉型号、合同号等精确词；
- 持续写入和更新：新文档进入、旧文档失效、Embedding 版本切换；
- 备份与恢复：索引损坏、节点故障或误操作后怎么恢复；
- 扩容与升级：容量增长时是加机器、拆分集合，还是迁移产品；
- 可观测性：召回率、尾延迟、索引构建和写入积压是否可监控。
因此，选型表至少要覆盖检索、数据治理和运维三个维度。关于 RAG 整体落地方法，可继续看企业知识库 RAG 落地的 6 个关键决策和AI Agent 的记忆、工具与 RAG。
2. 5 家产品分别解决什么问题
| 产品 | 产品形态 | 更适合先进入候选的条件 | 需要重点验证 |
|---|---|---|---|
| PGVector | PostgreSQL 扩展 | 已经重度使用 PostgreSQL，希望复用事务、SQL、权限和备份体系 | 过滤后的召回、写入影响、索引构建与数据库资源竞争 |
| Qdrant | 专用向量数据库，可单机或分布式 | 需要丰富过滤、多租户设计，希望保持相对独立的向量检索服务 | payload index、分片副本、备份恢复与集群运维 |
| Milvus | Lite / Standalone / Distributed 多种形态 | 已明确需要独立向量基础设施，团队具备分布式系统运维能力 | 组件复杂度、对象存储与元数据依赖、故障演练 |
| Weaviate | 专用向量数据库与托管服务 | 业务重视向量与 BM25 的混合检索，希望直接使用融合能力 | 混合检索参数、schema、模块依赖与部署成本 |
| 腾讯云 VectorDB | 全托管分布式服务 | 业务已在腾讯云，希望减少自建运维并明确国内数据地域 | 当前规格与报价、网络链路、SLA、备份和厂商锁定 |
这些定位可以直接回到官方能力核对：
- PGVector 官方仓库说明它在 PostgreSQL 中提供精确和近似最近邻检索，并支持 HNSW、IVFFlat 与 PostgreSQL 过滤能力；
- Qdrant 官方概览说明 collection、payload index、filterable HNSW、分片和多种部署形态；
- Milvus 官方部署说明区分 Lite、Standalone 与 Distributed，分布式形态意味着更完整的基础设施责任；
- Weaviate 官方混合检索文档明确其 Hybrid Search 会融合向量检索与 BM25F 关键词检索；
- 腾讯云 VectorDB 产品说明将其定义为全托管的分布式向量数据库服务。
3. 第一问：能不能先复用 PostgreSQL
如果业务数据、租户权限和运维体系已经在 PostgreSQL，PGVector 应该进入第一轮候选。它最大的价值不是“某个跑分最高”，而是少引入一套系统：
- 业务表和向量表可以在同一事务与权限体系内管理；
- 过滤、JOIN、备份、审计和监控可以复用现有能力；
- 团队不需要同时维护关系库与新的分布式服务。
但这不等于 PGVector 永远够用。它的近似索引与过滤组合、持续写入、索引构建会和 PostgreSQL 其他负载竞争资源。官方文档也专门说明了过滤列索引、HNSW/IVFFlat 参数与 iterative scan 的影响。
所以，不要用“十万还是一百万”做唯一门槛。应在接近生产的环境里记录：
- 真实查询集的 Top-K 召回率；
- P50、P95、P99 延迟；
- 带租户/权限过滤后的结果完整性；
- 增量写入时查询是否明显抖动；
- 索引构建、备份与恢复窗口。
如果这些指标达标，继续使用 PGVector 通常比提前迁移更简单；如果不达标，再拿同一套数据和查询去测 Qdrant、Milvus 或托管服务。
4. 第二问：过滤和多租户是不是核心负载
企业知识库很少只做“全库语义相似度”。真实查询往往带着租户、部门、产品、区域和有效期等条件。
Qdrant 把结构化信息作为 payload 保存，并通过 payload index 参与过滤。Qdrant 官方索引文档说明，payload index 不只是加速字段过滤，还会参与过滤条件下的查询规划；官方建议在导入数据前建立需要使用的 payload index。
这类架构适合：
- 向量检索需要从业务 PostgreSQL 中独立扩容；
- 过滤条件较多，需要把向量和元数据一起管理；
- 多租户隔离是长期需求；
- 团队愿意为独立服务建立备份、监控和故障恢复流程。
单机部署简单，不代表生产高可用已经解决。Qdrant 的分布式部署文档明确区分单节点的成本优势与多节点副本的韧性。是否上集群，应由允许的停机窗口和数据恢复目标决定，而不是只看向量数量。
5. 第三问：是否真的需要分布式向量基础设施
Milvus 的优势在于它从架构上为独立、可扩展的向量基础设施设计。它同时提供 Lite、Standalone 和 Distributed，不同形态对应完全不同的运维责任。
进入 Milvus Distributed 候选前，至少确认：
- 团队是否已经稳定运行 Kubernetes；
- 元数据、对象存储、WAL、监控和备份由谁负责；
- 滚动升级、扩容、节点故障是否做过演练；
- 业务是否真的需要将写入、索引和查询分别扩展。
Milvus 架构文档展示了存储与计算分离、元数据存储、对象存储和 WAL 等组件。它说明了扩展能力来自哪里，也说明了复杂度不会凭空消失。
如果团队没有这些基础，Milvus Standalone 或托管服务可能比直接上 Distributed 更合适。选分布式产品的前提，是你愿意承担分布式系统的日常责任。
6. 第四问：是否把混合检索当作一等能力
企业语料里有大量型号、编码、人名和制度名称。纯向量检索擅长语义相近，但不一定擅长精确词；BM25 擅长关键词，却不理解近义表达。因此很多 RAG 系统最终都会同时使用两路召回。
Weaviate 的 Hybrid Search 直接融合向量结果与 BM25F 结果，并允许调整融合方式和权重。它适合把混合检索作为产品主路径、希望减少自行拼接两路召回工程的团队。
但“原生支持”不等于默认参数适合你的语料。仍要用真实查询验证：
- 型号与专有名词是否能被准确召回；
- 语义问题是否被关键词结果挤掉；
- 不同融合权重下，Top-K 的相关性如何变化；
- 中文分词、字段权重和 rerank 是否需要额外处理。
7. 第五问：托管服务买走了哪些责任
腾讯云 VectorDB 这类托管产品的核心价值不是“零成本”，而是把部分基础设施责任转成服务合同和账单。它更适合已经在同一云上运行、希望减少自建集群工作的团队。
评估托管服务时，不只看单价，还要问：
- 数据和备份位于哪个地域；
- 内网访问、跨可用区与出网如何计费；
- SLA 覆盖哪些故障，恢复目标是什么；
- 索引和数据如何导出，退出成本多高；
- 规格变更、扩容和版本升级是否需要停机；
- 监控指标与审计日志是否满足企业要求。
自建与托管的比较，应使用总拥有成本：实例与存储、网络、备份、监控、升级、值班和故障恢复都要计算。只比较一张价格表，会漏掉最贵的责任项。
8. 三种常见架构怎么取舍
架构 A：业务 PostgreSQL + PGVector
- 优点：系统少、权限和事务一致、SQL 能力完整；
- 风险：向量负载和业务负载共享资源，扩展边界受 PostgreSQL 架构影响；
- 适合：已有 PostgreSQL、团队希望先验证业务闭环的项目。
架构 B：业务库 + 独立向量库
- 优点：向量检索独立扩容，过滤和索引可按检索负载设计；
- 风险：数据同步、最终一致性、双库监控和备份都要自己解决；
- 适合：向量负载已明显独立，或多租户/过滤需求成为核心的项目。
架构 C：业务库 + 云上托管向量服务
- 优点：减少自建集群工作，可用性和扩缩容能力写进服务边界；
- 风险：网络、持续费用、数据导出与厂商锁定需要提前评估；
- 适合：云上业务、团队不希望长期维护独立向量基础设施的项目。
关于数据合规和系统接入，还可参考AI Agent 企业数据安全和企业系统集成平台怎么选。
9. 一张可执行的决策树
业务是否已经稳定使用 PostgreSQL？
├── 是
│ ├── 真实压测达标 → PGVector 起步，建立迁移指标
│ └── 过滤后召回/尾延迟/写入影响不达标 → 测独立向量库
└── 否
├── 复杂过滤或多租户是核心 → 优先测试 Qdrant
├── 混合检索希望开箱使用 → 把 Weaviate 纳入测试
├── 已有分布式基础设施、需要独立扩展 → 测 Milvus
└── 希望减少自建运维、业务在国内云 → 测托管 VectorDB
所有分支最后都要回到同一件事：
用真实语料、真实查询、真实过滤条件和目标可用性做压测与故障演练。
建议把迁移条件写进设计文档，而不是等线上变慢才讨论。例如：尾延迟连续超出业务目标、过滤后召回无法达标、索引维护影响业务写入、恢复窗口超过允许范围。触发条件一旦出现，就用同一套评测集比较下一种架构。
写在最后
向量数据库选型没有一个对所有公司都成立的答案。PGVector、Qdrant、Milvus、Weaviate 和腾讯云 VectorDB 的差别，首先是系统边界和责任边界，其次才是某次跑分。
更稳妥的顺序是：先定义查询质量、延迟、可用性和运维责任，再用官方能力筛出两三家候选，最后用自己的数据做验证。这样选出来的不是“网上最强的数据库”，而是团队真正能长期维护的那一套。
如果你正在做 RAG 选型，可把数据规模、向量维度、读写比、过滤条件、召回目标、可用性和现有技术栈整理成一页。开沿可以基于这组约束帮你做候选收敛、压测口径设计与现有系统接入评估。也可以继续参考AI Agent 厂商选型避坑和AI Agent 落地路线图。
