2026 开源向量库全景对比：Milvus、Qdrant、Weaviate、pgvector 到底怎么选

AI 基础设施 2026-07-22 · 18 分钟

2026 年 6 月，一篇标题党味十足的实测博客在技术圈刷屏：作者在 5000 万向量的数据集上跑了一轮基准，声称 Postgres 上的 pgvector 把某些专用向量库"甩开了 11 倍"。评论区一半人拍手叫好，一半人质疑他没调好参数。抛开结论对错，这场争论本身说明了一件事——向量检索正在从"需要专门系统的黑科技"，退化成"数据库里的一种索引类型"。

与此同时，另一组数字也很有意思。截至 2026 年 7 月，在开源数据库赛道里，Milvus 的心智份额（mindshare）从去年的 5.8% 降到了 4.8%，而 Qdrant 从 3.6% 涨到 4.5%。老牌分布式方案在被更轻量的选项蚕食，而通用数据库扩展则在从另一头抢走"根本不需要专用库"的那部分需求。

选型这件事，从来不是"谁最快谁赢"。它取决于你的数据规模、是否已经有 Postgres、要不要混合检索、过滤命中率高不高、以及你的团队能扛多少运维复杂度。这篇文章把 2026 年主流的开源向量库拆开讲清楚，再补上一张和商用方案的成本对比，帮你在动手之前想明白。

先分清两条技术路线

在挑具体产品之前，得先明确一个大方向：向量检索有两条并行的技术路线，选错方向比选错产品的代价大得多。

第一条是专用向量数据库（dedicated vector database）。它们从头为向量检索设计，索引算法、内存布局、分布式架构都围绕"高维相似度搜索"这一件事优化。代表是 Milvus、Qdrant、Weaviate、Chroma、LanceDB。优势是性能天花板高、向量特性齐全；代价是你要多维护一套独立的数据库系统。

第二条是通用数据库扩展（in-database vector search）。它不新增组件，而是给你已有的 Postgres、Elasticsearch 装一个向量索引插件，让向量和业务数据待在同一个库里。代表是 pgvector、pgvectorscale、Elasticsearch/OpenSearch 的 kNN。优势是运维成本几乎为零、事务一致性天然具备；代价是极限性能和向量专属能力不如专用库。

2026 年最明显的趋势，是第二条路线在"吃"第一条路线的中小规模市场。一个被反复引用的判断标准是：如果你的业务数据本来就在 Postgres 里，且向量规模在 1 亿以下，大概率装个 pgvector 扩展就够了，不必再引入一个新数据库。下面先把专用库讲透，再回头看扩展式方案的边界在哪。

专用向量库五强

Milvus：亿级分布式的唯一充分验证方案

Milvus（Apache 2.0，LF AI & Data 基金会毕业项目，主要维护方 Zilliz）是目前唯一经过充分生产验证的亿级、十亿级向量分布式方案。它采用存算分离架构，支持 GPU 加速和多向量混合搜索，能在从笔记本到大规模 K8s 集群的各种环境里跑。

许可证是 Apache License 2.0，属于企业友好的宽松许可证，没有商业限制条款，不是 AGPL 或 SSPL，企业内嵌使用、修改、分发都没有法务合规风险。这一点在选型时经常被忽略，但对企业来说是硬指标。

Milvus 的短板是运维复杂度高。它依赖 etcd、MinIO/S3、Pulsar 等一堆外部组件，部署一套完整集群往往需要两天以上，还得有懂 K8s 的团队。多篇 2026 的对比都给出同一个结论：只有当你的数据量真的到了亿级、且有专门的运维团队时，Milvus 的复杂度才值得。如果你只是想快速上一个百万级 RAG，官方的 Milvus Lite 更适合本地验证，但那已经不是它的主场了。

Qdrant：通用生产首选

