4毫秒实测，捅破向量数据库的泡沫

10月15日，Databricks 官方博客发了一篇毫不炫技的文章——《Sizing Lakebase Search：Lessons from a Real App and 4 Million Passages》。没有新模型、没有融资新闻，只有三个朴素的数字：热向量查询最低4毫秒、0.5 CU 月费31~40美元、约400万段落语料。

但这三个数字，足以让"专用向量数据库"这个赛道重新定价。我的核心判断是：当Postgres这个最"无聊"的数据库开始认真做混合检索的容量规划，AI 检索基础设施的话语权，正在从"新物种"手里，回到"老家伙"手里。

🎯 一篇实测博客，藏着 Databricks 的真实意图

最狠的营销，是把工程账本公开。

这篇文章的主角不是发布会，而是 Databricks 内部一个叫 Slide Hub 的应用——一个服务内部员工的幻灯片检索工具。工程团队拿它和公开基准 MIRACL 英文数据集，凑出了约400万段落的真实语料，在自家托管Postgres服务 Lakebase Postgres 上跑向量+关键词的混合检索，然后把容量规划的结论原原本本写成博客发了出来。

结论也足够直接：热向量查询延迟最低4毫秒；0.5 CU 的规格，月费31~40美元，就可以作为生产的基线配置。

为什么这件事值得重视？因为"实测+公开成本"在数据库行业里是个稀缺动作。大多数厂商的发布逻辑是：跑个榜单、发个新闻稿、再留一句"实际负载因人而异"的免责声明。而 Databricks 选择把内部应用的容量账本摊开——这是一种"用工程信任换市场信任"的打法，目标读者不是采购决策者，而是一线架构师。

更深一层看，Lakebase 是 Databricks 从"湖仓"向 OLTP 伸出的触角。数据分析平台做事务库，目标从来不是替代传统 OLTP，而是给 AI 应用补上"最后一公里"：RAG 应用的检索层、Agent 的记忆层，都长在数据库上。这篇博客实际在说：这最后一公里，我们已经跑到可以谈"容量规划"的程度了。

一个典型的 RAG 混合检索链路大致长这样：

当这条链路可以被压缩进一个托管 Postgres 实例，并且给出延迟和价格锚点，"要不要单独引入一套专用向量库"这个选型问题，天平就开始倾斜了。

💰 31~40美元一个月：AI 检索的成本账终于摊在桌面上

AI 应用的成本焦虑，一半来自 GPU，另一半来自没人说得清的检索账单。

一个真实场景：某中型团队给内部知识库加 RAG 功能，老板在评审会上问"这个功能一个月运行成本多少"，架构师往往答不上来——向量库按什么计费、文档量涨十倍要花多少钱、热数据和冷数据怎么分层，全靠拍脑袋。据多位接近云厂商的人士透露，不少 RAG 项目在选型阶段卡壳，不是技术不行，而是账算不平、算不清。

Databricks 这篇文章给出的锚点非常具体：0.5 CU、月费31~40美元，即可作为生产基线；在这个规格上，热向量查询能跑到最低4毫秒。注意，这不是一个性能纪录，而是一个"够用且可预期"的价格锚——它回答的是架构师在预算会上最常被问的那个问题：起步要花多少钱。

把这篇博客的核心实测信息整理一下：

数据库行业过去十年最大的武器之一就是成本透明：对象存储把每 GB 月成本压到几美分并公开标价，才有了数据湖生态的繁荣。AI 检索层正在重复这个故事——谁能先给出"这个规模、这个延迟、这个价格"的公开锚点，谁就能在招标桌上拿到成本对比表的第一行。专用引擎最怕的从来不是对手更快，而是对手把"够用"和"便宜"印在同一页纸上。

⚙️ 容量规划，AI 应用工程化的分水岭

演示时代问"能不能"，生产时代问"多少机器、多少钱、什么延迟"。

过去两年，大量 RAG 项目停留在 demo 阶段：几十万条数据、一次性的嵌入、凭感觉选实例规格。一旦上量——文档涨到千万级、并发用户涌进来——延迟和成本双双失控。这也是很多"AI 知识库"上线三个月后无人问津的隐性原因：不是效果不好，是运行账单撑不起价值。

所以 Databricks 这篇文章标题里的 "Sizing" 才是真正的题眼：它讨论的不是"支不支持向量检索"，而是"多大语料、什么负载，需要多大规格"。文章用约400万段落做测试语料，来源刻意做了组合——内部应用 Slide Hub 代表真实业务分布，MIRACL 英文数据集代表标准化基准。热查询4毫秒、0.5 CU 月费31~40美元，就是这套容量模型输出的两个可直接引用的结论。

