做 RAG 或语义检索，绕不开向量数据库这道选择题。市面上候选一堆，纠结的根源是需求差异大。这篇按真实使用体验，把三个主流候选放到同一把尺子上量一量。
先想清楚四个问题
选型前先回答：数据量多大？检索延迟要求多严？是否已经在用 PostgreSQL？运维人力有多少？这四个答案基本就能锁定选项，比看跑分榜有用。
pgvector：存量系统的最短路径
pgvector 是 PostgreSQL 的向量扩展。最大优势是不引入新组件：表、权限、备份、事务全部复用现有体系，SQL 直接做混合查询（结构化条件加向量相似度），中小规模场景一劳永逸。
实测百万元级向量、常规检索，性能完全够用。短板在高并发和亿级数据：索引构建慢，召回率调优需要懂 PostgreSQL 内核参数。已经在用 PG 的团队，先上 pgvector，遇到瓶颈再迁移——向量数据和业务数据同库的价值，用过的都回不去。
Qdrant：轻量专用的均衡之选
Rust 写的专用向量库，单二进制部署，内存占用和检索延迟表现优秀。过滤检索（先按条件筛再向量搜）是它的强项，API 设计清爽，官方客户端覆盖主流语言。
适合中等规模、需要独立向量服务、又不想背 Milvus 那套分布式复杂度的团队。它的分布式方案比 Milvus 简单，但超大规模场景的案例储备不如 Milvus 丰富。
Milvus：大规模场景的重型武器
专为亿级到百亿级向量设计，存算分离架构，水平扩展能力三者最强。生态也最全：多种索引类型、多租户能力都有。
代价是组件多、运维重：依赖消息队列和对象存储，监控指标一大堆，没有专职运维的团队上它会比较痛苦。另外资源吃得多，小规模跑 Milvus 属于高射炮打蚊子。
选型速查
数据百万级以内、已有 PG：pgvector，别犹豫。千万级、要独立部署、追求低延迟：Qdrant。亿级以上、多团队共用、有运维人力：Milvus。还在验证阶段：先上 pgvector 或 Qdrant 跑通业务，向量库的迁移成本远低于选型拖延的成本。
最后一句话：向量库选型是工程问题不是信仰问题，用你现有技术栈里最顺手的那个起步，把精力留给切块策略和检索评估——那才是效果的大头。