Qdrant（Apache 2.0，Rust 编写）在 2026 年被普遍视为开源向量库里的"速度标杆"。多个公开基准测试反复确认：千万级向量下它的 P99 延迟约 12–15ms，而 Weaviate 约 16–22ms、Milvus 约 18ms，Pinecone 更是到了 38ms 量级。更关键的是，它能匹配 Milvus 的吞吐（约 9500 QPS，P99 < 25ms），却不需要 ZooKeeper、Kafka 这类外部依赖。

它是单进程架构、内置 Raft 共识，部署比 Milvus 轻量太多。2026 年被反复提及的一个优势是"带过滤条件的高 QPS 检索"——Qdrant 走的是 payload 感知索引路线，过滤后的检索性能不怎么衰减。如果你后续要按某个实体维度（比如车型、地区、时间）做元数据过滤检索，这一点会非常相关。

综合延迟、吞吐、运维成本和过滤能力，Qdrant 是目前"自托管生产环境"里最稳妥的默认选择。心智份额同比上升也印证了这个趋势。

Weaviate：混合检索标杆

Weaviate（BSD-3 许可证，Go 编写）更像一个面向 AI 的对象数据库，原生混合检索（向量 + BM25）做得最好，还提供 GraphQL 查询接口。

所谓混合检索，在 2026 年已经标准化成一套流水线：词法检索（BM25，可选 SPLADE 稀疏向量）+ 稠密向量检索，通过 RRF（Reciprocal Rank Fusion，倒数排名融合）或加权线性组合合并，再接一个 cross-encoder 或 ColBERT 重排器。Weaviate 把这套融合做进了内核，还在 2026 推出了 Search Mode，在 BEIR、BRIGHT、LoTTe 等信息检索基准上和传统 Hybrid Search 做了对比。

如果你的知识库场景对召回率敏感、想要"关键词 + 向量"的深度融合而不是简单加权拼接，Weaviate 通常是混合搜索场景的首选。反过来，如果你只做纯语义检索，它的性能优势不如 Qdrant 明显。

Chroma：原型开发的亲儿子

Chroma（MIT 许可证）定位很清晰——原型开发和 LangChain/LlamaIndex 生态的"亲儿子"。它可嵌入、开箱即用、本地零成本运行，百万级以下表现不错，是快速验证想法的好工具。

但它的天花板也很明确。多个 2026 的实测显示，Chroma 在过滤查询上比 Qdrant、Milvus 慢 2–5 倍，大规模场景性能有限，一般不建议直接上生产。合理的用法是：用 Chroma 跑通原型和 demo，等业务真正要上线时再迁移到 Qdrant 或 pgvector。这一点和 MinerU 文档解析在 RAG 链路里的定位可以对照着看——不同环节该用轻量还是重型工具，取决于它是不是生产关键路径。

LanceDB：嵌入式新势力

LanceDB（开源，Rust 实现）是这两年冒出来的新选项，底层是 Lance 列式格式，一种 Arrow/Parquet 风格、为 AI 工作负载优化的分析型布局。它支持嵌入式单机部署，支持 Flat、HNSW、IVF 以及 IVF_HNSW_FLAT/PQ/SQ 等多种索引算法，原生支持 BM25/全文检索，并且和 Arrow 生态深度集成。

2026 年 LanceDB 的一个亮点是和 DuckDB 打通——你可以在 DuckDB 的 SQL 里直接跑向量检索、全文检索和混合检索，作为表函数使用，然后立刻 join、聚合、materialize，不用离开分析工作流。这让它在"多模态湖仓 + 无需单独部署服务"的场景里很有吸引力，比如本地测试、边缘部署、或者把向量检索嵌进数据管道。

它的短板是生产级分布式能力还不如 Milvus/Qdrant 成熟。如果你要的是"轻量、嵌入式、跟着数据走"，LanceDB 值得关注；如果要的是高可用分布式服务，它还没到那一步。

