Databricks Lakebase 的 Postgres 写入加速架构

传统 Postgres 在高写入负载下的性能瓶颈由来已久，而 Databricks Lakebase 通过架构层面的重新设计，从根本上解决了这个问题。在 Lakebase 中，计算层与存储层天然分离，这一特性不仅带来了弹性扩缩容的能力，更重要的是，它打开了一扇优化写入路径的大门 —— 将原本驻留在计算节点的全页写入（Full Page Write，FPW）压力下推到分布式存储层执行，从而实现写入吞吐 5 倍提升、WAL 流量削减 94%、读取尾延迟降低 50% 的工程目标。

FPW 瓶颈：传统 Postgres 写入路径的结构性代价

要理解 Lakebase 的优化思路，首先需要看清传统 Postgres 是如何处理数据持久化的。每次数据库变更都会先写入顺序日志（WAL），这是崩溃恢复的保障。Postgres 定期执行检查点（Checkpoint），将内存中已修改的 8KB 数据页刷新到磁盘，并在 WAL 中记录一个里程碑标记。一旦崩溃，Postgres 从该里程碑开始重放 WAL 即可恢复数据。

然而这里存在一个风险：如果服务器在写入 8KB 页面的过程中崩溃，页面可能只被部分写入，产生 "撕裂页"（Torn Page）。撕裂页会导致后续 WAL 重放时数据永久损坏。为了防止这种情况，Postgres 引入了全页写入机制：在一个检查点里程碑之后，某个页面第一次被修改时，Postgres 不只记录微小的变更，而是将完整的 8KB 页面内容整个写入 WAL。这样，即使磁盘上的页面被撕裂，Postgres 也可以从 WAL 中取出完整的页面镜像作为起点进行重放，确保恢复过程的安全性。

问题在于，这种保护机制代价极高。在写入密集型应用中，完整的 8KB 页面写入会使日志量膨胀最高达 15 倍，成为系统最大的性能瓶颈。计算节点不仅要生成大量 WAL 数据并通过网络传输，还要消耗 CPU 周期进行页面复制，而 WAL 的膨胀进一步加剧了存储层的写入压力。

计算与存储分离：从架构约束到性能红利

Lakebase 的设计从一开始就将计算层设计为无状态。与传统 Postgres 实例拥有本地数据目录不同，Lakebase 的计算节点将 WAL 流式传输到一组基于 Paxos 共识的守护节点（Safekeepers）。由于本地磁盘不存在需要保护的页面，FPW 所要防范的撕裂页风险在 Lakebase 的架构中根本不存在。

但如果简单地在 Lakebase 中关闭 FPW，会引发新的问题：读取性能会急剧下降。传统 Postgres 中嵌入 WAL 的全页镜像充当了定期的 "重置点"，使得 delta 链的长度被自然地约束在 O (检查点频率) 的范围内。没有了这些重置点，一个频繁更新的页面可能累积起无限长的微小变更链，导致页面读取时需要重放整个链才能重建当前状态，读取延迟和资源消耗都会飙升。

页面镜像下推：将智能从计算层迁移到存储层

Lakebase 的解决方案是将全页镜像生成的责任从计算层的 WAL 流下沉到存储层执行，这被称为 "页面镜像下推"（Image Generation Pushdown）。

在 Lakebase 的架构中，存储层由多个 Pageserver 组成。当 Postgres 计算节点请求某个页面时，Pageserver 负责重建该页面 —— 它找到该页面最近的物化镜像，然后在其上重放 WAL 中的 delta 变更。传统架构中，计算节点通过 WAL 嵌入的全页镜像自然地为 delta 链提供了边界，将链长控制在合理范围内。

启用页面镜像下推后，这些边界消失了。但 Pageserver 现在掌握了一种新能力：当某个页面累积的 delta 记录数超过配置阈值而没有介入的镜像时，Pageserver 主动生成一个新的全页镜像。这是一种更优的策略，因为生成镜像的时机取决于页面的实际变更频率，而非无关的 Postgres 检查点进程。

