Databricks 于 2026 年 9 月 30 日发布 Lakebase Postgres 成本优化指南：缩容到零只到 32 CU，热工作集须装进缓存。 这条指南落在「前置部署」Forward Deployed Engineer（FDE）的交付成本段：把应用数据库的同步范围、计算规格与恢复策略一次定对，别等上线之后才因为账单返工。对在客户现场交付应用数据库的「前置部署」Forward Deployed Engineer（FDE）来说，成本是客户验收时最先被追问的一项，而这篇指南给的是一套可以逐条对齐的配置口径。 原文《A practical guide to cost optimization with Lakebase Postgres》由 Databricks 的 Benjamin Nwokeleme、Firas Farah 与 Jen Darrouzet 撰写，2026 年 9 月 30 日发布。Lakebase 是 Databricks 的托管 Postgres，定位是给数据应用与 AI Agent 用的在线事务库，与数据湖共用同一套治理。原文的分工很清楚：先讲架构自带的省钱点，再给四类可调配置，最后说账单在哪张系统表里查。 第一块是不用付配置代价就能拿到的部分。Lakebase 把「存储与计算分离」当成默认架构：数据库分支与父分支共享同一份底层存储，只记录分叉之后的变更，因此开发与测试环境不需要各复制一份生产数据的物理副本。「读副本」是独立计算实例但读同一份存储，加读能力不增加存储份数；「高可用」只是跨可用区加冗余计算，存储层同样不翻倍。这些省钱点不需要任何调参，局限是它们对单副本的写吞吐上限没有帮助，写放大仍然由主计算承担。前置部署 Forward Deployed Engineer（FDE）在给客户报架构时，可以先把这一块说成不增加成本的默认项。 第二个动作是缩小同步范围。原文点名称最常见的错误是把一张很大的 Delta 表整表推进 Lakebase，而应用其实只查其中一小块活跃子集；这会把 Lakebase 存储与同步成本一起推高，某些场景下还会连带拖慢性能。做法是用一个「物化视图」把应用真正需要的数据圈出来，例如滚动 60 天窗口，只同步这个视图。物化视图的自动变更数据流会在读取时计算「行级变更」，窗口外的行淘汰产生的删除也能增量回灌进 Lakebase，于是 Lakebase 里始终只有一份新鲜的低延迟活跃子集，完整历史留在 Delta 里。这是把数据湖数据回灌应用库时性价比最高的一种形态。 第三个动作是把「同步模式」对上数据的真实新鲜度。Synced Tables 底层是托管的无服务器 Spark 声明式管道，同步跑多久就按多久收费，所以成本由搬动多少数据与实例的「计算单元」共同决定。三种模式的分工是：Snapshot 每轮复制全量，适合源表每周期的行变更超过 10% 的场景，原文说这种场景下它比 Triggered 便宜最多 10 倍；Triggered 按需或按间隔跑增量，插入、更新、删除都在每次刷新时传播，适合变更节奏已知的表；Continuous 是秒级实时的流式同步，延迟最低但成本最高，因为管道一直在跑，即使没有任何变更也在消耗计算。 预算有限又想要接近连续的新鲜度，做法是 Triggered 加一个表更新触发器，只在源数据真的变了才跑。原文还补了一条容易被忽略的优化：把多张表打包进同一条同步管道，让它们共用底层计算，这对 Continuous 尤其重要，否则每张表都要单独养一条常驻管道。反过来，不要为了省事把同步间隔拉得很长，积压的大批变更会让下一次同步又慢又贵。这三条选择标准可以直接抄进「前置部署」Forward Deployed Engineer（FDE）的交付文档，让客户自己回答每个表需要多新鲜。 第四个动作是定计算规格，原文认为这是最重要的一项。新建项目自带一条生产分支与一个主读写计算，默认在 8 到 16 CU 之间自动伸缩，闲置 24 小时后「缩容到零」；默认值对小型应用往往偏大，不动它就是在为用不到的能力付钱。判定规格的唯一关键输入是「热工作集」，即应用频繁访问的数据与索引，而不是磁盘上数据库的总大小：一个 2500 GB 的库如果热工作集只有 20 GB，它不需要 2500 GB 内存，只需要把那 20 GB 加上一点余量装进缓存。原因是内存按计算规格线性增长，最多 75% 的 RAM 可作为「计算缓存」，热工作集装得下时绝大多数读命中内存，延迟稳定；装不下时 Postgres 要去存储取未命中的页，慢得多，延迟抖动会被应用直接感受到。 缩容到零适合开发流程、非生产变体以及不需要两位数毫秒延迟的生产应用，从缩容到零唤醒只需要几百毫秒。把缩容到零关掉则进入常开态定价，按基线容量打 25% 折扣，高可用这类无法缩容到零的计算也适用该折扣。实际动作上，与其建好项目再回头改规格，不如在创建项目时就通过 Databricks SDK 把初始计算范围定下来；如果用具名声明式方式管理，也可以用 Declarative Automation Bundles 把计算范围写进配置。「前置部署」Forward Deployed Engineer（FDE）最该先量的是热工作集这一项，它比任何调参都更能决定账单量级。 第五个动作是核对连接上限，这一项最容易在压测时才暴露。max_connections 是并发 Postgres 连接的硬上限，也由计算规格决定；对自动伸缩的计算，规则是取最大值 CU 与 8 倍最小值 CU 中的较小者。这意味着把最大值抬上去，只在最小值还有余量时才会真的增加连接数，最小值太小就会封顶，应用连不上时会收到 too many clients 这类报错。原文的建议很直接：如果连接数真的是瓶颈，把它算进最小 CU，并且在 Lakebase 前面放一个「连接池」；它能让许多客户端连接共用一小池 Postgres 连接，最多支持 10000 个并发客户端连接，这通常比单纯把计算规格调大来抬上限更便宜。 第六个动作是把判断依据从感觉换成指标。Lakebase Metrics 面板会按 5 分钟、15 分钟、1 小时三个窗口报告热工作集大小，并把它和可用计算缓存并排显示，一眼就能看出热数据装不装得下；访问模式稳定的负载，用 1 小时窗口的工作集对照可用缓存最有用。再配合「缓存命中率」、CPU、RAM 与连接利用率一起看，就能验证初始规格该往上还是往下调。原文说自动伸缩收益最大化的前提是热工作集在最小 CU 下就装得进内存，否则每次扩容都要先付一次「冷缓存」代价。 规格偏小的表现很少是直接报错，而是四类容易被误判的症状：查询延迟变慢且不一致，中位数还好看但 p95 与 p99 上蹿；「缓存命中率」下降，这是工作集超出缓存容量的先行指标，会早于延迟明显退化；CPU 饱和与查询排队，吞吐到达平台期后延迟整体抬升；以及连接被拒，报的正是 too many clients。 第七个动作是收掉恢复策略上多买的存储。「时间点恢复」PITR 持续保留把库恢复到窗口内任意时刻所需的历史，窗口可在 2 到 30 天之间配置；快照则是根分支上的离散时间点捕获，可以手动打，也可以按天、周、月自动打。PITR 的存储量同时随写入活跃度与窗口长度增长，写密集的应用配一个很长的窗口会吃掉可观的存储。 原文给出的省钱组合是：把 PITR 窗口设成刚好满足事故恢复要求，需要更长的恢复点就交给计划快照。原因是两者单价都低于常规「分支存储」：快照存储是每 GB 每月 0.090 美元，比常规分支存储便宜约 74%；PITR 存储是每 GB 每月 0.200 美元，便宜约 42%。自动快照还有一处便宜：计划里的第一个快照按「全量快照」存，之后的快照只按「增量变更」计费。分工上，PITR 用来应对「恢复窗口」内任意时刻可能发生的误删或坏写入，快照用来做计划内的恢复点，例如高风险迁移或批量更新之前手动打一个。前置部署 Forward Deployed Engineer（FDE）在验收时要把恢复点目标与存储单价一起写清，否则客户会按最长窗口默认配置。 第八个动作是把「账单」拆成三类看，否则省了计算费却在同步管道上花回去。Lakebase 的成本只有三块：数据库计算、数据库存储，以及启用 Synced Tables 时把数据从数据湖搬进来的无服务器管道计算。计算按 CU 用量乘时间计费，开着自动伸缩就按「伸缩范围」内实际消耗的容量算。存储单独计量，并用 storage_type 字段拆成三项：BRANCH_DATA_STORAGE 是不过期分支的数据存储，BRANCH_CHANGE_STORAGE 是过期分支上保留的变更数据，BRANCH_HISTORY_STORAGE 是为 PITR 保留的历史。 查询入口是系统「计费系统表」system.billing.usage，把它和 system.billing.list_prices 关联就能按生效挂牌价估算每天的花费；项目 UID 在 Lakebase 界面 Project 的 Settings 里能看到，用接口取则先列出项目，再按状态里的显示名匹配拿 uid。同步管道的用量同样在 system.billing.usage 里，按底层管道 ID 过滤后再关联价格表，管道 ID 可以在界面上打开 Synced Table 复制，或者在接口返回里读状态字段里的管道标识。要注意这些查询用的是挂牌价，客户合同折扣不体现，所以它是成本上限而不是实付。「前置部署」Forward Deployed Engineer（FDE）在客户现场做预算评审时，直接跑这几条查询就能把口径统一，不必等财务出账。 官方文档在原文之外还给了几条硬约束，配置时容易撞上。自动伸缩的上下限差值不能超过 16 CU，也就是最大值减最小值不超过 16，例如可以配 8 到 24、48 到 64，但不能从 0.5 配到 32；界面上的滑杆会自动挡掉不合法的组合。缩容到零只在 32 CU 及以下可用，带自动伸缩的计算其最大值也必须不超过 32 CU，更大的计算永远保持活动。自动伸缩本身只支持到 64 CU，对应 128 GB 内存，需要更多算力只能改用 80、96、112 CU 的固定规格，而固定规格不支持自动伸缩。计算的唯一标识 UID 以 ep- 开头，会出现在连接主机名里。固定规格的计算在容量上不再是区间，界面上「计算规格」一栏会显示单个 CU 值，而带自动伸缩的显示为一个区间；「计算单元」与内存的比例固定，所以按缓存容量倒推规格时，只要盯住内存这一列就够。 这篇指南的局限要说清楚。原文只给出挂牌单价与折扣比例，没有任何客户的账单前后对比金额，因此不能把 74% 与 42% 当投资回报承诺，也不能外推到别的数据库产品。原文里 Databricks SDK 与 Declarative Automation Bundles 的示例代码块由页面脚本渲染，纯文本抓取拿不到里面的具体字段名，本文没有照抄，要落地请直接看官方文档页。16 CU 的差值约束、32 CU 的缩容到零上限、64 CU 的自动伸缩上限来自官方文档的计算规格页，不是原博文正文里的表述。超过 64 CU 的固定规格、跨区域高可用、以及物理隔离环境下托管数据库能否使用，原文与文档都没有覆盖。全部价格是公有云上的挂牌价，不含客户合同折扣，也不含同步管道之外的第三方数据搬运成本。前置部署 Forward Deployed Engineer（FDE）应把这份清单当成本上限来用，而不是当成已经谈定的价格。 回滚方式：计算规格与伸缩范围在 Lakebase 界面的编辑计算入口改回默认的 8 到 16 CU，重启计算后生效，已产生的用量按计费口径结算、不可退回。同步模式可以改回上一个模式；把物化视图的窗口放大回全表即可恢复原来的同步范围，但存储与同步成本会回升到改造前水平。缩容到零重新打开即恢复空闲暂停，同时失去常开态的 25% 折扣。PITR 窗口与快照计划都能改回原值，已生成的快照按保留策略清理，缩短「恢复窗口」不会立刻释放已经计量的历史存储。 交付前的自检清单，逐条勾选，每一条都对应上面某一段的结论。 - FDE（「前置部署」Forward Deployed Engineer）：先量热工作集再定计算规格：2500 GB 的库配 20 GB 的热工作集，不该按 2500 GB 配内存。 - FDE（「前置部署」Forward Deployed Engineer）：确认热工作集在最小 CU 下就已装进缓存，否则每次扩容都要付一次冷缓存代价。 - FDE（「前置部署」Forward Deployed Engineer）：打开缩容到零并确认计算规格不超过 32 CU，超过就永远无法进入空闲暂停。 - FDE（「前置部署」Forward Deployed Engineer）：把自动伸缩的上下限差值控制在 16 CU 以内，例如 8 到 24 或 48 到 64，不要 0.5 到 32。 - FDE（「前置部署」Forward Deployed Engineer）：核对 max_connections：它取最大值 CU 与 8 倍最小值 CU 中的较小者，只抬最大值不会一直加连接。 - FDE（「前置部署」Forward Deployed Engineer）：连接数超过上限时先加连接池，而不是靠把最小 CU 调大来抬连接上限。 - FDE（「前置部署」Forward Deployed Engineer）：只把应用真正要用的活跃子集同步进 Lakebase，用物化视图圈出滚动 60 天窗口。 - FDE（「前置部署」Forward Deployed Engineer）：按表的真实新鲜度选同步模式：变更行数超过 10% 时用 Snapshot，增量改动用 Triggered。 - FDE（「前置部署」Forward Deployed Engineer）：预算紧张又想要接近连续的新鲜度时，用 Triggered 加表更新触发器，而不是直接上 Continuous。 - FDE（「前置部署」Forward Deployed Engineer）：多张表的变更节奏接近时把它们打包进同一条同步管道，避免为每张表各养一条常驻管道。 - FDE（「前置部署」Forward Deployed Engineer）：不要拉长同步间隔，积压的大批变更会让下一次同步又慢又贵。 - FDE（「前置部署」Forward Deployed Engineer）：把 PITR 恢复窗口按真实事故恢复要求设定，只在窗口内保留 2 到 30 天的历史。 - FDE（「前置部署」Forward Deployed Engineer）：把长期恢复点交给计划快照：首个快照是全量，之后的只按增量计费。 - FDE（「前置部署」Forward Deployed Engineer）：高风险迁移或批量更新之前手动打一个快照，作为计划内的恢复点。 - FDE（「前置部署」Forward Deployed Engineer）：把缓存命中率、p95 与 p99 一起监控，均值好看而长尾抖动就是工作集溢出缓存的信号。 - FDE（「前置部署」Forward Deployed Engineer）：用 5 分钟、15 分钟、1 小时三个窗口的工作集大小对照可用计算缓存，按 1 小时窗口定最小 CU。 - FDE（「前置部署」Forward Deployed Engineer）：把计算、存储与同步管道三类成本分开记账，storage_type 要区分 BRANCH_DATA_STORAGE、BRANCH_CHANGE_STORAGE 与 BRANCH_HISTORY_STORAGE。 - FDE（「前置部署」Forward Deployed Engineer）：用 system.billing.usage 关联 system.billing.list_prices 估日成本，并记住它不含合同折扣。 原始来源： - https://www.databricks.com/blog/practical-guide-cost-optimization-lakebase-postgres - https://docs.databricks.com/aws/en/oltp/projects/manage-computes - https://docs.databricks.com/aws/en/oltp/projects/manage-with-bundles