向量数据库选型：先看数据规模，再看运维成本

向量数据库的选型，网上铺天盖地的对比表其实帮不了你多少——那些表大多在比「谁快几毫秒」，而真正决定你用错还是用对的，是四个更土的问题：你的数据有多大、你查什么、你有没有人运维、你肯花多少钱。这篇不堆参数，就按这四个维度把分界说清楚。

数据规模是第一把尺子

判断写进第一句：向量库的选型，八成由数据规模决定，剩下的才是性能和功能。

几万条向量、做个原型或者内部小工具，Chroma 是最省事的起点——嵌入式、零配置、Python 原生，一条 pip install chromadb 就能跑，服务器本身连登录都没有，别暴露到公网就行。到几十万到千万级，单机的 Rust 系 Qdrant 是综合最稳的那个：性能在第一梯队、部署一个二进制搞定、payload 过滤强，2026 年的发布节奏也最活跃。上亿级、要分布式横向扩展，基本只剩 Milvus 一个可靠的开源选择——分布式原生、多索引，代价是组件多、运维重，一台 4GB 的机器跑它会在建索引时冲到 2.6GB。夹在中间有个特殊情况：你已经在用 PostgreSQL，数据量又没到千万，pgvector 是最经济的——零新增组件、ACID、SQL 直接查，不必为了向量再养一套数据库。

托管还是自建

判断写进第一句：这一维问的不是「哪个库」，是「你有没有运维的人」。

完全不想碰基础设施，Pinecone 的托管体验是碾压级的成熟，代价是 vendor lock-in 和不便宜。想要性能又没运维，Qdrant 有免费额度和基于资源的定价，小规模起步不吃亏。能自建又求省，对象存储优先的新玩家（Turbopuffer、LanceDB）在大语料上能把成本压到内存优先方案的几分之一，但尾部延迟要自己评估。一句话：没运维能力就托管，有运维能力再看成本曲线。

查询模式决定了要不要混合检索

判断写进第一句：如果你从第一天就打算做关键词加向量的混合检索，选型会立刻收窄。

Weaviate 原生支持 BM25 加向量的融合，多模态摄取也最顺，代价是资源占用高；Qdrant 有稀疏向量也能凑合；pgvector 得你自己拼。反过来说，纯向量、纯语义，这一维就不用纠结。一个实测数字可以参考：geekflare 拿 10 万条向量跑，Qdrant 和 Weaviate 的 recall@10 都是 99.3%，Weaviate 中位 4.9ms 最快；Milvus 和 pgvector 默认设置下 recall 只有 94.8% 和 95.4%，pgvector 把 hnsw.ef_search 从 40 提到 100 能拉到 98.4%。这说明默认参数和调过参数，召回能差几个点，别拿默认配置当结论。

选型决策表

常见误区

一是用「谁最快」代替「谁合适」，几万条向量去上 Milvus，纯粹给自己找运维负担。二是默认参数当结论，上面那个召回 94.8% 和 99.3% 的差距就来自默认值。三是忽视成本维度——向量库的账单往往不是库本身，而是内存。四是忘了「先跑基准再签单」这最后一步：拿你自己的数据、你自己的查询模式，在候选库里各跑一轮，比看任何对比表都靠谱。选型没有最好，只有最合适，而「合适」是从你的规模和约束里长出来的，不是从别人的测评里抄来的。