pgvector 在本地基准里赢了 7/7，为什么大规模还是得换 Milvus

一场覆盖 14 个测试用例、从摄入到并发查询全生命周期的向量数据库基准，在 2026 年 4 月给出了一个让很多人意外的结果：在本地部署类别里，pgvector 赢了全部 7 个类别；在云托管类别里，Qdrant 赢了 6/7。在 10,000 行 Amazon 商品数据集上，pgvector 的摄入速度是 1943.7 行/秒，语义搜索 p50 是 5.71ms，10 用户并发峰值 QPS 是 1212.3；作为对比，Pinecone Serverless 的语义搜索 p50 是 300.23ms，峰值 QPS 是 40.3。这些数字看起来很明确：如果你已经跑着 PostgreSQL，向量规模在千万级以内，pgvector 不只是“够用”，它在很多维度上就是最好的选择。

但同一时期的多份选型材料给出了一个同样明确的边界：pgvector 的规模上限大致在千万级，单机扩展会遇到明显天花板，HNSW 索引构建占用内存、写入与建索引互相争资源，分布式与多副本要靠 PostgreSQL 生态自行解决，十亿级和高 QPS 场景会先碰到瓶颈。2026 年的市场共识也因此分层：中小规模优先 pgvector 或 LanceDB，大规模走 Milvus，商业托管看 Pinecone 或 Qdrant Cloud。

这个分层的关键变量不是“谁更快”，而是过滤条件和扩展模型。pgvector 的过滤走 SQL WHERE，在 HNSW 索引下，候选从图中出来之后再过滤，一个高度选择性的过滤条件可能砍掉召回率，除非你主动扩大搜索范围。Qdrant 的 payload 索引在图的遍历过程中就被查询，过滤的选择性对召回的伤害更小；它原生支持稀疏向量，稠密和稀疏查询可以在一次请求里融合。如果你每次检索都带着租户 ID、权限条件、时间范围，而且这些条件不是“可选优化”而是“必须命中”，过滤语义的差异会比纯 ANN 延迟的差异更影响实际效果。

Qdrant 在云类别里赢了 6/7，但它的生态规模和超大规模生产案例仍然少于 Milvus。Milvus 的定位是亿到百亿级的工业主力，代价是运维复杂度最高：多组件、对象存储加消息队列、索引类型多、调参空间大。LanceDB 走的是另一条路：嵌入式加湖原生，运维最轻，适合中等规模和对数据湖集成有需求的场景。

一个务实的选型顺序是：先看你的向量规模是否真的会超过千万级，再看过滤条件是“偶尔用”还是“每次都必须命中”，然后看团队有没有人愿意维护一个独立的向量服务。如果三个答案分别是“不会”“偶尔”“没有”，pgvector 是默认答案，而且它在本地基准里的表现支持这个选择。如果过滤是核心路径、规模在亿级、团队有运维能力，Qdrant 或 Milvus 才进入视野。基准测试证明的是“在它的测试条件下谁快”，选型要回答的是“在你的数据形态和查询模式下，谁不会先撞墙”。