4毫秒向量查询，Databricks摊牌了

当整个行业还在为"该不该用独立向量数据库"吵得面红耳赤时，Databricks选择了另一种吵架方式：把内部应用的完整实测数据摊在桌上。10月15日，其官方博客发布工程实测文章《Sizing Lakebase Search：Lessons from a Real App and 4 Million Passages》，给出的数字足够具体——热向量查询最低4毫秒，0.5 CU每月31~40美元可作生产基线。这不是一次性能炫耀，而是一份定价与容量规划的"标尺公开"。本文的核心判断是：AI检索负载正在把事务库、检索引擎和湖仓重新捏合到一起，而竞争的主战场，已经从概念叙事切换到工程实测。

🧪 一场"反常"的公开实测

在数据行业，最稀缺的不是跑分，而是敢把跑分前提写清楚的人。

这次实测的样本选取很有意思。Databricks没有拿一个理想化的合成负载来撑门面，而是用了两个真实来源：一是公司内部应用 Slide Hub，二是学术界的 MIRACL 英文数据集，语料规模总计400万 passages。前者代表"自家 dogfood 的真实业务"，后者代表"可复现的公开基准"——两条腿走路，就是为了回答企业买家最关心的问题：我该买多大的容量？

按时间线看这件事的节奏：

• 10月15日：官方博客发布《Sizing Lakebase Search：Lessons from a Real App and 4 Million Passages》
• 实测对象：Lakebase Postgres 的混合检索能力
• 实测规模：400万 passages（Slide Hub 内部应用 + MIRACL 英文数据集）
• 核心结论：热向量查询最低4毫秒；0.5 CU 每月31~40美元，可作生产基线

注意"混合检索"这四个字。它意味着向量检索和传统检索路径要在一个系统里协同工作，容量规划不再只看向量索引的内存占用，还要考虑标量过滤、关键词命中的组合开销。这正是很多企业RAG项目上线后翻车的地方——单测时飞快，一上过滤条件延迟翻十倍。

业内私下流传的一种说法是：云厂商的AI检索类产品，售前最怕客户问"同样400万文档，你们要几个CU"。Databricks这次等于主动替客户把这道题先做了。产业逻辑很清晰：当检索基础设施从"能不能用"进入"要花多少钱"阶段，工程透明度本身就是竞争武器。

💰 31美元一个月，生产基线被改写

把容量规划做成"可预算的工作"，比把延迟跑低1毫秒更有产业价值。

先看实测给出的几个关键数字，它们构成了一条完整的决策链：

这组数字最大的意义在于基线的下移。0.5 CU、每月31~40美元——这个量级意味着一个中等规模的RAG检索服务，不再需要"先立项、再采购、后压测"的重流程。一个业务团队拿季度预算里的零头，就能把生产级的混合检索跑起来。

但务实地说，4毫秒这个数字也要冷静看待。它是热查询的最低值——也就是索引已被预热、查询命中缓存路径的场景。真实生产系统里，冷启动、高并发、过滤条件叠加，延迟都会高于这个数。Databricks自己也没回避这一点，文章标题写的就是"Lessons from a Real App"，重点在容量的规划方法，而不只是峰值性能。

据多位接近云厂商生态的人士观察，企业买家如今对AI检索类产品的核心诉求排序，已经从"延迟多少"变成"单位成本能扛多少QPS、扩容曲线长什么样"。这次实测直接回应了这个趋势。当成本被拆到CU颗粒度，数据库选型就从架构问题变成了财务问题——这是基础设施成熟期的典型标志。

🧱 物理布局，湖仓里最贵的一行决策

湖仓工程里 consequence 最大的决定，往往只占代码库里的一行配置。

同期另一份值得认真读的研究，来自 Kushal Kumar Vishwakarma 发表的基准评测《When Should You Use Liquid Clustering?》。作者在 Delta Lake 上，把 Liquid Clustering、ZOrdering 和传统分区三种物理布局策略，放在四类工作负载下做了对比，并发现了两种未在官方文档中记录的失败模式——作者判断，这些失败模式很可能正影响着今天还在运行的生产系统。