这一设计带来了三个关键优势。首先是网络效率：计算节点现在只传输紧凑的 delta 变更，而非 8KB 的完整页面，基准测试显示流量减少了 94%。其次是水平扩展能力：镜像生成的工作从单一的 Postgres 写入节点转移到可独立扩缩的分布式存储层，一个项目分支的镜像生成现在可以跨多个 Pageserver 在后台共享执行。第三是读取性能优化：镜像生成时机基于页面的真实变更情况，而非检查点周期，这意味着高频更新的页面能获得更及时的重置点，delta 链始终保持合理长度。

性能量化：从基准测试到生产验证

Lakebase 使用 HammerDB TPROC-C（衍生自 TPC-C 的 OLTP 基准）对这一优化进行了基准测试，并在大规模生产环境中进行了验证。

在基准测试中，启用页面镜像下推后，不同规格计算实例的吞吐量提升呈现出明显的规模效应。4 vCPU 实例从 78,876 NOPM 提升到 94,891 NOPM，提升幅度为 20%；16 vCPU 实例从 95,832 NOPM 跃升至 269,189 NOPM，提升 2.8 倍；32 vCPU 实例从 95,686 NOPM 大幅增长到 439,300 NOPM，提升超过 4.5 倍。这一结果清晰地表明，消除 FPW 瓶颈后，Postgres 的吞吐量能够随计算资源线性扩展，这在单体 Postgres 实例的高写入负载下是难以实现的。

WAL 流量削减与吞吐量提升直接相关。在计算节点上，每笔事务平均生成 58KB 的 WAL；启用页面镜像下推后，这一数字降至不足 4KB，降幅达 94%。更少的 WAL 意味着写入路径上的竞争减少、网络带宽消耗降低、存储层接收的数据量减少，整体系统的写入效率得到系统性提升。

生产环境的验证结果同样令人信服。在一个使用 56 vCPU 的大型项目中，启用页面镜像下推后，稳态 WAL 生成率从 30 MB/s 降至仅 1 MB/s，数据削减幅度与基准测试一致。写入吞吐量的提升也直接体现在每日业务高峰期的负载表现上。

不仅写入受益，读取性能同样得到了优化。通过优化 delta 链的结构，Pageserver 为每个读请求需要重放的 WAL 记录数显著下降。p99 读取延迟降低了 30% 到 50%，p50 读取延迟也有约 30% 的下降。在区域层面，启用后的计算节点总 WAL 生成量下降了最多 4 倍，存储引擎的 p99 页面读取延迟改善了最多 3 倍，且更加稳定。

对于使用 Synced Tables 的客户，影响同样立竿见影。一家客户的摄取吞吐量从每秒 17,000 行提升到 62,000 行，提升幅度达 3 倍，仅通过启用页面镜像下推实现，无需对应用层做任何修改。

零中断部署：控制平面驱动的平滑切换

这一优化自 2026 年 3 月底开始向整个集群推广，目前已在全球所有区域的 Lakebase Serverless 和 Neon 数据库上激活。

部署过程通过控制平面和存储系统的协调自动完成，无需客户重启计算节点或进行任何配置变更。实现这一能力的技术基础是 Postgres 现有的 XLOG_FPW_CHANGE WAL 记录机制，该机制允许在运行时动态切换 FPW 行为，而不会中断正在执行的事务。这种零中断的部署方式意味着客户无需专门的维护窗口即可获得性能收益，同时也验证了 Lakebase 架构在运行时动态调整存储行为的能力。

架构启示：分离设计打开的系统性优化空间

Lakebase 写入加速的成功揭示了计算与存储分离架构的深层价值。在传统单体数据库设计中，计算节点承担了包括持久化保障在内的多重职责，这些职责在设计时与计算资源紧密耦合，难以在运行时灵活调配。而当存储层成为一个独立的、具备计算能力的分布式系统时，许多原本必须在写入路径上执行的开销可以被卸载到后台异步执行，从而将关键的写入路径精简为最小必要操作。

页面镜像下推只是这一架构哲学的一个具体实践。正如 Lakebase 团队引入缓存预热机制实现零停机补丁一样，他们正在系统性地将重量级任务从事务路径迁移到可弹性扩缩的后台存储栈。Postgres 的写入税负 —— 至少在 Lakebase 的架构中 —— 已经成为历史。

资料来源：本文核心事实来源于 Databricks 官方工程博客《How lakebase architecture delivers 5x faster Postgres writes》（2026 年 5 月 7 日发布）。

systems