PGlite has reached 10 million weekly npm downloads. We want to mark the milestone by looking back at how a small Postgres-in-WASM experiment became a widely used embedded Postgres project, and by sharing where we want to take it next.
🪧 Quicklinks
PGlite is Postgres compiled to WASM, packaged for JavaScript environments including browsers, Node.js, Bun, and Deno.
Postgres is showing up in smaller places
Developers keep finding reasons to put Postgres in places where a database server is too small or too temporary:
- AI sandboxes need a database inside the runtime so generated apps can run immediately.
- CI pipelines need isolated databases that can be created, reset, and thrown away cheaply.
- Local-first apps need durable storage with real query semantics.
- Sync systems need a local target that behaves like the Postgres it is syncing from.
They are different situations, but they all run into the same problem: the database needs to be closer to where the application is running.
The closer you get to production, the less glue you need
It helps when development, testing, local state, and production all use the same database model. There is less translation between environments, and fewer bugs where a query works in one place but fails in another.
This matters even more now that AI coding agents are changing code inside sandboxes. A useful sandbox needs to look enough like production that the agent is working against the real system. But it also needs to be cheap, fast, and disposable. A full database server is often too much; a different local database is often too different.
PGlite is an attempt to make that tradeoff less awkward: real Postgres semantics in places that need something smaller than a database server.
You should be able to use the same schema and run the same queries, including the parts of Postgres people often reach for later: types, indexes, constraints, full-text search, pgvector, PostGIS, and other extensions.
How PGlite got here
In January 2024, Jarred Sumner asked publicly when "PostgresLite" would become a thing.
The tweet made the idea feel timely, and prompted Sam to take a second look at a proof of concept Stas Kelvich at Neon had previously shared with us: Postgres running in WASM.
At Electric, we were already thinking about a related problem. We were syncing Postgres on the server into local databases on clients, and the hard part was fidelity. Postgres has rich types, strict semantics, extensions, and plenty of behavior that application code comes to rely on. Translating that into a different local database creates friction.
So Sam picked up the proof of concept in February 2024. By the end of the month, it built, ran from an npm package, and had its first "got it working" announcement. The first version was basic: Postgres single-user mode, hacked JSON output, and in-memory or filesystem-backed persistence. It was still rough, but you could start to see how it might become useful.
From there, the work became about making it useful. PGlite gained the Postgres wire protocol, parameterized queries, proper type handling, live queries, pg_notify, and extension support. Adoption followed when people could use it for real workflows: Supabase database.build, Prisma local development, CI, AI sandboxes, local-first apps, and sync with Electric.
The first hack: Postgres in WASM
The first job was getting from "Postgres can technically run in WASM" to "you can install this package and build something with it."
Stas had cracked the first problem by getting Postgres running in single-user mode inside WASM. That mattered because Postgres normally uses a multi-process architecture: a postmaster accepts connections and forks backend processes to handle them. WASM does not map cleanly to that model.
Single-user mode gave us a path through that. It runs Postgres as a single process, which made it possible to package a working database into a JavaScript environment. The first PGlite release used that path. It was rough, but it was real: import PGlite and run Postgres inside Node.js, Bun, or the browser.
Making it feel like Postgres
The early version could run queries, but using it from JavaScript did not yet feel much like using a real Postgres server.
The wire protocol changed that. It brought parameterized queries, type metadata, protocol behavior, and the developer experience people expect from Postgres clients. Refactoring the main loop removed Asyncify from the hot path and made query execution much faster.
Other pieces made it useful beyond one-off queries. pg_notify unlocked local live queries: SQL queries that can re-run reactively when underlying tables change. Extension support brought PGlite closer to the real Postgres platform, starting with contrib extensions and pgvector, then expanding toward PostGIS and community-built extensions.
Later architecture work reduced the amount of custom Postgres code PGlite has to carry. That makes upstream Postgres upgrades easier, helps contributors understand the codebase, and sets the project up for future ports.
Basic usage
Install PGlite:
npm install @electric-sql/pgliteCreate a database and run a query:
import { PGlite } from '@electric-sql/pglite'
const db = new PGlite()
await db.exec('CREATE TABLE test (id serial PRIMARY KEY, name text)')
await db.exec("INSERT INTO test (name) VALUES ('hello')")
const result = await db.query('SELECT * FROM test')PostGIS in PGlite
PostGIS was one of the most requested extensions. You can install it as a PGlite extension package:
npm install @electric-sql/pglite-postgisimport { PGlite } from '@electric-sql/pglite'
import { postgis } from '@electric-sql/pglite-postgis'
const pg = new PGlite({
extensions: {
postgis,
},
})
await pg.exec('CREATE EXTENSION IF NOT EXISTS postgis;')The community made it real
PGlite started as an Electric experiment. It changed once people began pulling it into workflows we could not have planned alone.
Supabase used it for database.build, an AI database design tool that runs locally in the browser. Prisma bundled PGlite into its CLI for local development, bringing it to a much wider developer audience.
Electric built a sync adapter so remote Postgres data can sync into local PGlite while preserving the Postgres data model. Community contributors helped bring extensions such as Apache AGE, pg_uuidv7, pgTAP, pg_hashids, pgcrypto, and PostGIS to PGlite.
The project became more interesting each time someone used it somewhere we had not expected.
What 10 million downloads looks like
PGlite passed 1 million weekly downloads a little over a year ago. It has now reached 10 million weekly npm downloads.
That growth came from several directions: developer CLIs, CI pipelines, browser apps, AI sandboxes, local-first apps, and sync use cases. Prisma helped bring PGlite into everyday local development flows. Supabase database.build showed what browser-native Postgres can enable for AI-assisted database design.
The number is worth celebrating because embedded Postgres is no longer just an interesting demo. It is being distributed through real tools people use. What matters most, though, is what people are building with it, and how those projects stretch what "local Postgres" can mean.
Where PGlite goes next
Next, we want PGlite to feel less like "Postgres squeezed into WASM" and more like embedded Postgres.
More extensions are a major part of that. Postgres is powerful because of its extension ecosystem, and PGlite needs to make extension building and porting easier.
We also want true multi-connection support. PGlite currently works around Postgres single-user mode; future work is exploring multi-instance and multi-threaded approaches. Replication is another area we are interested in. Logical replication into and out of PGlite would make it a more powerful participant in Postgres systems, not just a local runtime.
libpglite is the longer-term ambition: a native embeddable Postgres library for mobile, desktop, and non-JavaScript environments. The goal is embeddable Postgres that can be adopted as broadly as SQLite, while bringing Postgres semantics and tooling with it.
Try it, build with it, tell us what you make
Try PGlite with npm install @electric-sql/pglite. You can find the project on GitHub and join the Discord.
Most of all, tell us what you have built, or what you want to build, with embedded Postgres. Thank you to everyone who helped get PGlite here: users, contributors, extension authors, maintainers, and the teams that bet on it early.