向量数据库选型：Milvus、Qdrant 与 pgvector 的分层决策

向量数据库选型最常见的错误，是还没定义问题就急着选组件。Milvus、Qdrant、pgvector 三者覆盖了从"Postgres 里加一列"到"十亿级分布式检索"的完整光谱，但它们不是同一个东西的三种品牌，而是不同规模、不同运维能力下的分层选择。本文按数据规模、召回质量、运维成本三个维度给出决策标准，并给出一条从轻到重的起步路径。

先回答三个问题，再谈选型

• 规模：向量总量、单条向量维度、每日增量。万级到百万级与十亿级是完全不同的工程问题；
• 召回要求：是否需要标量过滤、是否需要与关键词（BM25/稀疏向量）混合检索、recall@k 有没有硬指标；
• 运维边界：团队有没有能力维护分布式组件、有没有现成的 PostgreSQL、对延迟和 QPS 的要求。

三个选项的本质差异

pgvector：零新增组件的起步选项

pgvector 是 PostgreSQL 扩展，给表加一列 vector(n) 就能存向量，用 <=> 运算符做相似度排序。它继承了 Postgres 的一切：事务一致性、SQL、行级过滤、备份恢复。索引层面支持 HNSW 与 IVFFlat，数据量在千万级以内、单机内存能覆盖时表现稳定。

优点：没有新组件，起步成本最低，向量与业务元数据同库，过滤条件就是普通 WHERE，一致性天然有保证。缺点：单机扩展上限明显，HNSW 索引构建占用内存、写入与建索引互相争资源；分布式与多副本要靠 Postgres 生态（流复制、扩展方案）自行解决，十亿级和高 QPS 场景会先到瓶颈。

Qdrant：单二进制的中量级选择

Qdrant 用 Rust 实现，核心是一个可独立运行的二进制，部署形态从嵌入式到分片复制集群都有。它的特点是把"向量 + payload 过滤"作为一等公民：每条向量可以挂任意结构化 payload，查询时先用 payload 条件过滤再做 ANN 检索，避免"先全量召回再过滤"的精度损失。内置 HNSW、标量/乘积/二值量化，以及稀疏向量与 BM25 混合检索，多语言 SDK 与 REST/gRPC 接口齐全。

优点：部署简单（一个进程即可起步）、过滤与混合检索体验完整、单机到小集群的扩展平滑，运维负担显著低于重型分布式系统。缺点：真正的多租户与超大集群能力弱于 Milvus 这类为分布式设计的系统，超大规模（百亿级）与 GPU 加速不是它的主场。

Milvus：面向十亿级与高 QPS 的分布式系统

Milvus 是围绕"大规模向量检索"设计的分布式系统：元数据（etcd）、对象存储、消息队列、计算节点分层，支持 HNSW、IVF、SCANN、DiskANN 等多种索引与 GPU 加速，能把索引分片到多节点并行查询，面向十亿级数据与高并发在线服务。

优点：规模上限最高，索引与查询弹性扩展，适合对 QPS、延迟、数据量都有硬指标的生产检索服务。缺点：组件多、运维重——一套最小集群也要同时管理多个角色与依赖组件，评估成本、排障成本都比前两者高一个量级。为百万级、内部工具类场景上 Milvus，往往是过度设计。

决策标准：按分层而非按品牌

• 数据量 < 100 万、团队已有 Postgres、检索是"附加能力"：选 pgvector。先跑通业务，不要引入任何新系统；
• 100 万–1 亿、需要标量过滤/混合检索、希望单进程起步：选 Qdrant。它是"中间地带"的性价比选择，单机不够时再开分片；
• > 1 亿、或对 QPS/延迟有服务级 SLA、需要 GPU 或多副本弹性：选 Milvus，并为此预留专门的运维资源；
• 若团队已有 Elasticsearch 且数据规模不大，也可以评估其向量检索能力——但那是另一个选型维度，本文不展开。

召回质量：别只看"相似度分数"

召回质量由算法、索引参数与过滤策略共同决定，选型时用同一份评测集对比三个候选：

• recall@k：在标注好的查询集上，比较 Top-k 命中率；
• 过滤后的召回：加标量过滤条件后再测 recall，很多系统"不过滤很好、一过滤就崩"；
• 索引参数：HNSW 的 M、ef_construction、ef_search 直接影响召回与资源，POC 时要记录参数组合，而不是默认值；
• 延迟与 QPS：p95 延迟和吞吐必须用并发压测得出，单条查询快不代表扛得住并发。

索引与内存预算：选型前先算账

向量检索的性能几乎由索引与内存决定，这部分账要在选型前算清：

• HNSW 常驻内存：HNSW 索引通常需要把图结构放在内存里，占用约为向量数据本身的数倍（取决于 M 与 ef_construction 参数）。用"向量数 × 维度 × 4 字节 × 放大系数"做粗估，避免出现"数据装得下、索引装不下"；
• IVFFlat 与 HNSW 的取舍：IVFFlat 建索引快、内存占用小，但召回率受聚类数量与 probe 参数影响，适合对召回不极端、需要快速建索引的场景；HNSW 召回高、查询快，代价是建索引耗时与内存更高；
• 量化降内存：标量/乘积/二值量化能显著降低内存占用，代价是召回损失，必须在你自己的评测集上实测，不能照搬厂商宣传；
• DiskANN 类索引：把部分数据放磁盘，适合内存受限的超大规模场景，但延迟高于纯内存索引，在线服务要谨慎评估。

评测集与上线路径：让切换可回退

• 评测集怎么建：包含三类样本——精确关键词召回样本、带标量过滤的样本、边界/模糊语义样本。数量不用大（几百条即可），但要覆盖真实业务分布，避免拿公开数据集自嗨；
• 双写 + 影子查询上线：新老系统并行运行一段时间，用同一查询集对比结果与延迟，任何一项不达标都可回退，不搞"一刀切切换"；
• 固化为回归资产：把评测脚本、索引参数与基线结果存进仓库，后续引擎升级或参数变更时能自动回归，防止"换版本就退步"。

起步与迁移建议：从轻到重，留好逃生通道

1. 用 pgvector 做 POC：业务先跑起来，验证向量化方案本身的可行性，同时积累评测集；
2. 定评测集再扩容：数据量逼近千万级、过滤需求变复杂时，用同一评测集对比 Qdrant 与 Milvus，用数据说话而不是凭架构偏好；
3. 迁移只搬向量与元数据：导出向量、在目标库重建索引、双写过渡一段时间再切换，任何一步不达标都可回退；
4. 为索引留资源预算：HNSW 索引在内存中运行时检索最快，选型时要算清内存成本，避免"数据装得下、索引装不下"。

下一步：先明确你的规模档位与过滤需求，用 pgvector 跑通一个最小 POC 并固化评测集；当数据量跨过百万级或过滤召回不达标时，再按本文标准引入 Qdrant 或 Milvus，并为索引内存与运维人力预留预算。