Databricks一刀戳破弹性税：基线容量直降25%

Kunal Kande和Mike Jerome在博客后台敲下最后一行字，长出一口气。这两个Databricks的产品经理刚刚替所有运维工程师拨掉了一根扎了多年的刺——那个“要么为弹性多付30%溢价，要么锁死配置吃峰值成本”的可笑选择题，被他们一次性端走了。

新推出的Always-On定价瞄准Databricks Lakebase，一句话概括：保持无服务器灵活伸缩的底子，但基线计算资源的单价直接砍掉四分之一。没有包年锁定的对赌条款，自动扩展照样吃下突发流量。Kande在公告里扔了一句：“我们正在移除那个被迫接受的权衡。”

这句话背后的槽点，踩过云数据库坑的人都能秒懂。过去，但凡托管的Postgres服务，总有一条标尺横在面前：左侧写着“无服务器弹性”，右侧写着“预置实例固定成本”。选左边，每小时的单价蹭蹭上涨，负载恒稳的业务等于给空气付费；选右边，单价是下来了，可一旦夜间流量打个盹，超配的CPU就躺在账单上吃灰。更绝的是，两个模式之间切换意味停机或维护窗口，切换时机选在凌晨三点，咖啡钱都不给报销。

Databricks这次动手，对准的就是这套僵硬的商业模型。用他们的话说，Lakebase此前已经砍掉了几个Postgres的传统妥协——计算存储物理剥离、全页写入推进存储层、即时分支能力。现在，轮到定价模型挨刀。

具体怎么个“Always-On”法？操作层面非常简单，但背后逻辑值得掰扯。运维人员只需做两件事：第一步，关掉“缩小至零”的开关；第二步，设定自动伸缩范围。数据库连续运行满24小时后，基线容量自动切换到Always-On费率，25%的折扣静默生效。超出基线部分的用量，仍然按标准自动伸缩费率计费，一毛钱都不多收。高可用副本和最大规格的实例无需任何额外动作，自动合格。

“没有优化杂务。”这是公告里特别加粗的一句。听起来像针对某几家友商的吐槽，但实打实的场景是：你不需要每隔两周拉出监控图表，手动调整个实例规格，也不必在财年末被催促把预留实例的剩余额度用掉，否则过期作废。丹增的一个键盘快捷键，换掉你十几个深夜脚本。

为什么说“弹性税”是个伪命题？因为它本质上是对同一份计算能力的人为分层加价。无服务器架构让实例在闲时自动归零，归零时不收费，听起来很公道。但只要实例活着，每分钟都在计较高的小时费率。对于那些从来不会彻底空闲的生产负载——比如持续接收日志、始终在线的事务系统——归零是假象，溢价是事实。Always-On定价把这一层蒙眼布扯掉：对一直活着的基线，老老实实给个低价；对偶尔上冲的尖峰，继续按高速的弹性计费，互不争食。

用更刻薄的话讲，传统预置模式让你为可能发生的尖峰提前买下整台车，每天只开三公里却要付高速巡航的油耗；无服务器模式则是租车公司的按分钟计费，堵车时表照跳，到月底一算总共贵了四成。Now，Lakebase扔出一个方案：自己的车照开，但中低速巡航的油耗打折，只有踩地板油超车那几脚按瞬时高价算。

具体到账单上，这种混合计费怎么滚？假设一个Lakebase Postgres自动伸缩实例，基线70个虚拟核，平时稳在这个水位。开启Always-On后，这70个核的钱少付25%。下午市场开盘，流量瞬间推高到120核，多出的50个核照常按自动伸缩费率走。夜里流量退回基线，继续享受折扣。没有预留实例，没有按年预付，一切只要那个开关拨过去，24小时后自动触发。

这还只是底价。Databricks同步甩出一个叠加促销：从现在到2027年1月31日，额外再给50%的追加减免。两档折扣摞在一起，第一批吃螃蟹的团队几乎可以用重新定义预算的眼神审视自己那台Postgres实例。当然，促销有确切截止日期，不是永久。

那么，是否所有工作负载都要立刻切到Always-On？公告也坦诚划了一条线：对新建的、间歇性的、负载历史不明的任务，默认的缩至零模式依然保留。因为这类场景可能真的需要闲置时完全停机，避免按小时滚出最低消费。Always-On最适合的是那些已经有清晰基线、长线生产运行的系统——你很清楚它每小时最少吃多少资源，那就让这部分资源吃折扣，多余的临时爆发照常买。

梳理一下Lakebase这次的出招，能拆出五个吐槽点，同时也是五个实打实的交付：

一、彻底消灭“为弹性多付费”的行业潜规则，不再被迫在灵活性和单价之间做一次性赌博。二、干掉手工右规模的周常仪式，长期预留实例的威逼利诱不复存在。三、自动伸缩能力没有半格缩水，该冒烟照样冒烟，只是底薪打折。四、开启入口只有一个开关和一次范围设定，24小时后生效，透明到底，没有隐藏在控制台第五层的高级选项。五、叠加促销期明确，早期采用者有机会获得三重省钱——基础降价、自动伸缩费率分离、限时额外50%。

对运维人群而言，这剂药够猛。以往想压低成本，要么把数据库塞进预留实例的对赌协议，要么花时间磨集群的自动伸缩策略，夜间报警邮件经常来自“缩容后内存不足”的抓狂。现在，基线资源踏实吃25%的永久折扣，自动伸缩照常兜底尖峰，值班手机可以少响几次。

值得多琢磨一层的是，Lakebase早就不是传统的“某一种Postgres服务”。它先拆了计算和存储的绑定，又把全页写负担甩给存储层，还加上即时分支这种让开发者上瘾的功能。当计算独立、写放大被化解、克隆快到眨眼，弹性就变成了纯粹的资源伸缩问题。此刻再引入分级计费，相当于底层的存储和计算解耦已经为灵活定价铺好了路，商业模型最后一块积木卡入槽位。

难怪Kande和Jerome在公告结尾用的是“停止支付弹性税”这个颇具挑衅的短句。它暗示每个正乖乖为无服务器实例多付30%月费的团队，都是被行业惯例PUA了的受害者。其实，真正的省钱从来不是砍功能换来的，而是把人为的收费分层直接削平。

从现在起，所有维持基线运行的Lakebase Postgres实例，只要搬动一下开关，再等一天，就能看到计费控制台里那条平滑下降的曲线。没有连夜迁移，没有架构变更，没有长达数页的折扣规则说明。Always-On这个名字取得直白：它在说，只要你的数据库还活着，就该自动得折扣。

最后提醒一句：那个额外的50%促销折扣计时器已经启动，2027年1月31日到点关窗。有稳定基线的团队，越早打开开关，叠加省钱的周期越长。