摘要

现在的云应用和 AI 负载需要弹性计算、马上能隔离出来的环境，以及开放的数据互通。生产数据库大多仍是 1980 年代那种单体结构，存储和计算绑在一起，于是又脆、又贵、又被一家厂商锁住。Lakebase 把事务计算和存储拆开，并把库里的数据直接放进廉价的云对象存储，格式是开放的。Aurora、Socrates、AlloyDB 这一代云数据库也把存储内部分开了，但格式仍是专有的，数据只能从这一套引擎进去。Lakebase 把存储暴露成一层开放、持久的湖，上面再独立跑可以弹到零的 serverless PostgreSQL。论文写了这套设计：开放格式落在对象存储上、计算可以缩到零、用写时复制做即时分支和克隆、在同一份湖存储上同时做事务和分析。这些都已经落在 Databricks 的 Lakebase 服务里。文中接着分析它怎样降低运维复杂度、怎样做出类似 Git 的数据库工作流、怎样改善故障恢复、怎样减轻结构性的厂商锁定，并讨论了生产部署、性能取舍、持久性，以及多云高可用。评估用了标准的 OLTP 和分析基准，也用了分支和弹性的生产数据。Lakebase 被放在第三代数据库架构里：事务系统按云对象存储、弹性计算和 AI 时代的开发方式重新做。

总结

Lakebase 把计算和存储分开，全部数据以开放的 PostgreSQL 页格式放在云对象存储上。存储外置且格式开放之后，多套引擎都能读同一份数据，OLTP 也就直接放在 Lakehouse 旁边，事务和分析不用再各存一份。持久性靠对象存储，性能和可用性靠一层存储层次，写入正确性靠共识复制的 Safekeeper。自动伸缩、缩到零、自动故障转移和内建分支，比传统数据库少一层运维。这些性质对智能体负载尤其有用：要能马上克隆、亚秒启动、算完即走。生产上能看到很深的分支和很快的试验节奏。写作时，Lakebase 是 Databricks 采用最快的产品，每天创建和管理的数据库超过一千万个。它对应的是今天这种基础设施上的事务库：存储便宜且持久，计算可伸缩，数据必须开放。

Dange 等，Lakebase: Serverless Postgres over Open Lake Storage，PVLDB 19(12): 4385–4398，2026。

版权所有

版权归属：Pray0

许可证：署名 4.0 国际 (CC-BY-4.0)

上一页Lakebase