向量数据库，正在被SQL吞掉

过去两年，向量数据库是 AI 基础设施里最热闹的赛道，融资、创业、站队，样样不缺。而当 Databricks 在运行时里给出 NEAREST BY join——把最近邻检索直接写成一条 SQL 子句——风向变了。向量搜索起家时是个 serving 问题，经典用例是聊天机器人；现在，它正在被重新定义为一个查询问题、一个数据平台问题。本文的核心判断是：独立向量数据库的『中间层叙事』，正在被湖仓平台系统性收编，而这不是第一次，也不会是最后一次。

🧭 起点，确实是个 serving 问题

每一代专用引擎，都诞生于一个当时通用引擎做不好的负载。

把时间拨回 2023 年。一家做企业知识库问答的创业团队，典型架构是这样的：文档切分、调用 embedding 模型、写入 Pinecone 或 Milvus，业务数据躺在 PostgreSQL 里，两套系统之间靠一条同步管道维持默契。问答链路每回答一个问题，先去向量库里召回，再回头查业务库补元数据、拼权限。

这个架构之所以成立，是因为向量搜索最初的形态就是 serving 问题：低延迟、高 QPS、读多写少、对召回质量极度敏感。这恰恰是专用向量库擅长的形状——ANN 索引常驻内存、读写分离、按查询量计费，产品逻辑清晰，增长也快。那两年，「RAG 要不要专门的向量数据库」几乎成了架构评审的必答题。

但故事讲到这里有个被忽略的细节：serving 场景塑造了独立向量库的产品形态，却不等于企业落地的瓶颈也在 serving。真正让工程团队熬夜的，往往不是查询慢几百毫秒，而是查询之前的那些事——同步、更新、权限、重刷。专用引擎回答的是「怎么查得快」，而企业问的是「数据凭什么是对的」。

这中间的落差，就是后来一切变化的原点。

⚖️ 两条管道的一致性税

同步管道的每一米，都在收税。

向量检索进入企业后，最先暴露的是双写架构的脆弱性。源数据改了，向量没更新；embedding 模型换了一版，全量重刷一遍；权限过滤要跨两个系统拼接，血缘断在管道里。数据圈里流传一句半开玩笑的话：RAG 项目一半的工程量，花在让两份数据假装是同一份数据上。这话未必是精确统计，但方向没错——痛点不在检索端，在数据端。

NEAREST BY 的思路正是冲着这个落差去的：把最近邻检索作为 join 的一种形式，内联进 SQL。embedding 不再是被搬运出去的副本，而是和源数据、元数据同处一份数据里的普通列；过滤、权限、血缘，全部复用平台已有的机制，检索与关联在同一个运行时内完成。两类架构的差异，一张图就能看明白：

上面的路径是传统双管道：数据被搬运一次、算一次嵌入、存一份副本，应用再从独立的向量库召回。下面的路径是平台内检索：嵌入就是数据本身，检索就是一个查询算子。

这背后的产业逻辑是老熟人——数据重力。计算倾向于向数据所在处迁移，因为搬运永远比计算贵。湖仓手里握着源数据、权限模型和血缘体系，向量检索作为高频负载内联进 SQL，是顺理成章的收编动作。用户省下的不只是一条管道，还有那份持续缴纳的『一致性税』。

🔍 专用引擎的护城河还剩多少

收编不等于替代，市场会分层，而不是一边倒。

需要先说清楚一件事：NEAREST BY 这类方案的出现，并不意味着 Pinecone、Milvus、Qdrant 们立刻失效。向量检索市场至少有三个形态并存，各自的甜蜜点不同：

据多位接近头部 AI 应用团队的观察，真正需要亿级向量、P99 压到毫秒级的在线 serving 场景，仍然是专用引擎的主场——那是它们用多年索引工程换来的护城河，短期不会被 SQL 语法冲垮。

但另一端的市场正在松动。企业内部的批量相似检索、权限敏感的知识库查询、面向分析师的即席召回——这些场景对延迟没那么苛刻，对工程复杂度和成本却极其敏感。过去它们被迫搭一套向量库，现在一条 SQL 就能覆盖，选择的天平自然倾斜。

更关键的是量级对比：企业里的向量检索需求，绝大多数落在『分析型』而非『serving 型』。专用引擎守得住塔尖，守不住塔身。这不是谁更快的问题，是谁离数据更近的问题。

📜 又一次熟悉的收编

数据库史上，专用与通用是交替出现的两条主线，而收编的剧本从未变过。

把向量检索的故事放进更大的坐标系，会发现这是一场重播。行业轨迹大致是：

• 2021 年前后：pgvector 等开源扩展出现，向量检索开始在关系库里试探；
• 2023 年：RAG 带火专用向量数据库，成为融资与技术叙事的双料热点；
• 2024 年：云数仓与湖仓平台陆续把向量能力纳入自家版图，Snowflake 等厂商跟进类似方向；
• 2025 年：Databricks 在运行时层面推出 NEAREST BY join，检索成为 SQL 的一等公民。

每一步都有前例可循。全文检索当年是 Elasticsearch 的天下，如今各主流数据库都内置了全文能力；JSON 文档存储一度是独立文档库的叙事，最后被关系库的 JSON 类型消解了大半；机器学习平台也走过同样的路，从独立工具链被逐步吸进数据平台。剧本高度一致：专用引擎引爆一个负载 → 负载被验证为大众化需求 → 平台把它内联成基础能力 → 中间层退守高门槛场景。

判断哪些负载会被收编，标准其实只有两条：一是需求是否足够大众化，二是数据是否已经重仓在平台里。向量检索恰好两条全占——所有做 RAG 的团队都要做检索，而所有 RAG 要检索的原始数据，本来就躺在湖仓和数仓里。

对独立厂商而言，接下来的路径很清楚：要么向下扎进 serving 深水区，拼索引工程和硬件效率；要么向上做检索之上的应用语义层。卡在中间、只提供『一个能存向量的库』的产品，生存空间会被持续挤压。

小结

NEAREST BY 的意义，不在于把向量检索做得多快，而在于把它做得离数据多近。对用户来说，少一条同步管道，就少一份一致性税；对赛道来说，独立向量库退守高门槛 serving，平台吃走最宽的长尾。往前看，这场收编大概率只是开始——当检索成为 SQL 的一等公民，多模态向量、更丰富的语义算子被纳入运行时，只是时间问题。数据平台的历史一再证明：能留在 SQL 里的能力，最终都会变成平台的地基；留在 SQL 外面的，才需要为生存而战。