Databricks 收购 PGLite：当 WASM 嵌入式数据库成为 AI 智能体的本地数据层

一、为什么这条新闻值得拆解

2026-08-11，Databricks 宣布收购 Electric —— 也就是 PGLite 和 Electric Sync 的母公司。这是 Databricks 在不到 16 个月之内第二次重仓 PostgreSQL：上一次是 2025-05 以约 10 亿美元收购 Neon，并把它改造为 Lakebase。

把这两次收购放在一起看，能看出一条很清晰的战略线：

1. 2025：把 PostgreSQL 推到中心云端（Lakebase，serverless Postgres）
2. 2026：把 PostgreSQL 推到边缘 / agent 本地（PGLite + Electric Sync）

加上 Databricks 在 2026-08-13 同步完成的 50 亿美元融资（估值 1900 亿美元），募资用途里明确点名「agent 数据基础设施」和 Electric 整合。把这三件事并起来读，结论很直接 —— Databricks 在押注一个完整的「agent 数据栈」：

中心层用 Lakebase 承担持久化与治理，边缘层用 PGLite 承担 agent 的本地读写，两层之间用 Electric Sync 做局部复制 / 双向同步。

这条战略对国产数据库厂商、对 PostgreSQL 生态、对所有正在做「agent + 数据」产品的团队都有直接参考价值。下面把它拆开来读。

二、PGLite：把 PostgreSQL 编译到 WebAssembly

2.1 它到底是什么

PGLite 是 Electric 团队在 2024 年初开源的项目，目标是把完整的 PostgreSQL 编译进 WebAssembly。整个产物是一个 ~3 MB 的单文件 wasm 模块（加上 JavaScript / TypeScript 胶水代码约 6 MB），可以在浏览器、Node.js、Bun、Deno、Cloudflare Workers、Service Worker、Electron 里直接跑起来，启动时间通常在 100 ms 以内。

注意：这不是把 PostgreSQL 的协议层「重写」一遍 —— 真正的 PostgreSQL C 代码（截至 PostgreSQL 17 的稳定基线，2026 年初已向 18 跟进）通过 Emscripten 工具链编译为 WASM，运行在沙箱化的线性内存里。它支持的 PostgreSQL 能力包括：

• 完整 SQL 方言（CTE、窗口函数、JSON、GIS 扩展 pgvector）
• 表、索引、视图、约束、外键
• 事务（MVCC + WAL）
• pgvector、PostGIS、pg_trgm 等 30+ 常用扩展
• 完整 pg_dump / pg_restore 兼容

它不支持（或部分支持）的能力集中在「需要真实进程间通信」的场景，比如跨实例复制、并行后台进程、文件系统锁。这意味着 PGLite 不是要替代服务端 PostgreSQL，而是为「单进程、单用户、高密度」场景设计的。

2.2 性能与生态现状

到 2026-08，PGLite 在 npm 周下载量已突破 1300 万次（见 BlocksAndFiles 报道），核心使用场景包括：

• 浏览器端本地 SQLite 的替代品（与 indexedDB / Origin Private File System 配合做持久化）
• Claude Code、Cursor、Devin 等 coding agent 的本地状态层
• Edge Functions（Cloudflare Workers、Vercel Edge）
• 离线优先的 SaaS 应用（行程规划、调研笔记、健康数据）

Electric 团队自己披露了 PGLite 在若干场景下的性能数字：在 M2 Mac 上跑 pgbench-like 场景，单连接简单 SELECT 延迟约 0.3 ms，写事务约 1.5 ms；典型 agent 会话涉及几十次 SELECT + 几次写，整体开销远低于一次远程 round-trip。

2.3 它和 SQLite WASM 有什么不同

很多读者第一反应是「这不就是 SQLite WASM 吗」。实际上二者定位完全不同：

对 agent 场景关键的是最后两项：pgvector 让本地也能跑 embedding + ANN 检索；pg 协议兼容意味着 agent 框架的 PG 适配器（比如 LangChain 的 PostgresChatMessageHistory）无需改造即可指向本地 PGLite。这两点是 PGLite 能在 agent 生态快速铺开的关键。

三、Electric Sync：双向同步引擎

3.1 解决什么问题

把 PGLite 当本地数据库用之后，自然会问：「本地数据怎么跟中心数据库同步？」传统方案是 CDC / ETL —— 周期地把本地变更同步到中心，或反过来从中心拉 schema。但 CDC 至少有两个问题：

1. agent 经常断网（飞行模式、隧道、企业代理），不能依赖周期同步
2. 本地写入是「事实已发生」，不能因为网络问题丢给中心失败重试

