Databricks收购Electric：为每个AI Agent配置独立Postgres数据库

Databricks 于周二宣布收购 Electric，这家初创公司是 基于 WASM 的 Postgres 项目 PGlite 及 Electric 同步引擎的幕后团队。在 Agent 应用改变开发者使用数据库方式的背景下，这笔交易应运而生。

Electric 团队将加入 Neon，后者是 Databricks 去年以约 10 亿美元收购的无服务器 Postgres 公司，也是其 Lakebase 数据库服务的基础。

交易条款未予披露。

Databricks 的收购标的

PGlite 是一个完整的 WebAssembly（WASM）版 Postgres 数据库。它可以在浏览器、Node.js 进程或 Agent 用来执行代码的沙箱中运行。它支持动态扩展加载，包括 pgvector——那是 Postgres 首选的向量扩展。

据两家公司透露，PGlite 过去一年周下载量从 100 万增长到 1300 万。

Electric 的核心：同步引擎

不过，真正让 Databricks 对 Electric 产生兴趣的是 Electric 同步引擎。这个引擎维护着一个中央 Postgres 数据库，可以与浏览器标签页、移动应用或 Agent 近实时同步。正如 Databricks 所指出的，这是 Figma 或 Google Docs 的多人协作模式，只是应用到 Postgres 及其使用者——也就是 Agent——身上。

Neon 团队在自家公告中写道："冲突解决、部分复制和重连逻辑等复杂问题使得实时同步难以从零开始构建。"这或许就是 Databricks 选择收购 Electric 而不是自己造轮子的原因。

至于 Electric 的未来，公司创始人 James Arthur 和 Valter Balegas 写道："我们此前开源的所有内容将继续保持开源。"这涵盖了同步引擎、PGlite、Durable Streams 和 TanStack DB。

然而，这笔交易中无法延续的是 Electric 的托管服务。"Electric Cloud 即将关停，"两位创始人写道。"云端用户需要自行托管或迁移到其他提供商。"

这笔交易也延续了 Databricks 的一系列数据库收购，包括 Neon 本身，以及最近的事务处理初创公司 Mooncake。

一个只存活 10 秒的数据库

Databricks 团队认为，传统的非 Agent 应用在多个客户端之间共享一个数据库，而那个数据库是整个技术栈中最持久的部分。但 Agent 工作负载改变了这一点。

在最近一篇关于 Agent 开发如何改变数据库的文章中，Databricks 的 Ippokratis Pandis、Nikita Shamgunov 和 Reynold Xin 写道：Agent 现在在 Lakebase 上创建的数据库数量大约是人类用户的四倍。他们还强调，现在每个项目平均携带约 10 个数据库分支，有些项目的分支迭代深度超过 500 层。

对于 Lakebase 上某些类型的应用，数据库计算的平均存活时间现在已不足 10 秒。

事实证明，Agent 喜欢像分支代码一样分支数据库——这是 Neon 构建其架构时所围绕的模式。

在实践中，一个编码 Agent 会启动一个沙箱，在其中实例化 PGlite，然后针对数据库进行构建和测试，最后要么丢弃整个沙箱，要么将结果与——在 Databricks 语境下——Lakebase 分支同步。因为 Lakebase 将存储和计算分离，并将数据以 Postgres 页面格式保存在对象存储上，所以创建那个分支是一个相对廉价的写时复制元数据操作。

"随着编码 Agent 将创建成本推向零，"Neon 团队写道，"应用数量会爆发式增长，而且大多数都是小型应用。"一个数据库服务器——哪怕是能缩容到零的无服务器数据库——仍然为最小可行应用的运行成本设定了一个下限。"如果每个应用都需要固定的最少计算资源，就不可能迎来富足时代，"文章指出。

"同一个想法的两个 halves"

值得注意的是，PGlite 并非诞生于 Electric。它最初是 Neon 联合创始人 Stas Kelvich 的一个实验——他将 Postgres 编译为 WASM，看看能否在客户端运行。Electric 接手了这项工作并将其打造为生产级项目。"那个仓库成为了 PGlite 的基础，"Arthur 和 Balegas 写道。

正如 Databricks 的公告所指出的，这如今"让同一个想法的两个 halves 重新走到了一起"。