此外还有两个不能不提的老将。Vespa 是最早把向量检索和 BM25 结合起来的引擎（早于 Weaviate、Milvus），排序（ranking）能力非常强，适合多向量字段 + 复杂业务排序逻辑的场景，但学习曲线和运维成本都偏高，国内讨论和落地案例相对少。Elasticsearch / OpenSearch 则胜在 kNN + BM25 原生融合，能无缝接入已有的日志/搜索平台，缺点是向量检索性能不如专用库、索引体积大、内存消耗高——已经有 ES 集群、不想再加运维团队时可以考虑。

回迁 Postgres：向量检索正在"退化"成索引

前面说的都是"新增一套系统"。但 2026 年最强的一个信号，是不少团队从专用向量库"回迁"到了 Postgres。原因很朴素：维护额外一套数据库系统成本高、复杂，且往往没必要。对于 1 亿向量以下的生产级 RAG 应用，PostgreSQL 现在已经是一个相当强的选择。

具体有两个关键扩展：

pgvector（MIT）：提供 HNSW 和 IVFFlat 两种索引，事务一致性、SQL 过滤能力都很强。500 万向量以下，直接用 HNSW 索引就够。pgvector 0.8+ 还引入了迭代扫描（iterative scans），明显改善了高过滤率场景下的召回问题。
pgvectorscale（属于 pgai 家族）：在 pgvector 基础上加了 StreamingDiskANN 索引，把向量数据放到磁盘、大幅降低内存需求。1000 万向量以上，它通常是比纯 pgvector 更好的选择。

判断标准很简单：如果你的业务数据本来就在 Postgres 里，大概率不需要再引入一个数据库，装个扩展就够了。向量检索已经从"需要专门系统的黑科技"退化成了"一种索引类型"。

当然，Postgres 路线也有明确短板，主要在"高过滤率场景下的检索性能"。它的工作方式是先扫 HNSW 索引拿一批候选，再套过滤条件；如果过滤条件命中率很低，候选集里可能筛不出几条有效结果。这正是 Qdrant payload 感知索引的价值所在——它把过滤条件融进索引本身，而不是事后过滤。pgvector 0.8 的迭代扫描缓解了这个问题，但没有根治。

补充：和商用向量库的对比

聊完开源，绕不开一个现实问题：那我干脆买个商用托管服务，是不是更省心？确实省心，但 2026 年的账单数字会让你重新算这笔账。

商用阵营的标杆是 Pinecone——全托管、serverless、99.95% SLA、零运维，10M 向量以内 P95 延迟能压到 10ms 以下。对没有专职运维的小团队，它的"开箱即用"值这个钱。但问题出在规模化之后的成本上。多份 2026 的定价对比（均注明基于官方定价页快照）给出了相当扎眼的数字：

小规模（<1M 向量、10M ops/月）：Pinecone 的托管简单性完全够用，这个量级下 Pinecone（约 $70/月）甚至比 pgvector on RDS（约 $128/月）还便宜——因为专用库的 serverless 计费在低用量时比常驻实例划算。
中等规模（50M 向量）：Pinecone $800–1,200/月，pgvector 自托管（预留实例）$400–600/月，但后者要额外承担运维、备份、HNSW 内存开销。
大规模（100M 向量、10M 查询/月）：Pinecone 约 $12,690/月，同样的负载放到 Qdrant Cloud 约 $4,500/月，差了近 3 倍。这也是多数团队在这个规模开始考虑"逃离 Pinecone"的原因。

除了成本，2026 年关于 Pinecone 的抱怨也越来越响：查询模型比较"opinionated"、免费额度越收越紧、数据出不了它的云（合规团队要求数据留在自己 VPC 时就卡住了）、以及"本地和生产用不了同一个数据库"。这些正是越来越多团队从 Pinecone 迁到 Qdrant、Weaviate 的推力。

值得一提的是，开源方案大多也提供官方托管云，等于给了你"两头都占"的选项：

Zilliz Cloud：Milvus 原班团队打造的全托管服务，把 Milvus 重新工程化，主打极致扩展性和性能，适合已经认准 Milvus 技术栈、又不想自己运维 etcd/MinIO/Pulsar 的团队。
Qdrant Cloud：1GB 以内免费，成本曲线明显比 Pinecone 平缓，且随时能切回自托管。
Weaviate Cloud：托管或自托管都行，schema 灵活、多租户开箱即用。