Electric Sync 是 Electric 团队为这个问题单独设计的同步引擎。它的核心抽象是「shape」：

一个 shape 是「一段 SQL 描述的表集合」，形如 SELECT id, name, email FROM users WHERE team_id = $1。

每个 PGLite 实例订阅一个或多个 shape，Electric 维护 shape 到中心 PG 的映射关系，shape 内的变更会从中心实时推到本地；本地对 shape 内表的写入会经过 Electric Sync 的客户端 SDK 上传到中心。

3.2 关键设计取舍

Electric Sync 的几个工程决策让它在 agent 场景特别合用：

1. CRDT 派生而非纯 CDC：写入路径不是「本地 WAL → 推到中心」，而是把每行写入表达为 shape 内部的 logical row，再按字段做 last-writer-wins 合并。这意味着 agent 即使在断网状态下连续改同一行多次，也能保证最终一致。
2. 字段级合并而非整行覆盖：避免「agent 在本地改了一行，中心 schema 变了」时整行丢失。字段级合并 + LWW 让本地未触碰的字段保留中心最新值。
3. 权限继承：本地端调用 SDK 走的是用户级 token，权限边界与中心一致 —— 不会出现「agent 在本地绕过 RBAC」。
4. 延迟一致性而非强一致：shape 同步最终一致（毫秒到秒级），agent 在本地读到的不是中心最新数据，但对绝大多数 agent 决策（写本地偏好、记笔记、缓存中间结果）足够。

代价是它不是「Postgres 的复制」，而是一套新的同步语义 —— 不能简单当成 logical replication 用。Databricks 收购 Electric 之后，把 Electric Sync 整合进 Lakebase，预计会把「中心 PG 的 logical replication」与「Electric Sync 的 shape 同步」做一层统一抽象，但 2026-08 时点还没有正式 GA。

四、Lakebase：从 Neon 到 Databricks 的 Postgres 战略锚点

4.1 Lakebase 在 Databricks 数据栈里的位置

Lakebase 不是凭空出现的。Databricks 2025-05 以约 10 亿美元收购 Neon（Neon 的核心是 serverless Postgres，存储与计算解耦、即时 branching），收购后做的主要改造：

1. 把 Neon 的存储层从 Neon 自有对象存储迁到 Databricks Lakehouse 的 Delta / Iceberg 共享存储
2. 把元数据接入 Unity Catalog
3. 在 serverless 计算层加入 Mosaic AI 的 agent 编排能力
4. 把它与 Genie、Unity AI Gateway 在一个控制面里管理

改造后的 Lakebase 据 Databricks 披露已跑通 1 亿美元 ARR（公司 Q2 整体 ARR 70 亿美元、同比 +80%）。一个有意思的数据点是 Databricks 在 TechCrunch 采访中提到的「Lakebase 超过 80% 的数据库实例是由 AI agent 自动创建的」 —— 这印证了「agent 才是 Postgres 在 2026 年最大的增量用户群」。

4.2 为什么 Databricks 同时需要 Neon 和 Electric

这看起来冗余，实际不是。Neon / Lakebase 解决的是「agent 的中心持久化」：状态、审计、合规、共享、跨 agent 协作；Electric / PGLite 解决的是「agent 的本地读写」：低延迟、离线、隐私、嵌入式部署。两层叠加后，agent 的完整数据生命周期是：

1. agent 启动 → 在本地 PGLite 里加载与自己相关的 shape（用户的偏好、当前任务的中间状态）
2. agent 处理任务 → 大部分读写命中 PGLite（亚毫秒级）
3. agent 需要跨实例 / 跨用户共享的数据 → 通过 Electric Sync 推到 Lakebase
4. agent 退出 / 重启 → 本地 PGLite 持久化到 OPFS 或本地磁盘，下次启动加载最新 shape
5. 审计与合规 → Lakebase 中心层保留全量历史，配合 Unity Catalog 做血缘追踪

这套架构呼应了 2026 年企业级 AI 落地的三个高频诉求：

• 低延迟：agent 每一步推理都伴随数据读写，远程 round-trip 是首要瓶颈
• 隐私：很多场景（医疗、法律、企业内部数据）不允许数据离开本地
• 合规：GDPR / HIPAA 等要求审计与最小化数据外流

五、对 PostgreSQL 生态的冲击

5.1 PostgreSQL 事实上成为 agent 数据底座

过去 18 个月，主流数据厂商密集往 PostgreSQL 加码：

