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