Databricks 正在改进 Lakebase Postgres 计算缓存，但自动扩缩容才是真正考验
Databricks 正在通过一项新配置提升 Lakebase Postgres 计算缓存的性能；根据其生产环境测量结果，吞吐量最高可达原来的两倍。这项变更已在至少拥有 80 个计算单元的固定规格 Databricks compute 上启用。然而，更棘手的问题仍未解决：如何将同样的内存策略应用到 Postgres 运行期间能够动态扩缩的 compute 上。
此次更新改变了数据库频繁请求页面的驻留位置。大型固定规格 compute 现在会将最多 75% 的可用内存分配给 Postgres shared buffers。这些缓冲区是数据库引擎中速度最快的内存缓存。Databricks 还使用 2 MB huge pages 支撑这部分内存，以减少操作系统内部的地址转换工作。
这一组合直指解耦式数据库的核心矛盾。将持久存储与计算分离，可实现快速重启、独立扩展以及低成本对象存储。但与此同时，运行中的查询与所需数据之间也拉开了更远距离。Amazon Aurora、AlloyDB 和其他云数据库都面临类似问题，但 Databricks 正将其解决方案应用于 Lakebase 底层的 Neon 架构。
改进 Lakebase Postgres 计算缓存从固定规格 Compute 开始
Databricks 已将 Lakebase 缓存中最热的数据从本地磁盘移入 Postgres 内存，但仅限于规格足够大的固定规格机器。
该变更于 2026 年 9 月 9 日公开。根据该公司的 compute cache update，它已在至少拥有 80 个计算单元的固定规格 Lakebase compute 上启用。Neon 的对应部署覆盖至少拥有 18 个计算单元的固定规格 compute。
Lakebase 使用解耦式存储，这意味着 Postgres compute 与持久数据存储作为独立层运行。计算节点负责运行数据库引擎，但并不持有数据的权威副本。这种设计使运维人员能够替换、重启或调整 compute 规格，而无需迁移整个数据库。
读取会经过一个层级体系。Postgres 首先检查 DRAM 中的 shared buffers。如果其中没有所需页面，先前的配置会检查存储在 compute 节点 NVMe 驱动器上的本地文件缓存。若仍未命中，请求便会发送至分布式存储层，由 pageserver 重建并返回数据库页面。
这一本地文件缓存解决了一个重要的早期问题。标准 Postgres 部署通常同时受益于 shared buffers 和操作系统的页面缓存。Lakebase 不会通过传统本地文件系统处理远程页面读取，因此无法依赖常规的第二层缓存。
因此，Databricks 和 Neon 将本地文件缓存构建为一种弹性替代方案。它可占用超出静态 Postgres 缓冲区分配的容量，并随 serverless compute 一同调整。这种安排支持自动扩缩容，无需在 Postgres 运行期间调整 shared buffers 的大小。
不过，先前配置将 shared buffers 限制在约 1 GB。其余大部分计算缓存容量——最高可达 DRAM 的 75%——被分配给本地文件缓存。在大型机器上，这种平衡使许多原本可缓存的读取经由 NVMe，而非内存完成。
新的固定规格 compute 配置将本地文件缓存从这一路径中移除。它将 75% 的 DRAM 分配给 shared buffers，使更大的工作集保留在 Postgres 内部。根据公告，当管理员运行 show shared_buffers 时，一个 80 单元的 Databricks endpoint 应显示 120 GB。
访问 DRAM 避免了本地缓存所需的磁盘输入输出。它也让 Postgres 能直接了解已缓存的页面及其使用情况。在决定淘汰哪个页面时，操作系统缓存或独立磁盘层掌握的数据库状态信息更少。
这正是改进 Lakebase Postgres 计算缓存的直接含义。这并非引入新的索引、查询规划器或存储格式。Databricks 调整的是既有 Postgres 执行引擎周边的内存分配与虚拟内存机制。
适用范围至关重要。固定规格部署可在启动时分配 shared buffers，因为其内存上限保持已知。自动扩缩容 endpoint 则无法作出同样假设。其可用内存会随着工作负载需求变化，而标准 Postgres 设置在启动后仍保持静态。
这也是为什么首个版本意义重大，但尚不完整。Databricks 已证明，更直接地使用内存能够改善大型 Lakebase endpoint 的表现。但它尚未在令解耦式 Postgres 颇具吸引力的 serverless 运行模式中交付同样的设计。
为何 Lakebase 缓存性能成为优先事项
存储分离带来了运营灵活性，但每一次缓存未命中都会暴露这种灵活性背后的延迟与 CPU 成本。
传统 Postgres 通常将查询引擎、预写日志和数据库文件部署在同一台机器或紧密连接的存储上。操作系统可以在页面缓存中保留最近访问过的文件页面。Postgres 也会在 shared buffers 中保留选定页面。
这种安排可能导致内存中的数据重复。Databricks 举例称，一台拥有 4 GB RAM、其中 1 GB 分配给 shared buffers 的机器，通过文件系统读取 1 GB 数据时，操作系统缓存中可能还会留下另一份副本，意味着缓存 1 GB 数据库页面会消耗 2 GB 内存。
Lakebase 改变了这一路径。其 storage architecture 将系统划分为无状态 Postgres compute 与持久存储服务。Safekeeper 会复制预写日志记录，而 pageserver 则重建页面版本并将其持久化至对象存储。
这种架构使 compute 能够独立于存储数据进行扩展。它支持 scale-to-zero、快速分支、只读副本和故障转移等功能，而无需复制整个数据库。这些优势依赖于将持久状态保留在 compute 节点之外。
然而，无状态 compute 在处理查询时仍需要将状态保留在近处。应用会反复访问索引、表页面、目录记录及其他结构。如果这些页面驻留在 DRAM 中，读取便可在层级体系中延迟最低的部分完成。
shared buffers 未命中会走更长的路径。本地 NVMe 缓存虽比远程存储更快，但仍需要磁盘访问与额外的软件处理。若该层也未命中，请求将到达 pageserver，可能增加网络流量和页面重建工作。
由此产生的压力主要落在使用大型 Lakebase 实例运行延迟敏感型应用的团队身上。这些客户配置了大量内存，但此前 1 GB 的 shared-buffer 上限阻止 Postgres 通过最快的缓存路径使用其中大部分内存。
随着工作集增大，这种错配会愈发明显。工作集是应用在给定时间段内频繁访问的一组页面。当其超过较小的内存缓存容量时，即使机器拥有充足 DRAM，请求也会溢出到更慢的层级。
Databricks 需要更好的答案，因为 Lakebase 现在服务于运营型工作负载，而不只是分析任务。面向用户的应用关注尾延迟，它反映的是延迟分布较高端的较慢请求。平均值可能仍可接受，但 p99 请求依然可能造成用户可感知的停顿。
AI 应用也会对运营型数据库施加不均衡压力。一个 agent 可能触发检索、写入、检查点和并发工具调用的突发流量。当流量以集群形式到来，而不是以稳定请求流到来时，可预测的缓存行为就变得更加重要。
这并不意味着所有工作负载都会获得同等收益。已完全适配早期 shared-buffer 分配的数据集，改善空间较小。页面复用较少的扫描密集型工作负载，无论缓冲区有多大，仍可能持续访问更低层级的缓存。
最适合受益的是那些拥有可复用工作集、且工作集超过原先 1 GB 限制的大型 endpoint。其现有内存如今可在 Postgres 内部直接容纳更多热点页面。这也是 Databricks 展示生产案例，而非承诺普遍实现性能翻倍的原因。
因此，Lakebase 缓存性能既取决于工作负载形态，也取决于机器规格。新配置消除了一个架构瓶颈，但并未改变缓存局部性、查询设计、索引或内存争用所遵循的基本规律。
Huge Pages 让更大的缓冲池具备可行性
除非 Lakebase 同时降低数据库进程映射这些内存的成本，否则为 Postgres 分配更多内存本身也会带来额外开销。
Postgres 使用基于进程的架构。每个活动连接通常都会获得一个 backend 进程，而每个 backend 都会将 shared-buffer 区域映射到自己的虚拟地址空间中。操作系统维护页表项，将这些虚拟地址转换为物理内存位置。
标准 Linux 内存页面通常为 4 KB。在该页面大小下，1 GB 的 shared buffers 需要为映射该区域的每个进程维护 262,144 个页表项。Databricks 计算得出，512 个 backend 映射 32 GB shared buffers 时，大约需要 43 亿个条目。
该公司估计，仅为映射一个 32 GB 缓存，这些条目就会消耗约 32 GB 页表内存。这是一个极端示例，说明更大的缓冲区分配如何将开销转移到其他位置。当内存管理消耗过多 RAM 和 CPU 时间时，增加缓存容量并不一定有用。
处理器还维护着一个转换后备缓冲区，即 TLB。这个硬件缓存存储近期的虚拟地址到物理地址转换。即使数据页面已位于 Postgres 内存中，CPU 在 TLB 未命中后定位该页面时仍会付出代价。
Huge pages 通过以更大单位映射内存来降低这一压力。Lakebase 在新的固定规格 compute 配置中使用显式的 2 MB HugeTLB 页面。每个 huge page 覆盖的内存是标准 4 KB 页面的大 512 倍，因此所需映射条目数量也相应减少相同倍数。
PostgreSQL 已提供操作系统层面的 huge-page 控制。其 resource documentation 说明，显式 huge pages 可以降低与大型连续共享内存区域相关的开销。当 shared_buffers 变得非常大时，这一优势尤为重要。
虚拟化使实施变得更困难。Lakebase 在裸金属主机上的轻量级 guest 虚拟机中运行 Postgres。因此，地址转换需跨越 guest 与 host 两层。为了保持预期收益，huge pages 必须在 host、hypervisor 与 guest 之间保持一致的支撑。
Databricks 表示，它已在整个技术栈中增加专用 huge-page 支持。大型固定规格虚拟机会以预定数量的 huge pages 启动。在 Postgres 初始化后，compute 系统会释放数据库并不需要的容量。
该公司选择显式 HugeTLB 页面，而非 transparent huge pages。Transparent huge pages 允许操作系统自动提升内存页面，但这种行为属于尽力而为。显式预留让数据库环境能够更严格地控制页面可用性与布局。
在 Databricks 基准测试中，大页将读取延迟的尾部值最多降低了约 40%。CPU 利用率最多下降了约 30%。这些是公司测量结果，并非适用于每一种 Lakebase 工作负载的独立保证。
这一区别很重要，因为大页并不能解释全部已报告的改进。两项变化同时发生：更多数据保留在共享缓冲区中，而访问这片更大区域所需的页表转换次数更少。不同工作负载可从每种机制中获得不同比例的收益。
管理员可通过 Postgres 检查已部署的设置。对于符合条件的 80 单元 Lakebase 端点，运行 show huge_pages 应返回 on。结合 shared_buffers 的值，这提供了一种直接确认新配置是否已应用到某个计算实例的方法。
这一机制也解释了为什么仅仅提高 shared_buffers 并不能完整解决普通 Postgres 部署的问题。为数据库预留的内存必须与连接、查询操作、维护作业以及操作系统需求共存。如果周边系统并非为此设计，大规模内存分配可能带来新的限制。
Databricks 控制虚拟机、计算镜像、缓存路径和存储协议。这种端到端控制使其能够将大页预留与 Postgres 启动过程协调起来。自行管理的团队则需要独立调优这些层面，并在自身工作负载下验证结果。
因此，Lakebase 缓存的工作方式比“使用更多 RAM”更复杂。改进取决于将热数据放入正确的内存区域、高效映射该区域，以及为缓冲池之外的一切保留足够内存。
生产结果显示收益，而非通用基线
Databricks 报告了三个生产端点的显著改进，但公开示例并不能确立全平台的平均性能。
第一个示例于 8 月 11 日约 06:10 UTC 获得新配置。每秒访问的 Postgres 块数量翻倍，Databricks 将其用作吞吐量代理指标。存储 GetPage 请求从每秒约 8,000 次降至约 1,500 次。
该客户还报告称，与前一天、前一周和前一个月相比，其中位延迟和 p99 延迟均有所降低。此次发布未提供底层延迟数值、工作负载定义、查询组合或受控对比环境。读者应将这一观察视为生产结果，而不是标准化基准测试。
第二个端点于 8 月 14 日约 01:30 UTC 完成变更。其报告的吞吐量提高了约 43%，同时计算缓存命中率接近 100%。发布后，请求几乎完全由共享缓冲区提供服务。
第三个端点于 8 月 15 日完成变更。Databricks 表示，CPU 消耗从 20 个核心降至 4 个，缓存命中率接近 100%，测得吞吐量翻倍。CPU 使用量五倍下降格外引人注目，但公开文章并未说明所有外部工作负载条件是否保持不变。
综合来看，这些示例支持一种可信的机制。更多请求命中 DRAM，更少读取到达分布式存储服务，处理器花在地址转换上的时间也更少。这些结果与设计变更一致。
但这并不意味着每个符合条件的计算实例都会快一倍。Databricks 使用了“最高可达”的表述，而且三项结果各不相同。一项记录到 43% 的吞吐量提升，另外两项则达到此前测量值的大约两倍。
工作负载构成仍是最大变量。对大型但有界工作集进行重复访问的、对缓存敏感的查询，预计能获得更大收益。写入密集型工作、低复用扫描、锁竞争、低效查询或受网络限制的应用逻辑，都可能限制可见的改进。
旧的本地文件缓存也发挥了有用作用。它提供了比原始共享缓冲区分配更大的容量，并避免了许多存储层请求。将热页面从 NVMe 移入 DRAM 能改善最快路径，但移除这一二级层会在工作集超出可用内存时改变系统行为。
Databricks 表示，在这些固定计算实例上，缓存未命中现在会从共享缓冲区直接进入分布式存储。这为异常庞大或不断变化的工作负载提出了一个重要问题。更高的内存命中率可以与落在扩容后缓冲池之外页面的更高代价同时存在。
公开的端点似乎得益于其活跃数据能够很好地容纳在更大的分配中。两个示例中接近 100% 的命中率表明数据局部性很强。局部性较弱的应用可能会在更快命中和远程未命中之间呈现不同的平衡。
重启行为同样值得关注。共享缓冲区是临时性的，因此新启动的计算实例通常不会在内存中保留其热工作集。Databricks 另行记录了自动缓存预热，它会在计划更新期间重新填充常用数据。
预热可以降低更新后的冷缓存代价，但应用仍可能在重启期间经历短暂的连接中断。驱动程序、连接池和重试逻辑必须处理这一事件。缓存改进并不能消除对连接韧性的需求。
独立基准测试结果将进一步增强这一论据。有效测试应披露数据集规模、连接数、查询分布、缓冲状态、计算规模和延迟分位数。它们还应在稳定和变化的工作集下，对旧版与新版缓存路径进行比较。
目前，证据支持一个更有限的结论。改进 Lakebase Postgres 计算缓存似乎对 Databricks 测量的大型生产端点有效。另一应用可获得的收益幅度仍是一个经验问题，运营人员应通过自身的延迟、命中率、CPU 和存储读取指标来回答。
主要冲突在于固定内存与自动扩缩容
当前版本改进了 Lakebase 较为简单的一半，而产品的无服务器承诺取决于能否在不重启 Postgres 的情况下调整缓存内存。
shared_buffers 设置通常在 Postgres 启动前确定。更改它需要重启，因为数据库会在初始化期间建立共享内存区域。这种行为与处理流量时改变内存容量的自动扩缩容计算实例直接冲突。
固定计算实例避免了这种冲突。Databricks 知道虚拟机拥有多少内存，将 75% 分配给共享缓冲区，预留相应的大页，然后启动 Postgres。该分配可在机器的整个生命周期内保持不变。
自动扩缩容端点必须扩展和收缩。当需求上升时，Postgres 应获得更多缓冲容量，而客户机应接收高效映射所需的精确数量的大页。当需求下降时，两类资源都应被归还，且不能破坏活动状态或强制进行干扰性的重启。
这是一项截然不同的工程任务。共享内存可能包含正被活动后端读取、修改、固定或检查的页面。缩小该区域需要与缓存逐出和并发数据库活动进行安全协调。
Databricks 表示，它已开发出一种可随动态共享缓冲区一起扩缩大页的协议。该公司计划在第二篇技术文章中解释这一实现方案，也打算与开源 PostgreSQL 社区合作开发底层机制。
在这项工作上线前，Lakebase 有两种缓存策略。大型固定计算实例采用扩容后的共享缓冲区设计。自动扩缩容计算实例则继续依赖现有组合：保守设置的共享缓冲区和本地文件缓存。
这种分化给产品定位带来了压力。固定容量目前提供最明确的性能提升，而自动扩缩容则提供无服务器数据库所具备的灵活性。客户暂时不能假设自己能从同一种计算模式中同时获得这两种特性。
这并不意味着自动扩缩容在每种部署中都更差。需求波动或间歇性的应用，可能比最低可能的缓存延迟更看重缩容至零和弹性容量。稳定、内存密集型的生产服务可能更偏好可预测的固定资源。
这一决策还取决于工作负载增长。固定计算实例要求运营人员预先选择足够容量。自动扩缩容能够吸收流量变化，但当工作集超出较小的共享缓冲区分配时，当前缓存路径可能会让更多命中经由本地 NVMe。
这才是 Lakebase 缓存性能真正的竞争考验。其他托管 Postgres 服务同样结合了分布式持久化、本地缓存、副本和弹性资源管理。架构细节各不相同，因此头条基准数字很少能支持明确的产品排名。
Databricks 必须证明，其存储分离不会对目标工作负载施加可避免的性能代价。交付动态共享缓冲区将使 Lakebase 能够保留其无状态计算模型，同时让更多弹性内存直接受 Postgres 控制。
与上游社区的合作可能将影响扩展到 Lakebase 之外。动态缓冲区大小对于分配内存随时间变化的容器化和弹性 Postgres 环境同样具有意义。不过，Databricks 尚未发布公告中提及的代码、审查状态或发布路径。
这种不确定性应保持明确。该公司已说明方向，并表示自动扩缩容协议已经存在。但它尚未提供发布日期、支持的计算范围，或自动扩缩容共享缓冲区的生产测量结果。
因此，固定计算实例的推出既是一项改进，也是一次预览。它在稳定内存条件下验证了缓存放置和大页机制。下一阶段必须证明，这些机制能够跟随变化的机器资源，而不牺牲可用性或可预测的性能。
Lakebase 用户现在应测量什么
相关问题不在于公开基准看起来是否令人印象深刻，而在于符合条件的工作负载能否变得更快，同时不会产生新的未命中代价。
符合条件的用户可先确认配置。show shared_buffers 会显示当前 Postgres 缓冲区分配，而 show huge_pages 则报告显式大页是否处于活动状态。根据公司的示例，80 单元 Databricks 端点应显示 120 GB 和 on。
仅凭配置并不能证明价值。团队应在等效流量窗口内比较缓存命中率、存储 GetPage 活动、CPU 消耗、吞吐量，以及 p50 和 p99 查询延迟。比较应考虑部署、数据增长、维护和应用变更。
缓存命中率需要结合上下文理解。接近 100% 的命中率可能表明活跃工作集适合存入内存。如果不结合吞吐量和延迟考察，它也可能掩盖请求成本、查询频率或工作负载组合方面的差异。
存储读取提供了另一个直接信号。读取量下降表明更多页面留在 Postgres 内部，而不是到达 pageserver。根据第一个示例中每秒约 8,000 次降至 1,500 次的变化，Databricks 报告 GetPage 请求减少了约 5.3 倍。
CPU 测量可揭示大页和避免处理磁盘缓存带来的益处。然而，较低的 CPU 使用率只有在吞吐量保持稳定或提升时才最具参考价值。安静时段可能同时降低 CPU 使用和完成的工作量，却并不代表效率提升。
团队还应检查重启和预热行为。计划内更新会触发计算资源重启，不过 Databricks 表示通常只需几秒钟。在这些窗口期测试连接重试和尾延迟，能够发现稳态图表容易忽略的运营影响。
一个具体场景是：某个事务型应用的活跃索引和高频访问行占据数十 GB。按此前的配置，只有一小部分能留在共享缓冲区中。尽管 DRAM 仍有未利用的空间，许多命中仍会落入本地 NVMe 缓存。
更新后，这个工作集或许几乎可以完全装入扩大的缓冲池。团队应预期存储请求减少、读取延迟降低，以及 CPU 开销下降。如果这些信号没有变化，很可能是其他瓶颈占据主导。
AI Agent 服务提供了第二种场景。它可能在 Postgres 中保存对话状态、工具结果、任务状态或向量元数据。当频繁复用的数据页能留在内存中时，突发的并发读取可从中受益；但连接数量和查询模式仍决定着后端进程的压力。
审查这类变更的工程师需要共享证据，而不是零散截图。可搜索的工程知识库可以保存基准测试条件、查询计划、配置快照和发布观察结果，供日后比较。
评估也应纳入失败情形。如果工作集超过扩大的共享缓冲区，固定计算资源将不再拥有此前位于中间层的本地文件缓存。测量冷启动、大规模扫描和工作集突然变化时的延迟，将显示远程未命中是否变得更加明显。
这些检查都不要求接受或否定公司的核心说法。它们只是将所提出的机制转化为可观察信号。如果在等量需求下，更多读取命中共享缓冲区，同时 CPU 占用和尾延迟下降，那么该更新就正在为该工作负载发挥作用。
如果吞吐量保持不变，团队应先检查锁等待、应用网络、查询计划、索引和写入压力，再将结果归因于 Lakebase。缓存变更无法解决数据库延迟的所有来源。
三项信号将决定此次缓存重构是否重要
自动扩缩容的交付、独立工作负载证据以及上游 PostgreSQL 的进展，将决定这是否会成为 Lakebase 的广泛优势。
第一个信号，是面向自动扩缩容计算资源发布动态共享缓冲区的生产版本。Databricks 需要证明，共享缓冲区容量能够随内存同步扩缩，同时大页支持的容量仍能得到正确配置。若发布时披露适用条件、上线行为和运营限制，将强化该公司的架构论证。
生产环境测量结果应与该版本一同发布。有价值的比较不是将自动扩缩容与无关的固定基准进行对比，而是比较启用动态缓冲区前后相同的弹性工作负载，其中包括扩容事件、缩容事件、缓存命中率、CPU 使用率和 p99 延迟。
如果自动扩缩容能够在不造成干扰性重启的情况下达到类似的缓存效率，当前分析就会更具说服力。这将表明，解耦式 Postgres 可以将弹性计算与大型、由引擎管理的内存缓存结合起来。若长期延迟发布，最快的路径仍将局限于固定容量。
第二个信号，是更广泛的基准测试证据。Databricks 已发布三个表现良好的生产案例，但用户还需要看到覆盖不同工作集大小和查询模式的结果。独立测试应包括读取密集型事务、读写混合、高连接数、冷启动，以及大于可用 DRAM 的工作负载。
持续一致的提升证据将支持所宣称的机制。结果若高度可变，并不会否定此次发布，但会缩小可能受益的应用范围。在移除本地磁盘层后，缓存未命中时出现性能回退将需要更密切的关注。
第三个信号，是开源 PostgreSQL 中可见的进展。Databricks 表示计划与上游社区合作开发动态共享缓冲区。具体提案、补丁、技术讨论和审阅反馈，将揭示这套方案有多少应当归入 Postgres 本身。
获得上游接纳将使这一设计得到更广泛的技术审视，并使其价值超越单一供应商。它还可能缩小弹性云环境与围绕固定机器设计的 Postgres 配置之间的长期差距。
未能将这项工作合入上游，并不会阻止 Databricks 推出平台专属实现。但这会使外部人士更难评估其兼容性、维护成本和可移植性。
改进 Lakebase Postgres 计算缓存，已在部分选定的固定计算资源上产生可测量的结果。更关键的考验在于，Databricks 能否在不削弱存储分离所带来弹性的前提下，让缓存实现动态化。
对于运行符合条件端点的团队，下一步很直接：确认设置、记录稳定基线，并在上线后比较真实工作负载指标。对于自动扩缩容用户，在假定同样收益适用之前，应关注第二次工程发布。对你的应用而言，当前更重要的是固定内存性能，还是随需求扩展容量的自由？