• Databricks：Lakebase（Neon）+ Electric（PGLite）
• Snowflake：2025 年收购 Crunchy Data
• Redpanda：2025 年收购 SQL 引擎（Postgres 兼容）
• Microsoft：Fabric SQL DB、PostgreSQL on Azure 持续加码
• AWS：DynamoDB 内嵌向量 + Aurora MySQL/PostgreSQL
• ClickHouse：Ciklum 等合作伙伴把 PG 生态作为对接桥梁
• Couchbase：在 Capella 里加入 PG 兼容层

把所有动作并起来读，结论是 PostgreSQL 在「agent 数据栈」这个新战场上已经成为事实标准 —— 不是因为它最好，而是因为它有完整的 SQL 方言、扩展生态、客户端工具链，迁移成本最低。

5.2 对其它数据库的挤压

这个趋势对国产数据库、专用向量数据库、传统 NewSQL 都是压力：

• 国产数据库（OceanBase、PolarDB、达梦、openGauss、GaussDB）：在 AI agent 数据栈这一波上不能简单「兼容 MySQL」就完事，需要认真考虑 PG 兼容路线的可行性，否则会被生态绑死。
• 专用向量数据库（Weaviate、Qdrant、Milvus、Pinecone）：pgvector 已经能稳定跑到 1000 万+ 向量，对中小规模 RAG / agent 场景，独立向量数据库的必要性被持续稀释；差异化必须往「hybrid retrieval + 边缘部署 + 行业 know-how」走。
• 传统 NewSQL（CockroachDB、TiDB、YugabyteDB）：分布式 SQL 的传统故事（水平扩展、地理分布）依然有效，但「agent 数据底座」这一波被 PostgreSQL + 服务端 serverless + 边缘 PGLite 的组合吃掉不少话语权。Yugabyte 已经推出 Meko、CockroachDB 在谈 agent-native 故事，但效果待观察。

六、对国产数据库的启示

Databricks 这两次收购 + 一次大额融资给国产数据库厂商至少四个直接启示：

6.1 PG 兼容不是「加分项」，是「入场券」

过去几年很多国产数据库在宣传上主打「对 Oracle / MySQL 兼容」，但 2026 年的 agent 数据栈里 PostgreSQL 才是那个「必须兼容」的对象。建议把 PG 方言 / 协议 / 扩展兼容作为下一代版本的硬指标，不只是 wire protocol 兼容。

6.2 双层架构：中心 + 边缘

PGLite 模式给国产数据库一个新的「边缘」产品思路：能不能做一个 PG 兼容的 WASM 嵌入式实现，承担边缘 / 离线 / agent 本地场景？这块的工程门槛在 WASM 编译与 PG 扩展移植（pgvector 是首选），对国产数据库的研发投入不算大，但对拿下 agent 数据栈入口价值很高。

6.3 双向同步是新型基础设施

Electric Sync 这类 shape-based 双向同步不是 Postgres 自带的能力，是「新基建」。如果国产数据库想要做中心 + 边缘的双层架构，需要从头设计一套同步语义，简单搬 CDC / logical replication 不够。

6.4 Agent 数据栈是 ARR 的新增长极

Databricks Lakebase ARR 1 亿美元、80%+ 实例由 agent 创建 —— 这个数字给所有数据库厂商一个清晰的「下一个 ARR 增长极」信号。国产数据库如果不在 2026-2027 把 agent 数据场景作为产品战略重点，会错过下一波云数据库红利。

七、给技术人的结论

• 如果你正在做 coding agent / 数据 agent 类产品，PGLite + Electric Sync 是当前最值得评估的本地数据层选择；投入小、收益直接（本地读写 + 离线 + 隐私）。
• 如果你正在做数据库产品，PG 兼容 + WASM 嵌入式 + 双向同步 是 2026 年下半年的三个关键词；忽略任何一项都会在 agent 数据栈里失去位置。
• 如果你正在评估 RAG / agent 平台，向量检索尽量走 pgvector，避免引入新的独立向量数据库（除非明确超过 1000 万+ 向量或特殊 hybrid 检索需求）。
• 如果你正在做企业 AI 落地，关注 Databricks 这次 $5B 融资里点名的「agent 数据基础设施」方向 —— 这是 2026-2027 年数据库行业最大的资本叙事。

参考资料

• CNBC: Databricks wraps $5B funding round at $190B valuation
• TechCrunch: Databricks wanted to raise $1B, investors wanted $15B
• InfoWorld: Databricks acquires Electric to bring local Postgres databases to agentic apps
• The New Stack: Databricks acquires Electric to give every AI agent its own Postgres database
• BlocksAndFiles: Oh no, not another one! Databricks buys Electric
• TechTarget: Databricks' Electric acquisition adds embeddable PostgreSQL
• PGLite GitHub Repository
• Electric SQL 官网