Databricks Acquires Electric to Give Every AI Agent its Own Postgres

Databricks just made a bet that the future of AI infrastructure looks less like one big shared database and more like thousands of tiny, disposable ones. The company announced it is acquiring Electric, the startup behind the WASM-based Postgres project PGlite and the Electric sync engine, as agentic applications change how developers use databases. The deal is a direct response to a pattern Databricks is already seeing in production: agents don't use databases the way humans do.

Agents broke the database model

Traditional applications are predictable. They have known query patterns, fixed data access, and one managed Postgres instance serves them well. Agents are different in three fundamental ways:

• They decide what data they need at runtime, updating their context several times per second. That inner loop wants data in the same process.
• They run inside sandboxes, where a remote database connection adds latency that compounds across every reasoning step.
• They work in parallel groups, requiring both fast local context and a shared, current view of what other agents have done to avoid duplicating work or acting on stale state.

The numbers from Databricks' own platform back this up. Agents now create roughly four times more databases than human users do on Lakebase. The average project carries about 10 database branches, some run more than 500 branch iterations deep, and for certain workloads, the average database compute session is alive for under 10 seconds. The old model of one durable server per app simply does not map to this world.

What Electric actually built

PGlite gives every agent its own lightweight Postgres right where it runs, providing ultra-low latency access to local context. It has grown from 1M to 13M weekly downloads in just twelve months. The key technical trick: PGlite is a lightweight WASM Postgres build, packaged into a TypeScript library for the browser, Node.js, Bun, and Deno, with no need to install any other dependencies. And at under 3MB gzipped, it is small enough to live inside the agent sandbox itself rather than on a separate server.

You can spin one up in a few lines:

import { PGlite } from '@electric-sql/pglite'
const db = new PGlite()
await db.query("select 'Hello world' as message;")
// -> { rows: [ { message: 'Hello world' } ] }

But the local database is only half the story. Electric's real-time sync engine continuously synchronizes data between distributed agents and centralized Lakebase infrastructure, enabling agents to securely share information with the definitive record in the cloud while keeping fast local context. Think of it as the multiplayer model powering Google Docs or Figma, applied to a fleet of agents that need to stay coordinated without stepping on each other.

A reunion of two halves

There is a neat historical loop here. PGlite began as a proof of concept by Neon co-founder Stas Kelvich, exploring Postgres compiled to WASM. Electric took that experiment and turned it into a database that millions of projects build on every week. Bringing the teams together closes a loop that started years ago.

The Electric team will join Neon, the serverless Postgres company Databricks acquired for about $1 billion last year and the foundation of its Lakebase database service. Lakebase separates storage from compute, keeping data in Postgres page format on object storage, which makes spinning up a new database branch a cheap copy-on-write metadata operation. PGlite and Lakebase are now the two ends of the same Postgres wire: one lives inside the agent sandbox, the other governs the durable record in the cloud, and Electric's sync engine keeps them consistent.

The open source question

For anyone already building on Electric's open source projects, the news is mostly good. Everything Electric has previously open sourced stays open source: Postgres Sync, PGlite, TanStack DB, and Durable Streams. Electric Cloud is winding down, and cloud users will need to self-host or move to another provider. The hosted service is the casualty; the libraries are not.

The Neon team notes that "complex problems like conflict resolution, partial replication, and reconnection logic make real-time sync difficult to build from scratch," which explains why Databricks chose to acquire rather than build. This is also part of a broader database acquisition spree for Databricks, which includes Neon itself and, more recently, transactional processing startup Mooncake.

Who wins, who loses, and what comes next

The clearest winner is anyone building agentic applications on the Databricks stack. The combination unlocks a pattern that was previously painful to assemble yourself:

1. Spin up an agent in a sandbox with its own PGlite instance for zero-latency local queries.
2. Let the agent read, write, and reason against local state at machine speed.
3. Sync results back to a Lakebase branch when the task completes.
4. Merge or discard the branch, just like a code branch in Git.

The loser, at least in the short term, is anyone who relied on Electric Cloud as a managed service. Those users need to migrate. Competitors in the local-first and edge database space, including projects like Turso and any SQLite-based sync layer, now face a well-funded, deeply integrated rival with a 13M-download-per-week head start in the WASM Postgres niche.

For the broader industry, this acquisition signals something important: the database layer is fracturing. The assumption that one cloud Postgres instance serves an application is giving way to a model where databases are ephemeral, abundant, and agent-scoped. Databricks closed approximately $5 billion in equity financing at a $134 billion valuation and reported a $5.4 billion annualized revenue run-rate growing more than 65% year-over-year, giving it the resources to keep assembling this stack aggressively. The Electric acquisition is not a one-off; it is a piece of a deliberate architecture for the agentic era, and the companies that do not have an answer to the local-execution-plus-sync problem will feel the gap.

Terms of the deal were not disclosed. The Electric team is already working with Neon inside Databricks, and the two teams say new backend capabilities are already in progress. For a first look at where the platform is heading, the Electric founders' post and the official Databricks announcement are the best starting points.