数据库厂商，开始晒体检报告了

数据基础设施这个行业，过去十年的通用话术是：发布会讲架构，白皮书讲性能，定价页讲'联系我们'。

但最近两件事，正在把这个惯例撬开。10月15日，Databricks在官方博客发布工程实测文章《Sizing Lakebase Search：Lessons from a Real App and 4 Million Passages》，用自家内部应用Slide Hub和MIRACL英文数据集，把Lakebase Postgres的混合检索能力摊开在桌面上：热向量查询最低4毫秒，0.5 CU每月31~40美元可以作为生产基线。几乎同期，Cloudflare把事件流服务K2开放公测，直接把持久化日志建在R2对象存储上，produce延迟p99约1秒——而一位测试者报出的端到端p99是7.5秒，团队公开回应'高于预期'。

一个主动给出价格基线，一个公开承认短板。这不是巧合，而是一个信号：数据基础设施的竞争，正在从营销指标转向实测信任。

🧪 用自家App当测试集，这步棋不寻常

金句先行：最好的benchmark，是厂商自己每天都要用的那个系统。

Databricks这次没有选择标准的学术测试集跑分完事，而是拿内部应用Slide Hub做真实负载，结合MIRACL英文数据集约400万条passage，完整走了一遍容量规划的推演过程。测的是什么？混合检索——也就是向量检索加关键词检索的组合查询，这正是当下RAG类应用的检索底座。

结论里有三个数字值得记住：热向量查询最低4毫秒；容量规划可以按CU（计算单元）线性估算；0.5 CU每月31~40美元，被明确标注为'可作生产基线'。

注意这里的行文姿态。传统厂商发布性能数据，逻辑是'我很快，请相信我'；而Databricks这篇的逻辑是'我们是这样一步步算出你该买多少CU的，过程如下'。前者是广告，后者是工程文档。据多位接近人士的说法，这种'容量规划教程式'的博客，在客户侧的转化效果远好于跑分海报——因为采购者真正焦虑的不是峰值性能，而是'我这个规模的业务，到底要花多少钱'。

产业逻辑也很直白：当Lakebase Postgres这类服务化数据库进入AI检索场景，客户的核心决策点从'能不能'变成了'多大、多贵、多稳'。谁先把这个问题回答清楚，谁就掌握了对话的入口。

💰 CU定价透明化，serverless进入'可规划'时代

金句先行：serverless的下半场，比的不再是弹不支持，而是账单可不可算。

'0.5 CU每月31~40美元'这句话，表面是报价，实质是一份容量规划契约。它意味着客户可以在动手之前，用几个关键参数——文档量级、查询QPS、冷热数据比例——大致推导出月度成本区间。这在按量计费的serverless世界里并不常见：太多按量服务的问题恰恰是'账单不可预测'，用的时候爽，月底心惊。

这次实测公开的关键数字，可以汇总成一张表：

把'最低配置的生产基线'公开写出来，等于帮客户划了一条心理底线：小团队可以按这个数起步，成长之后再线性扩容。这背后是定价策略的转向——从'用得多收得多'的模糊计费，转向'给你一个可复制的起步模板'。而一旦有一家把账算得这么细，同赛道的对手就很难再回到'联系我们'的定价页了。

⚡ Cloudflare K2：对象存储开始'吞'消息队列

金句先行：当日志的耐久性可以托付给对象存储，专门的流基础设施就必须重新证明自己。

Cloudflare的K2目前处于公测阶段，定位是无服务器事件流服务，核心设计是把持久化日志直接建在R2对象存储之上。官方给出的produce延迟是p99约1秒，消费端计费与生产端按GB对齐——这个'读写同价'的对称设计，降低了用户的心智负担。

但真正有信息量的，是那个被公开讨论的瑕疵：一位测试者报告端到端p99为7.5秒，一位替团队回应的评论者承认这'高于预期'。 produce写入约1秒，端到端却到7.5秒，说明延迟主要消耗在消费侧的链路上——这恰恰是把日志建在对象存储上必须付出的代价：R2给的是近乎无限的容量弹性、极低的存储成本和与计算解耦的架构，但它的延迟特性天然不如本地盘上的传统日志系统。

这是一笔典型的工程交换：用延迟上限，换成本下限和运维下限。 对于事件溯源、审计日志、异步任务编排这类对秒级延迟不敏感的场景，K2的账是划算的；但对于金融撮合、实时风控这类毫秒级场景，它现在还不在牌桌上。

把这条链路画出来，逻辑会更清晰：

换句话说，K2不是要取代所有消息队列，而是在'事件流的存量大、查询和回放需求重'的那个细分市场下注——这个市场的规模，可能比大家想象的更大。

📊 公开短板，是一门越来越划算的生意

金句先行：在买方足够成熟的行业里，承认缺点是最便宜的营销。

把这两件事放在一起看，会发现一个共同姿态：Databricks公开了'热查询4毫秒'——注意，这是'热'数据的成绩，冷数据的代价它没有回避语境；Cloudflare公开了'7.5秒高于预期'的回应。两家都在主动暴露边界，而不是只画能力圆圈。

这不是偶然。数据基础设施的买方早已经被市场教育过了：圈内流传的一句老话是'所有厂商的benchmark都长在对自己最有利的地形上'。当跑分公信力见底，实测文档就成了新的信任货币——尤其是用自家生产系统当测试集、把容量规划方法论一起公开的做法，传递的潜台词是'我们自己也在这么用'。

用一张定位图来看，这两个产品正在占据的位置也很清楚：

Lakebase Postgres和K2都押在'成本敏感'的高位区，但路径不同：前者靠透明定价和容量规划拉信任，后者靠对象存储的成本结构换市场。而位于左下象限的传统托管服务，如果既给不出透明账单、又给不出实测文档，空间会被一点点挤压。

对买方来说，这个趋势是纯利好；对卖方来说，则是一道不得不答的题：你的下一个产品发布，敢不敢附一份含短板的实测报告？

🧭 给选型者的三步清单

金句先行：指标可以抄，容量规划抄不来，必须自己算一遍。

面对越来越多'晒实测'的厂商，选型者要做的是把对方的实测语境映射到自己的业务上。核心痛点与对应的解法，可以归纳成下面这张卡：

落到具体动作上：第一步，核对话语体系——对方的'4毫秒'是热数据、哪个数据规模、什么查询类型；第二步，把Slide Hub式的实测方法搬过来，用自己的一份真实数据跑一遍小规模容量测试；第三步，把延迟SLO和成本SLO写进同一场验收，让'快'和'便宜'在同一个表格里对账。

数据和AI应用的成本结构正在从'买服务器'变成'买可规划性'——谁能把这条曲线算清楚，谁就拿到了这个时代数据基础设施的入场券。下一次厂商发布会，别只看架构图了，先问一句：你们的实测文档，敢发吗？

小结

Databricks的4毫秒和0.5 CU定价基线，Cloudflare K2的1秒produce与被公开讨论的7.5秒，指向同一件事：数据基础设施的竞争维度，正在从'峰值性能叙事'转向'实测透明+成本可规划'。买方成熟度提升，正在倒逼卖方把工程细节当成产品的一部分。可以预见，未来一年'附实测报告的产品发布'会从加分项变成及格线——而那些仍然只有跑分海报和'联系我们'定价页的厂商，将率先失去对话资格。