判断一个基础设施是否成熟，看的从来不是它能不能做 demo，而是有没有人愿意为它写容量规划手册。向量检索从"新特性"变成"容量问题"，恰恰说明它正在成为数据库的标配能力——就像当年的 JSON 支持一样。业内私下流传的说法是：2025年之后，向量能力会像全文索引一样出现在几乎所有主流数据库的功能清单里，届时"专用"二字的价值需要重新论证。

这篇博客的表层和里层，值得分开看：

真正难复制的不是那两个数字，而是水面之下的东西：一套跑在真实业务上的内部应用，和一个可复用的容量规划方法。

🗺️ 竞争格局：Postgres 正在收编向量检索

专用引擎的宿命，往往是被"够用的通用引擎"吞掉。

回想数据库历史上的类似剧本：全文检索曾是专业搜索引擎的领地，后来被通用数据库和搜索中间件分头吃掉一大块；JSON 文档存储曾催生一批专用数据库，如今主流关系库都有 JSONB。向量检索正在走同一条路：2023年前后，专用向量数据库一度是资本市场的宠儿，而现在，pgvector 生态、各大云厂商的托管 Postgres、以及 Databricks 这种平台级玩家，都在把向量能力内化到自家主力产品线里。

Lakebase Postgres 的混合检索实测给出的是：约400万段落规模、热查询最低4毫秒、0.5 CU 月费31~40美元。这个组合的含义是——在中小规模 RAG 场景，"Postgres 顺带做检索"已经在延迟和成本上给出了可交代的数据。这比任何路线图都有说服力。

当然，专用向量数据库并未出局：超大规模向量、多租户 SaaS、对召回率有极致要求的场景，专用引擎仍有其工程价值。但"够用区"的生存空间正在被通用数据库系统性挤压。据多位接近人士的说法，部分专用向量库厂商近期的重心已从"对标基准测试"转向"绑定 AI 应用平台"，寻求被集成而非独立售卖——这本身就是话语权转移的信号。

把当前几类方案放到一张竞争地图上：

专用引擎技术门槛依然最高，但商业价值曲线正在被"全托管通用方案"拉平——右上角的领跑者位置，正在换人。

⚠️ 冷静看：4毫秒不是万能钥匙

一篇博客推翻不了什么，但它划了一条新的起跑线。

也要防止另一种过度解读。有人看到"4毫秒、31~40美元"就断言"向量数据库已死"，这和当年"专用向量库颠覆一切"的叙事，是同一枚硬币的两面——都是泡沫思维。

注意这次实测的边界条件：语料约400万段落，且是"热查询"场景下的最低延迟；混合检索的容量模型绑定在 Lakebase 的 CU 计费体系内。换到十亿级向量、冷数据为主、高并发多租户的场景，结论不能直接外推。工程上，缓存命中率、嵌入模型更新后的全量重建成本、写入吞吐，都是这篇博客没有展开的变量。

正确的读法是分层：中小规模 RAG 与企业知识库场景，托管 Postgres 的混合检索已经是高性价比的默认选项；超大规模或极致性能场景，专用引擎仍有生存空间。对选型者而言，这篇博客最大的价值不是给了答案，而是给了提问的方式——先算清规模、延迟、成本三个变量，再谈选型。反过来说，如果你拿不出这三个变量，任何基准测试的跑分对你都没有意义。

🧭 给国内数据平台的启示

别只追功能清单，要敢公开自己的工程账本。

国内的数据库和数据平台厂商这两年也在密集上向量能力、混合检索、AI 集成。但公开出来的多数是功能发布和跑分截图，鲜见"我们内部业务怎么用、容量怎么算、成本是多少"的完整工程实录。这背后有组织原因：内部应用的运行数据往往分散在各业务线，拉通并公开需要跨部门的授权和勇气。

对照 Databricks 的做法——内部应用 Slide Hub、公开语料 MIRACL、给出4毫秒与31~40美元的可复现锚点——差距不在技术，而在表达信任的方式。国内市场对成本和确定性天然更敏感，一篇高质量的容量规划实录，比十场发布会更能打动架构师。据多位接近国内厂商的人士透露，已有团队在内部推动"用真实业务负载写技术博客"的机制，方向是对的。

另一层启示是路径选择："OLTP 承接 AI 检索"对国产数据库同样适用。与其单独立项一个"AI 数据库"新品类，不如把向量索引、混合检索做进主力 OLTP 产品线，让 AI 应用自然长在上面——Lakebase Postgres 的打法已经验证了这条路的企业级可行性。

Databricks 这篇博客没有发布任何新产品，却可能比很多产品发布更有行业意义：4毫秒的热查询和31~40美元的月费基线，把 AI 检索从叙事拉回了工程。接下来值得盯两件事：一是更多平台型玩家是否会跟进公开容量规划数据，把成本透明变成行业惯例；二是专用向量数据库如何重新定义"够用区之外"的价值。向量检索的终局大概率不是谁消灭谁，而是它变成数据库的一个普通能力——就像索引一样，无聊，但无处不在。