五年前，Databricks 用“Lakehouse”重新定义了分析型数据架构的存放方式。五年后，它试图用同一个逻辑回答另一个问题：如果存储可以独立于计算存在，为什么事务型数据库还要被困在一台机器的磁盘上？

Lakebase 给出的答案不是又一款“托管 Postgres”，而是一次对数据库架构层的重新切分：把 OLTP 引擎变成无状态的、可抛弃的计算，把数据以开放格式直接放进湖仓，让事务与分析第一次共享同一份存储，而不是靠管道去“同步”。如果说 Lakehouse 解决的是 OLAP 的弹性问题，那么 Lakebase 瞄准的是 OLTP 的结构性僵化。

传统数据库的“单机宿命”

要理解 Lakebase 改了什么，先看它拆了什么。一台传统 PostgreSQL 实例是一个紧凑的单机系统：查询引擎、Write-Ahead Log（WAL）和数据文件挤在同一台机器的本地磁盘上。WAL 负责让写入变快——顺序追加后即确认提交；数据文件负责让读取变快——页面物化后查询不必重放日志。

这套设计稳定运行了几十年，代价藏在三个地方。持久性绑在那台机器的物理基础设施上，存储必须提前预配，容量规划本身就是一个猜谜游戏。高可用和水平扩展通常意味着对整个数据库做物理克隆，克隆越大，操作越慢、越贵。单机故障就是数据风险，RAID 能降低概率，但换不来架构层面的解耦。

第二代云数据库看到了这个问题。Aurora、Socrates、AlloyDB 都把存储从计算中剥离了出来，但存储仍然使用专有格式，只服务于自家的引擎。分析引擎想读这些数据，依然要走抽取—加载的老路。计算解耦了，数据没有解耦。

Lakebase 的切法：把 WAL 和页面都交给独立服务

Lakebase 的架构可以用一句话概括：计算层跑标准的、无状态的 Postgres；存储层由 Safekeeper、Pageserver 和云对象存储共同承担。

计算层不持久化任何数据。它只持有内存中的 Postgres 缓冲区和一块本地临时缓存。正因为没有持久状态，计算实例可以被替换、重启、自动扩缩，甚至缩到零，而不需要搬动或丢失数据。多个计算实例可以挂在同一个存储层上，读副本和快速故障转移本质上就是“多开一个无状态引擎，连同一份存储”。

存储层做了更细的分工。Safekeeper 接管了 WAL 的职责：Postgres 生成的 WAL 记录被转发到一组 Safekeeper，通过基于 Paxos 的共识协议在 Quorum 中复制，只有多数派确认后事务才提交。这相当于把“写入耐久性”从一个本地磁盘的承诺，变成了一个跨可用区的分布式共识承诺。Pageserver 和对象存储接管了数据文件的职责，页面版本被物化并持久化到廉价的对象存储中，不再需要预配块设备，也不存在“磁盘写满”这种故障模式。

这套切分带来的直接后果是：事务型数据库第一次可以像无状态服务一样被调度。缩容到零不是休眠再唤醒的权宜之计，而是架构上允许的常态；分支和克隆不是拷贝数据，而是在 copy-on-write 语义下共享未变更的页面，秒级创建一个与生产隔离的完整数据库副本。

不是“又一个托管 Postgres”：开放格式才是分水岭

Lakebase 与 Aurora 类产品的关键区别不在“存储计算分离”这个口号上，而在存储层的格式和归属。Lakebase 把数据库数据直接放进云对象存储，使用开放格式。写入湖仓的数据，Spark、Databricks SQL 或其他分析引擎可以直接查询，不需要经过 ETL 把数据从专有存储里“搬出来”。

这解决了操作型湖仓项目中反复出现的接缝问题。以前，一个需要毫秒级响应的应用要在湖仓旁边再架一套 Postgres，管道从 Delta 抽数据过去，反向 ETL 再把应用状态写回来。延迟对不上，治理变成两套模型，反向 ETL 的漂移没有人能持续盯住。Lakebase 的做法是把两种模式放进同一个 Postgres 数据库里：同步表把 Gold 层的 Delta 物化视图以秒级新鲜度映射进来，提供单数字毫秒的只读查询；应用状态表则是完整的读写 Postgres 表，承接那些 Delta 天生不擅长的逐行 ACID 操作——队列、账本、审计日志、代理收件箱。

两者共享同一个访问模型，底层则由 Unity Catalog 统一治理。Lakebase 表会注册为 Unity Catalog 中的镜像目录，权限、血缘、审计元数据与底层 Delta 表在同一处可见。治理不再是“湖仓一套、数据库一套”的两线作战，而是收敛到同一个控制面。

LTAP：比“湖仓一体”更进一步的架构信号

Databricks 围绕 Lakebase 提出的 LTAP（Lake Transactional/Analytical Processing）概念，值得单独拆开看。湖仓一体解决的是分析负载的统一存放；LTAP 试图统一的是事务与分析在存储层的共存：同一份湖存储，同时服务 OLTP 和 OLAP，取消团队长期维护的 CDC 同步链路，让事务系统和分析系统不再需要“保持同步”。

