Every agent working inside a sandbox this year needed a database on the other side of a network call, and Databricks just closed that gap. On August 11, Neon, the serverless Postgres company Databricks acquired in 2025, absorbed Electric, the team behind PGlite, a build of Postgres compiled to WebAssembly small enough to run inside a browser tab, a serverless function, or an agent sandbox instead of on a separate server (Databricks, 2026).
PGlite's growth is the number that made the deal make sense. Weekly downloads climbed from 1 million to 13 million over the past year (Databricks, 2026), pulled by sandboxes, embedded apps, and test suites at companies including Prisma, Supabase, and AWS (Electric, 2026). Ali Ghodsi framed the move on LinkedIn as feeding "blazing fast AI agents" that need Postgres to run where the agent runs, then sync back to a central instance.
Databricks argues a single managed Postgres instance was built for a different kind of workload. Agents decide what data they need mid-task instead of running queries written in advance, and they often run inside sandboxes that reach the cloud only over a network hop. They also work in groups, needing a shared, current view of what teammates have already done to avoid duplicating work (Databricks, 2026).
One Postgres Dialect From Sandbox to Warehouse
PGlite compiles Postgres itself to WebAssembly and runs it in single-user mode inside the process that requested it, with no hosted service in between (Electric, 2026). An agent working inside a sandboxed container gets a real Postgres instance with no network round trip and no separate service to provision. Lakebase gives Databricks serverless Postgres on the server side. PGlite gives it the client side: the same SQL dialect and the same extensions, running on the laptop, browser, or sandbox where the agent itself executes. A schema written for Lakebase runs unmodified in PGlite, with no translation layer to maintain between the two.
Terms were not disclosed.
A schema written for Lakebase runs unmodified in PGlite, with no translation layer to maintain between the two.
A Sync Engine Built for Fleets of Agents
Local execution solves half the problem. Electric's real-time sync engine keeps distributed agents and centralized Lakebase infrastructure reconciled, the same architecture pattern behind Google Docs, Figma, and Notion, so a team of agents can share information with the record in the cloud while keeping fast local context (Databricks, 2026).
The Postgres lineage behind the deal runs deeper than the transaction itself. PGlite's core WASM Postgres work traces to Stas Kelvich, a Neon co-founder, and Electric turned that proof of concept into the embeddable database millions of projects now run every week (Databricks, 2026). Years earlier, while raising funding, Electric's founders were introduced to Nikita Shamgunov, Neon's chief executive, back when Electric was still syncing Postgres to SQLite rather than replacing it (Electric, 2026). Electric's own post describes the goal as wrapping world-class developer experience and agent experience around Lakebase as a single primitive.
One Dialect Buys Consistency. Cost Parity Is Still Unproven.
Databricks is betting that enterprises standardizing agent infrastructure will pay a premium to avoid running two SQL dialects, one for the sandbox and one for the warehouse. That is a real argument for platform teams committed to Postgres for governance, row-level security, and existing tooling. A team that runs Lakebase gets an agent-native database with no new dialect to learn and no new vendor to govern.
Not every agent platform made that choice first. Turso, a SQLite rewrite built around a database per agent rather than one instance shared across many, is running in production at a scale worth naming. CTO.new, a platform that assigns teams of AI agents to autonomous software projects, runs tens of thousands of Turso databases, one per project, with roughly 2,000 queried concurrently at peak, for a total bill of $500 a month (Turso, 2026). Turso databases are files, not processes, so an idle agent costs nothing to keep alive, an economic model PGlite was not built around. PGlite is single-user and single-connection by design, built for one agent talking to one embedded copy of Postgres rather than a platform spinning up tens of thousands of them at once (Electric, 2026; GitHub, 2026).
Whether Postgres compatibility is worth that cost difference depends on what a platform team has invested. A team standardized on Lakebase for governance and tooling gets real value from a shared dialect. A team that adopted SQLite for cheap, instant per-agent isolation is optimizing for something Postgres, even compiled to WebAssembly, was never built around.
Unknowns and Uncertainties
Acquisition terms were not disclosed, so the price Databricks paid for a team last counted at 21 employees is not verifiable. Electric's blog states that its existing open-source projects remain open source, but does not specify a timeline for merging PGlite's engine into Lakebase or whether its single-connection limitation is on a public roadmap. The sync engine's own adoption curve relative to PGlite's remains unstated, and Databricks has not addressed how it plans to compete on per-agent cost against database-per-agent architectures already running in production elsewhere.
Databricks. "Electric Joins Databricks to Bring WASM Postgres to AI Agent Sandboxes." Databricks Blog, 11 Aug. 2026, databricks.com.
Neon. "Electric Is Joining Team Neon at Databricks." Neon Blog, 11 Aug. 2026, neon.com.
Turso. "CTO.new Coordinates Tens of Thousands of AI Agents with a Database per Project on Turso." Turso Blog, Aug. 2026, turso.tech.
Databricks. "Databricks Is Raising a Strategic Round of Funding at a $188 Billion Valuation." Databricks Newsroom, 16 July 2026, databricks.com.
Tracxn. "ElectricSQL - 2026 Company Profile, Team & Competitors." Tracxn, 2026, tracxn.com.
GitHub. "electric-sql/pglite." GitHub, 2026, github.com.