所以"商用 vs 开源"在 2026 已经不是二选一。更务实的路径是：用开源方案（尤其是 Qdrant/Weaviate）起步，需要托管时上它们的官方云，既避开了 Pinecone 的成本陷阱和数据锁定，又保留了随时自托管的退路。这套"成本可控 + 无锁定"的思路，和我们在开源大模型选型里聊的逻辑是一致的。

一张对比速查表

维度	Milvus	Qdrant	Weaviate	Chroma	pgvector(scale)
协议	Apache 2.0	Apache 2.0	BSD-3	MIT	MIT
语言/架构	Go+C++，分布式	Rust，单进程	Go，模块化	Python，轻量	Postgres 扩展
千万级 P99 延迟	~18ms	~12ms	~16ms	一般不测大规模	视索引调优
混合检索	支持，较基础	支持但非主打	原生最强	弱	需自行拼 SQL+全文
运维复杂度	高	中	中	低	极低（复用现有 PG）
最佳定位	亿级分布式	通用生产首选	混合搜索/知识图谱	原型/本地测试	中小规模+已有 PG

对照商用方案：Pinecone 胜在零运维和企业级 SLA，但 10M 向量以上成本陡增、有数据锁定；LanceDB 则填补了"嵌入式、多模态湖仓"这个开源库的空白位置。

决策路径：三个问题定方向

选型别一上来就比延迟数字，先问自己三个问题：

问题一：你的业务数据在哪？ 如果本来就在 Postgres 里，且向量规模预计在 1 亿以下，先上 pgvector。数据量往 1000 万以上走，再加 pgvectorscale。这是 2026 年对绝大多数 B2B SaaS 最省事的答案。

问题二：规模会到多大？ 明确要到亿级、十亿级，且有 K8s 运维团队，选 Milvus（或它的托管版 Zilliz Cloud）。千万级、要自托管又不想背 Milvus 的运维包袱，选 Qdrant。

问题三：检索模式是什么？ 纯语义检索，Qdrant 的延迟和过滤能力最优。关键词 + 向量深度融合、对召回率敏感，Weaviate 的原生混合检索最强。只是做原型、跑 demo，Chroma 最快。要嵌入式、跟着数据管道走，LanceDB 值得一试。

把这三个问题的答案叠在一起，方向基本就定了。真正的建议是：别急着上专用向量库。先从最轻的方案起步，等业务规模、检索复杂度真的把你逼到瓶颈时，再迁移到专用库——迁移的工程成本，往往远低于一开始就背上一套重型系统的运维成本。这也是 2026 年整个赛道给出的共识：没有普适的"最强向量库"，只有最匹配你当前阶段的选择。

小结

2026 年的开源向量库版图，可以用一句话概括：两头挤压，中间分化。一头是 pgvector 把中小规模需求收编进 Postgres，让向量检索退化成一种索引；另一头是 Milvus 守着亿级分布式的高地。中间地带，Qdrant 凭延迟和运维平衡坐稳了通用生产首选，Weaviate 靠原生混合检索卡住知识库场景，Chroma 和 LanceDB 各自占据原型和嵌入式的生态位。

而商用方案的位置也在被重新定义——不再是"更省心所以更值"，而是"小规模够用、大规模太贵、还有数据锁定风险"，于是开源库的官方托管云成了更聪明的折中。

选型没有标准答案，但有清晰的决策逻辑：从数据在哪、规模多大、怎么检索这三个问题出发，先轻后重，让向量库跟着业务长，而不是让业务迁就向量库。

免责声明：本文所涉性能数据、延迟基准与定价均来自公开的第三方测试与厂商定价页，测试环境、硬件配置和版本不同会导致结果差异，文中数字仅供选型参考，不构成任何采购建议。云服务定价变动频繁，请在决策前以官方最新报价为准。内容为独立技术分析，与文中提及的任何厂商无商业关联。