这个方向的工程基础来自两次收购。Lakebase 的无状态 Postgres 引擎和存储分离架构源自 Neon；Mooncake 则带来了在 Postgres 变更与湖仓格式之间做实时转换的能力，使 Postgres 的写入可以镜像到湖仓侧。LTAP 的实质不是把 OLAP 塞进 Postgres，也不是把 Postgres 改造成数仓，而是让两者在存储层共享同一份数据，计算层各取所需。

性能数据提供了初步佐证。在 VLDB 论文报告的测试中，Lakebase 在 24 vCPU 档位下持续吞吐比第二代云数据库架构高约 26%，同时将 p95 延迟保持在 20 毫秒以下。在向量检索场景中，将本地文件缓存配置到与索引规模匹配后，页面缓存命中率达到 95%–98%，热向量查询延迟可降至 4 毫秒。Ibotta 报告的 ML 模型服务延迟降低了 3–10 倍，服务计算成本下降 90%，分析 API 平均响应时间从 3–5 秒降至约 700 毫秒。这些数字需要结合具体工作负载解读，但它们至少说明：存储与计算的彻底解耦并没有以牺牲 OLTP 性能为必然代价。

谁在用，用来做什么

Lakebase 目前收敛出三种主要模式，每一种都对应着传统架构下需要额外搭建一套系统的场景。

把湖仓数据变成低延迟的服务接口。同步表将 Unity Catalog 中的 Gold 数据以秒级新鲜度映射到 Postgres，应用用标准 Postgres 驱动连接，拿到的是单数字毫秒的读延迟。物流公司 Hafnia 用 Lakebase 作为内部运营门户的事务引擎，将生产级应用的交付时间从两个月压缩到五天，缩减约 92%。easyJet 将欧洲最大的传统 SQL Server 环境之一上的收益管理桌面应用，用 Lakebase 重建为 Web 枢纽，开发周期从九个月降到四个月，同时把 100 多个 Git 仓库合并为两个。

作为 AI Agent 的状态和记忆后端。用 LangGraph 或 OpenAI Agent SDK 构建的代理，可以把对话状态和长期记忆存在 Lakebase 的 Postgres 表中，而不是散落在应用内存或额外的缓存层里。Databricks Apps 托管代理运行时，Lakebase 提供带 ACID 保证的读写状态存储，两者共享自动缩放和缩容到零的算力模型。在代理大规模创建和销毁数据库的场景下，DBA 不可能为每个数据库配一个人，Lakebase 把数据库遥测数据也写进湖仓，让“管理数据库”变成用 SQL 和 ML 模型看趋势、找异常的分析问题。

作为在线特征存储和混合检索底座。Model Serving 提供的模型可以通过 Lakebase 支撑的在线特征存储以低延迟读取特征。Lakebase 同时提供lakebase_vector和lakebase_text扩展，在同一个 Postgres 中支持向量语义搜索和全文检索，避免为 RAG 或搜索单独维护一个向量数据库。

冷静看待：架构红利与尚未闭合的缺口

Lakebase 的架构方向是清晰的，但把它当作“即插即用的 Aurora 替代品”会误判它的位置。Snowflake 的对比文章指出了几个实际缺口：Lakebase 不支持标准 Postgres 逻辑复制之外的常规复制方式，与外部系统的集成可能比传统 Postgres 更复杂；面向企业生产负载的公开可用性承诺和高级安全控制，在成熟度上尚未与运行了多年的云数据库拉平。成本方面，计算标价约为每 CU 小时 $0.092（AWS，限时折扣至 2027 年初），存储为每 GB 月 $0.345，缩容到零能显著降低间歇性负载的计算支出，但无服务器层的账单在持续高并发下仍可能膨胀，延迟和并发声明的第三方 SLO 验证仍然必要。

还有一个更结构性的判断标准：Lakebase 的收益与 Databricks 湖仓的绑定深度正相关。如果企业已经在 Unity Catalog 和 Delta 上运行分析负载，Lakebase 消除的是一整套“第二数据库 + 反向 ETL + 双治理面”的叠加成本，收益是乘数级的。如果企业的事务负载与湖仓几乎没有交集，Lakebase 的开放存储优势就无从兑现，它只是一款架构上更弹性的托管 Postgres，与传统方案相比未必划算。

Lakebase 最诚实的定位，是第三代数据库架构的一个早期样本：事务系统不再围绕一台机器设计，而是围绕云对象存储、弹性计算和湖仓治理重新组装。它不是在现有数据库上增加一个湖仓连接器，而是把数据库本身变成湖仓计算的一种形态。这条路能不能走通，取决于 Databricks 能否把企业级数据库的可靠性、安全性和可运维性补齐到与架构创新相匹配的水位。但至少，它让“OLTP 和 OLAP 共享一份数据”从一句口号，变成了一个有 Safekeeper、Pageserver 和 copy-on-write 分支支撑的可部署系统。