By ByteBot
PGlite went from a clever hack to corporate infrastructure in twelve months. The WebAssembly Postgres project that hit 13 million weekly downloads was just acquired by Databricks — and the reason is less about database strategy than about how AI agents are supposed to manage state. But before anyone panics: the open-source projects stay open. The hosted service does not.
What Happened
On August 11, Databricks announced that Electric — the team behind PGlite and the Electric sync engine — is joining Neon, the serverless Postgres company Databricks acquired for roughly $1 billion last year. Neon is the technical foundation of Lakebase, Databricks’ serverless Postgres product that crossed $100 million in revenue run-rate earlier this year.
The terms of what survives are important to get right:
- Stays open source: PGlite, the Electric sync engine, TanStack DB, Durable Streams — all under Apache 2.0 or MIT, unchanged
- Shuts down: Electric Cloud, the hosted sync service
- Unchanged: The npm package (
@electric-sql/pglite), the API, the documentation
If you are using PGlite in your test suite, your browser app, or your agent sandbox, nothing breaks. If you are an Electric Cloud customer, you need a migration plan — Lakebase is the intended destination.
Why Databricks Wanted This
Databricks is building what they call LTAP (think HTAP, but for LLMs): a unified data platform where the same Postgres schema spans cloud warehouses, serverless functions, and agent sandboxes. The acquisition completes the last layer.
The architecture Databricks is pitching is straightforward once you see it:
Agent 1 → PGlite (local) → Electric Sync ─┐
Agent 2 → PGlite (local) → Electric Sync ─┤→ Lakebase/Neon (cloud)
Agent N → PGlite (local) → Electric Sync ─┘Each agent gets its own lightweight Postgres instance running in its sandbox. No network round-trip for local reads. No schema translation — the same schema you deploy to Lakebase runs unmodified in PGlite. Electric’s sync engine keeps distributed agents aligned with a central record.
The comparison worth making here is SQLite and mobile apps. SQLite became the default local database for iOS and Android not because it was the most powerful option, but because it was the right abstraction at the right layer. Databricks is explicitly making the same bet for AI agents.
What PGlite Actually Is (If You Have Not Used It)
PGlite is PostgreSQL compiled to WebAssembly. Not a Postgres-compatible layer, not SQLite with a Postgres skin — actual Postgres, in a 3.7MB gzipped package. It runs in Node.js, Bun, Deno, and the browser. It supports pgvector, PostGIS (since v0.4 in March 2026), and real Postgres extensions.
Getting started takes one install:
import { PGlite } from '@electric-sql/pglite'
// Ephemeral — great for CI and testing
const db = new PGlite()
// Persistent in browser
const db = new PGlite('idb://agent-memory')
// Persistent in Node.js
const db = new PGlite('./data-dir')
await db.exec(`
CREATE TABLE IF NOT EXISTS agent_state (
id serial PRIMARY KEY,
session_id text,
key text,
value jsonb,
ts timestamptz DEFAULT now()
)
`)
const result = await db.query(
'SELECT * FROM agent_state WHERE session_id = $1',
['session-abc']
)The growth story makes the acquisition legible: 1 million weekly downloads in August 2025 became 10 million by June 2026 and 13 million by the time of the acquisition. It is already embedded in Prisma, Firebase, Netlify, and AWS toolchains. The community built the PostGIS WASM compile chain and the connection multiplexing layer. Databricks is not acquiring a side project — they are acquiring infrastructure that already runs in millions of environments.
The Implications Worth Paying Attention To
The longevity concern that comes with any small open-source company effectively disappears. Neon has strong Postgres engineering and Databricks has the balance sheet. PGlite is now maintained by the people who maintain Neon and Lakebase — people with a commercial incentive to keep it working.
Durable Streams, Electric’s open protocol for persistent real-time streams, is now positioned as the standard channel for stateful agent loops. If you are building multi-agent systems, this is worth a close read: the protocol generalizes Electric’s sync pattern into something addressable and replayable, not just reactive.
The one thing that does not survive is Electric Cloud. If you relied on the hosted sync service rather than running the open-source sync engine yourself, you are looking at a migration. Databricks has not published a formal migration guide yet, but Lakebase with the Electric sync engine is the obvious landing spot.
What to Do Now
If you are not using PGlite yet, now is the time to evaluate it. The Databricks acquisition validates the approach and eliminates the maintenance uncertainty that holds teams back from adopting smaller open-source projects. Start with CI: replace your Postgres Docker sidecar in tests with new PGlite() and see how fast your pipeline gets. Then consider what it means for your agents to have local structured state that syncs instead of making round-trip database calls for every operation.
If you are an Electric Cloud customer, start planning a migration now. The service is not shutting down tomorrow, but it is shutting down. The New Stack has a solid technical breakdown of the full Lakebase + PGlite architecture if you want the deeper read.
