向量数据库2026：Milvus 3.0、Qdrant与Postgres之争

向量数据库进入分水岭时刻

2026年，任何将RAG（检索增强生成）流水线投入生产的人都不可能绕开向量数据库。它已是企业级AI架构的默认标配，也是支撑大模型落地检索能力的核心基础设施。但这个赛道正在经历深刻的分化：一端是专用向量数据库向数据湖与智能体（Agent）场景纵深演进，另一端是PostgreSQL搭配pgvector以"够用就好"的姿态吞食中小规模用例。

据RSS源报道，2026年7月，Zilliz发布了Milvus 3.0，其核心变化是将向量检索直接运行在数据湖之上；同年3月，Qdrant完成了5000万美元B轮融资，并伴随智能体工作负载持续增长；而PostgreSQL搭配pgvector则在小规模场景中拿下越来越大的份额。三股力量同时发力，勾勒出这一年的竞争格局。

Milvus 3.0：把向量检索推进数据湖

Milvus 3.0最引人注目的架构决策，是让向量检索直接在数据湖内完成，而不是把数据从湖仓搬到专用向量库再计算。这一变化的意义不只是性能，更是数据治理和成本结构。

传统RAG架构里，原始文档往往存放在对象存储或数据湖中，向量库则是另一套需要同步的独立系统。数据在两处之间来回搬运，带来一致性风险、额外的运维负担以及双份存储成本。Milvus 3.0把检索下沉到数据湖，相当于让向量能力成为数据平台的原生能力，而非外挂组件。

对于已经以数据湖为中心构建数据栈的企业，这降低了引入向量检索的迁移门槛。不过，这种架构对数据湖本身的格式与计算引擎提出了更高要求，实际落地效果仍取决于企业现有的数据基础设施成熟度。

Qdrant：融资5000万美元，押注智能体工作负载

Qdrant在2026年3月完成5000万美元B轮融资，资本市场的信心与其增长动因直接相关——智能体工作负载正在成为向量数据库新的需求引擎。

传统RAG的查询模式相对简单：一次检索、一次生成。而智能体场景下，检索是反复、多轮、带状态的过程。Agent需要记忆、需要多跳检索、需要在执行过程中不断写入和更新向量。这对数据库的写入吞吐、过滤能力、以及低延迟的实时更新提出了不同于批处理式RAG的要求。

Qdrant近年的产品演进方向与这一趋势吻合。相比把向量库当成静态索引，它更强调实时性和过滤精度，这对于需要频繁读写的Agent记忆系统尤为关键。5000万美元的融资将主要用于扩大工程与市场团队，能否在专用向量库的竞争中守住差异化，取决于它在Agent场景中能否形成足够强的性能与生态壁垒。

理解智能体工作负载与向量库的关系，需要先区分两种检索范式。传统RAG的检索是无状态的：用户提问，系统从索引里取回若干相关片段，拼进提示词交给模型生成，流程结束，向量库在此过程中基本只读。而智能体（Agent）是有状态的：它会把自身的推理轨迹、工具调用结果、任务目标等写入长期记忆，下一轮执行时再检索回来，形成"写入—检索—再写入"的循环。这种循环对数据库提出了几项硬性要求：其一，写入吞吐要能跟上高频的小批量插入与更新，而不是只擅长离线批量建索引；其二，过滤能力要强，因为智能体往往需要按用户、会话、时间、任务类型等元数据做条件过滤后再做相似度检索；其三，更新延迟要低，记忆一旦过期或纠错就要立刻生效。这些要求叠加起来，使得"静态索引"型向量库在Agent场景中容易成为瓶颈，也为专攻实时读写的产品留出了差异化空间。

Postgres + pgvector：小场景的"默认答案"

如果说Milvus和Qdrant代表专用向量库的纵深路线，PostgreSQL搭配pgvector则代表了另一条路径：把向量能力嵌入企业已有的关系型数据库。

对于中小规模用例，pgvector的优势是显而易见的。团队不需要引入一套新的数据库系统，不需要额外的运维技能栈，事务一致性、备份恢复、权限体系都可以复用Postgres现有能力。当向量规模在百万级以内、检索延迟要求不极端时，pgvector往往"足够好"。

这种"够用即可"的逻辑正在让pgvector在中小场景中占据越来越大的份额。它的威胁不在于性能超越专用向量库，而在于它把向量检索从"要不要引入新系统"的问题，变成了"现有数据库加个扩展"的问题——决策成本大幅降低。

pgvector 是 PostgreSQL 的官方风格扩展，它为关系表新增了 vector 数据类型，并支持 L2 距离、内积、余弦距离等相似度运算符，以及 IVFFlat 和 HNSW 两类近似最近邻索引。真正让它在中小场景具备吸引力的，不只是"少装一套系统"，而是它与 Postgres 生态的原生融合：向量列可以和普通列写在同一条 SQL 里，用 WHERE 做元数据过滤、用事务保证写入一致性、用既有的备份与复制机制做容灾，还能通过行级安全策略控制访问。代价则是可扩展性上限——单机内存和索引结构的约束使得它在千万级以上向量、或极高并发低延迟要求下，通常需要分片或专门的分布式方案来兜底。因此 pgvector 的定位更接近"覆盖长尾场景的默认选项"，而非取代为海量向量设计架构的专用库。

三足鼎立背后的真实问题

把这三条路线放在一起看，2026年向量数据库的核心问题已经不再是"哪个库更快"，而是"向量能力应该放在数据栈的哪一层"。

Milvus 3.0的答案是：放进数据湖，成为数据平台的一部分。Qdrant的答案是：作为独立的实时检索层，服务智能体这类高频读写场景。Postgres + pgvector的答案是：不需要独立层，扩展现有关系库即可。

这三种答案对应的是三类不同的用户：以数据湖为中心的大企业、构建Agent应用的团队、以及希望以最低成本起步的中小团队。专用向量库不会消失，但当pgvector覆盖了足够多的"小用例"，专用库必须向上证明自己在规模、实时性和Agent场景中的不可替代性。

对于正在选型的技术团队，真正需要回答的问题不是"选哪个数据库"，而是先判断自己的数据规模、查询模式和基础设施现状——因为2026年的向量数据库市场，已经不存在一个放之四海皆准的默认答案。