三种策略的核心特征，可以这样理解：

这份研究真正值得警惕的是那两个未文档化的失败模式。湖仓的物理布局决策之所以"最贵"，是因为它的代价是延迟兑现的：布局选错，当时看不出问题，等到数据量上到几十亿行、查询并发上来之后，每次扫描都在为当初那行配置买单。而修复往往意味着重写整个表的历史数据——计算费用、时间窗口、下游依赖，一样都省不掉。

从产业逻辑看，这份基准研究和 Databricks 的实测文章指向同一个判断：湖仓平台正在从"功能堆料"转向"行为可验证"。 Liquid Clustering 这类自动化布局方向是对的——它把最考验工程师经验的决策交给了系统自适应；但"未文档化的失败模式"提醒我们，自动化不等于免检，生产系统依然需要小规模试点验证。

🔗 检索、事务、湖仓正在合体

RAG没有杀死数据库，反而逼着数据平台把三条产品线焊在了一起。

把两条素材放在一起看，图景就完整了：Lakebase Postgres 解决的是"检索和事务在一个引擎里"，Delta Lake 的布局优化解决的是"海量历史数据的物理组织"——一个是AI应用的热路径，一个是数据平台的冷底座。AI检索负载恰好是那个把两者拉到一起的中间层：

这条链路解释了为什么 Databricks 要做 Lakebase：RAG应用的检索请求需要毫秒级响应，这天然是OLTP/检索引擎的地盘；但语料的加工、版本管理、治理审计，又是湖仓的强项。过去企业要在两套系统之间自己搭同步管道，维护两份一致性语义；现在平台厂商直接把这一层收编进产品线。

这也解释了独立向量数据库的处境。业内私下的一种声音是：检索能力正在从"独立品类"退化成"平台附赠功能"——就像当年缓存、消息队列陆续被云平台收编的剧本。当 Lakebase 这类方案能做到4毫秒热查询、31美元一个月起步，专用向量数据库的溢价空间就被从两端挤压：下有 pgvector 这类开源方案托底，上有一体化平台覆盖。

当然，判断不宜走极端。专用引擎在超大规模、极致调优场景仍有位置，但主流企业市场的默认选项，正在向"平台一体化"倾斜——这才是这次实测真正的产业信号。

🎯 格局重排与选型清单

格局没有定论，但选型的坐标系已经变了。

把当前主流的AI检索落地路径放进坐标系里看，维度不再是单纯的"性能高低"，而是工程透明度和一体化程度两个轴：

基于这次的公开信息，给正在做选型的团队一张务实的清单：

1. 先做容量试点，再谈架构。用官方基线（0.5 CU、每月31~40美元）搭一个小规模生产级试点，拿自己的真实语料复测延迟和成本曲线，别直接采信任何厂商的峰值数字——包括这一次的4毫秒。

2. 把过滤条件纳入压测。混合检索的成本大头往往在向量+标量的组合查询上，单跑向量索引的延迟没有参考价值。

3. 布局策略先验证再固化。无论选 Liquid Clustering 还是传统方案，鉴于仍有未文档化的失败模式存在，生产表务必先在小数据量上验证行为，并保留回退路径。

4. 警惕一体化锁定。平台一体化降低了运维成本，但也加深了绑定程度，关键数据的导出通道和开放表格式兼容性要提前确认。

一句话总结这个阶段的竞争逻辑：厂商开始用"可规划性"争夺买家，而不是用"概念领先性"争夺头条。

小结

4毫秒和31美元，单看是两条产品新闻，连起来看是一条产业分水岭：AI数据基础设施的竞争，已经从"有没有检索能力"进入"值多少钱、可不可以进预算表"的阶段。物理布局层面，自动化策略与传统手段的边界仍在被基准研究不断重画，自动化不等于免检。往前看，随着更多厂商跟进公开实测，容量规划文档会成为AI检索产品的标配，而检索、事务与湖仓的一体化融合，将是未来两年数据平台市场最确定的整合方向。