文章目录传统数据库的“单机宿命”Lakebase 的切法把 WAL 和页面都交给独立服务不是“又一个托管 Postgres”开放格式才是分水岭LTAP比“湖仓一体”更进一步的架构信号谁在用用来做什么冷静看待架构红利与尚未闭合的缺口五年前Databricks 用“Lakehouse”重新定义了分析型数据架构的存放方式。五年后它试图用同一个逻辑回答另一个问题如果存储可以独立于计算存在为什么事务型数据库还要被困在一台机器的磁盘上Lakebase 给出的答案不是又一款“托管 Postgres”而是一次对数据库架构层的重新切分把 OLTP 引擎变成无状态的、可抛弃的计算把数据以开放格式直接放进湖仓让事务与分析第一次共享同一份存储而不是靠管道去“同步”。如果说 Lakehouse 解决的是 OLAP 的弹性问题那么 Lakebase 瞄准的是 OLTP 的结构性僵化。传统数据库的“单机宿命”要理解 Lakebase 改了什么先看它拆了什么。一台传统 PostgreSQL 实例是一个紧凑的单机系统查询引擎、Write-Ahead LogWAL和数据文件挤在同一台机器的本地磁盘上。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 提出的 LTAPLake Transactional/Analytical Processing概念值得单独拆开看。湖仓一体解决的是分析负载的统一存放LTAP 试图统一的是事务与分析在存储层的共存同一份湖存储同时服务 OLTP 和 OLAP取消团队长期维护的 CDC 同步链路让事务系统和分析系统不再需要“保持同步”。这个方向的工程基础来自两次收购。Lakebase 的无状态 Postgres 引擎和存储分离架构源自 NeonMooncake 则带来了在 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.092AWS限时折扣至 2027 年初存储为每 GB 月 $0.345缩容到零能显著降低间歇性负载的计算支出但无服务器层的账单在持续高并发下仍可能膨胀延迟和并发声明的第三方 SLO 验证仍然必要。还有一个更结构性的判断标准Lakebase 的收益与 Databricks 湖仓的绑定深度正相关。如果企业已经在 Unity Catalog 和 Delta 上运行分析负载Lakebase 消除的是一整套“第二数据库 反向 ETL 双治理面”的叠加成本收益是乘数级的。如果企业的事务负载与湖仓几乎没有交集Lakebase 的开放存储优势就无从兑现它只是一款架构上更弹性的托管 Postgres与传统方案相比未必划算。Lakebase 最诚实的定位是第三代数据库架构的一个早期样本事务系统不再围绕一台机器设计而是围绕云对象存储、弹性计算和湖仓治理重新组装。它不是在现有数据库上增加一个湖仓连接器而是把数据库本身变成湖仓计算的一种形态。这条路能不能走通取决于 Databricks 能否把企业级数据库的可靠性、安全性和可运维性补齐到与架构创新相匹配的水位。但至少它让“OLTP 和 OLAP 共享一份数据”从一句口号变成了一个有 Safekeeper、Pageserver 和 copy-on-write 分支支撑的可部署系统。
