---
url: /blog/2026/06/25/pglite-reaches-10-million-weekly-downloads.md
description: >-
  PGlite has reached 10 million weekly npm downloads. This post looks back at
  how Postgres in WASM became a widely adopted embedded Postgres project, and
  where PGlite is going next.
---

# PGlite reaches 10 million weekly downloads

PGlite has reached [10 million weekly npm downloads](https://www.npmjs.com/package/@electric-sql/pglite). We want to mark the milestone by sharing what people are building with PGlite, how a small Postgres-in-WASM experiment got here, and where we want to take it next.

PGlite passed 1 million weekly downloads just over a year ago. We always saw PGlite as something with reach beyond "embedded in your application" — but watching the community embrace it across local emulators, ORM integrations, test suites, browser sandboxes, AI apps, and the toolchains shipped by Prisma, Firebase, Netlify, and AWS has been the best part of getting here.

> \[!WARNING] 🪧  Quicklinks
> [PGlite](https://pglite.dev/) is Postgres compiled to WASM, packaged for JavaScript environments including browsers, Node.js, Bun, and Deno.
>
> * [PGlite docs](https://pglite.dev/)
> * [PGlite REPL](https://pglite.dev/repl/)
> * [GitHub](https://github.com/electric-sql/pglite/)
> * [Discord](https://discord.gg/pVASdMED)

## What's driving the downloads

### Local development without Docker

The biggest single category is local development for managed Postgres products. PGlite lets a CLI hand a developer a database the moment they install, then transparently swap in a cloud Postgres later without changing the application's connection code.

[Prisma](https://www.prisma.io/docs/postgres/database/local-development) bundles PGlite as the local engine for Prisma Postgres. Firebase runs it under [SQL Data Connect](https://firebase.google.com/docs/data-connect) for local prototyping. Netlify uses it to give developers an instant database when they spin up [Netlify Database](https://docs.netlify.com/build/data-and-storage/netlify-database/local-development/). And [AWS Blocks](https://docs.aws.amazon.com/blocks/latest/devguide/bb-data-storage.html) ships PGlite as the local implementation of `Database` and `DistributedDatabase`, mapping those same APIs to Aurora Serverless v2 and Aurora DSQL when the app deploys.

These are very different products solving the same problem: how to give a developer a database the second they install, using the same Postgres features and behaviour they'll eventually ship to.

### Local AI and search

AI apps need somewhere to keep embeddings, metadata, conversation history and document chunks, and somewhere to run full-text search and joins over all of it. PGlite gives them a local Postgres for the whole stack, `pgvector` included.

A particularly clear recent example is [GBrain](https://github.com/garrytan/gbrain), the personal-AI brain that Garry Tan (President of Y Combinator) built to run his own agents. GBrain [recently made PGlite its default engine](https://x.com/garrytan/status/2042920191303258192) for personal brains — "database ready in 2 seconds, no server" — using hybrid HNSW + BM25 retrieval over `pgvector` to run brains of up to ~50K pages on a developer's own machine.

It also shows up in [Hugging Face's Transformers.js](https://huggingface.co/docs/transformers.js) semantic search demos, in [Obsidian Smart Composer](https://github.com/glowingjade/obsidian-smart-composer) and [Infio Copilot](https://github.com/infiolab/infio-copilot), in [ElizaOS](https://github.com/elizaOS/eliza), in a number of agent-memory packages, and in experiments like local semantic search over your starred GitHub repos.

Inference, embeddings and vector search can all sit next to the application — in the browser or in the app — instead of being a separate service a round trip away.

### Tests against real, but tiny, Postgres

Test suites want databases that come up fast, stay isolated between tests, and don't leave anything behind when they finish. PGlite gives you that inside the test process — without dropping to a mock or a different SQL dialect.

[Drizzle](https://orm.drizzle.team) uses PGlite in its integration tests. [Supabase](https://supabase.com) pulls it into local mocks and test harnesses. Prisma projects can use PGlite through the [PGlite Prisma adapter](https://www.npmjs.com/package/pglite-prisma-adapter), giving them a fast, throwaway database that still talks the same SQL as production.

The useful part is that tests can exercise real Postgres behavior, not just adapter wiring. Drizzle's own [PGlite integration tests](https://github.com/drizzle-team/drizzle-orm/blob/48e54060/integration-tests/tests/pg/pglite.test.ts) spin up PGlite, reset the schema, then assert against real query results:

```ts
import { PGlite } from '@electric-sql/pglite'
import { sql } from 'drizzle-orm'
import { drizzle } from 'drizzle-orm/pglite'
import { beforeAll, beforeEach, expect, test } from 'vitest'

let db

beforeAll(() => {
  db = drizzle(new PGlite())
})

beforeEach(async () => {
  await db.execute(sql`drop schema if exists public cascade`)
  await db.execute(sql`create schema public`)
  await db.execute(sql`
    create table users (
      id serial primary key,
      name text not null
    )
  `)
})

test('insert via db.execute + select via db.execute', async () => {
  await db.execute(sql`insert into users (name) values (${'John'})`)

  const result = await db.execute(sql`select id, name from users`)
  expect(Array.from(result.rows)).toEqual([{ id: 1, name: 'John' }])
})
```

Like this, tests and data remain completely constrained to the JS engine and behave very close to production.

PGlite also make it trivial to [clone](https://pglite.dev/docs/api#clone) an existing instance, which is very handy when your thousand of tests need db access without interfering with each other. In practice, it also gives you almost instant database branching.

### ORMs and frameworks

A lot of adoption depends on the Postgres ecosystem around PGlite, not just PGlite itself. Once Drizzle or Kysely treats it as a normal Postgres target, the rest of the project does too.

PGlite now shows up across the Postgres tooling layer: Drizzle, [Kysely](https://kysely.dev), Prisma, [MikroORM](https://mikro-orm.io), [Effect SQL](https://effect.website/docs/sql/introduction), [Knex](https://knexjs.org), [TypeORM](https://typeorm.io), [Orange ORM](https://orange-orm.io) and others all [document how to point at it](https://pglite.dev/docs/orm-support).

Embedded Postgres is much more useful when developers don't have to throw away their existing migrations, schemas, query builders and type-safe database code to use it.

### Browser sandboxes and interactive docs

PGlite also runs Postgres in places a database server couldn't — inside browser products, docs, demos, and even research papers.

Supabase built [`database.build`](https://database.build/) on top of PGlite: an AI-assisted database design tool that runs entirely in the browser. [Supabase Studio](https://supabase.com/dashboard) uses it as a sandbox for testing RLS policies without touching the real database. The [Key Joins proposal](https://keyjoin.org/) goes further and embeds a custom PGlite build into the paper itself, so readers can run the proposed SQL syntax inline as they read. And in AI app builders like [Bolt.new](https://bolt.new), PGlite can put [a real database inside the sandbox](/blog/2025/06/05/database-in-the-sandbox), so generated apps can run without provisioning external Postgres first.

Smaller tools wrap PGlite for interactive code playgrounds: [LiveCodes](https://livecodes.io/) and [Codapi](https://codapi.org/) both let authors embed runnable Postgres snippets directly in their docs.

The video below shows the kind of browser-native database workflow that PGlite makes possible in [`database.build`](https://database.build/): the database is created, queried and iterated on inside the page, with no server to provision first.

Watch on YouTube: [I gave AI full control over my database (postgres.new)](https://www.youtube.com/watch?v=ooWaPVvljlU)

None of these work the same way with a conventional Postgres server. With PGlite the database is part of the document or the application, not something you point at over a network.

## Postgres is showing up in smaller places

All these different settings share one underlying need: a database that runs close to the application. Local emulators, test suites, browser sandboxes, AI runtimes — they all want real Postgres close to the application, without operating a separate Postgres server.

It helps when development, testing, local state and production all use the same database. Fewer translations between environments, fewer bugs that only show up in one of them.

AI coding agents writing code inside sandboxes make this trade-off sharper. The sandbox needs to look enough like production that the agent's work is meaningful, but it also has to stay cheap, fast and throwaway. A full Postgres server is too much; a different local database is too different.

[PGlite](/sync/pglite) is Postgres packaged for places that need something lighter and more embeddable than a full database deployment. It runs in single-user mode today, but it still brings most of the parts people reach for as projects grow — types, indexes, constraints, persistence, 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 got us looking again at a proof of concept Stas Kelvich at Neon had shared with us a while earlier: [Postgres running in WASM](https://github.com/kelvich/postgres_wasm).

At Electric we'd been bumping into a related problem from a different direction. We were syncing Postgres on the server into local databases on the client, and the hard part was always fidelity. Postgres has so many types, semantics and extensions that translating it into a different local database leaks behaviour somewhere every time.

The breakthrough Stas had already made was running Postgres in single-user mode inside WASM. Postgres normally lives as a multi-process system — a postmaster accepts connections and forks backend processes to handle them — which doesn't map onto WASM at all. Single-user mode collapses that into one process and one connection, just enough that you can package the result and ship it as a library.

We picked that up in February 2024 and had something working by the end of the month. The first cut was basic: single-user mode, JSON output hacked in, persistence either in memory or against a virtual filesystem. Rough, but real — you could import PGlite and run actual Postgres queries inside Node.js, Bun or the browser. The ["got it working" announcement](https://x.com/ElectricSQL/status/1760734511132995604) went out shortly after.

## Making it feel like Postgres

The early version could run queries, but using it from JavaScript still didn't feel much like working with Postgres.

Implementing the wire protocol changed that. Parameterised queries, type metadata, the connection lifecycle people expect from Postgres clients — all of it became possible once PGlite spoke the same protocol as every other Postgres client. Pulling `Asyncify` out of the main loop on the way made queries much faster on top.

Beyond querying, `pg_notify` unlocked local live queries: SQL queries that re-run reactively when their underlying tables change. Extension support pulled PGlite closer to being Postgres rather than just SQL-in-WASM — first with contrib extensions and `pgvector`, then PostGIS and a growing set of community-built extensions.

### Extensions make it Postgres

[PostGIS](/blog/2026/03/25/announcing-pglite-v04) was one of the most requested extensions. You can install it as a PGlite extension package:

```bash
npm install @electric-sql/pglite-postgis
```

```typescript
import { 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;')
```

Community contributors have brought extensions like Apache AGE, `pg_uuidv7`, `pgTAP`, `pg_hashids`, `pgcrypto` and PostGIS to PGlite. Our [extensions catalog](https://pglite.dev/extensions/) contains the currently supported extensions, and the docs include a [walkthrough for building Postgres extensions](https://pglite.dev/extensions/development#building-postgres-extensions) if you want to contribute a new one.

That brings the Postgres extension model into embedded environments, so the parts of Postgres people reach for in production are reachable locally too.

### Postgres in the browser

Running Postgres in the browser also changes what docs and demos can do. Instead of telling readers to install a database, you can drop a live one in front of them. The REPL below is running PGlite inside this page:

## What the pattern means

No single killer app got PGlite to 10M downloads. It's been a steady accumulation of teams from very different starting points all reaching for Postgres they can run wherever the application is — inside a CLI, inside a test, inside the browser tab, inside an AI agent — without giving up the behaviour they'd get from the managed Postgres they'll eventually deploy against.

Electric's own [PGlite sync adapter](/sync/pglite) is in that picture too: remote Postgres data syncs into a local PGlite that is still Postgres, instead of being translated into a different local data model on the way down.

## Where PGlite goes next

We want PGlite to keep moving from a clever Postgres-in-WASM port toward a first-class embedded Postgres, and we're excited about the next pieces we are working on and aiming to ship soon.

Recent architecture work made by Tudor has cut down the amount of custom Postgres code PGlite carries. That makes upstream upgrades less painful, gives contributors a more approachable codebase to land in, and makes PGlite a more realistic candidate for porting to other targets.

It's been only a few full moons since we've released [pglite-icu-full](https://www.npmjs.com/package/@electric-sql/pglite-icu-full), a build of [ICU](https://github.com/unicode-org/icu) for PGlite that can power multi language applications.

More extensions. The thing that makes Postgres what it is, more than anything else, is its extension ecosystem — and the more of it runs in PGlite, the more useful PGlite gets. We've got our eyes on time-series extensions such as [TimescaleDB](https://github.com/timescale/timescaledb) and we're keen on supporting Rust based ones such as [ParadeDB](https://github.com/paradedb/paradedb) by [Tiger Data](https://www.tigerdata.com). But there are many, many more that we'd like to bring in!

Multi-connection support is the next big piece we want to land. Postgres normally gets that by forking a backend process per connection; WASM does not give us `fork`, so PGlite currently works through Postgres single-user mode. We are working on emulating enough of that backend model in WASM to let multiple connections talk to the same embedded database, without making developers leave the JavaScript runtime or start a separate server.

There is also a more experimental, much wilder path we are excited to keep pushing on: making Postgres itself threaded. Sam has been exploring this in a [multithreaded Postgres branch](https://github.com/samwillis/multithreaded-postgres), asking whether PostgreSQL can keep the compatibility and isolation properties of its process-per-backend model while also supporting many more concurrent client sessions. That matters for PGlite because multi-session Postgres in WASM is much easier if Postgres can separate logical database sessions from OS processes and run those sessions inside one address space.

Logical replication is on the same list, and we're excited to make progress there too. Replicating in and out of PGlite would let it sit inside a Postgres topology rather than next to one.

The longer-term ambition is `libpglite`: a native, embeddable Postgres library for mobile, desktop and other non-JavaScript environments. The aim is for Postgres to be embeddable as broadly as SQLite, with the full Postgres feature set and tooling along for the ride.

## Try it, build with it, tell us what you make

Install PGlite:

```bash
npm install @electric-sql/pglite
```

Create a database and run a query:

```typescript
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')
```

Or run it behind a Postgres socket for tools that expect a normal database connection:

```bash
npm install @electric-sql/pglite @electric-sql/pglite-socket
```

```typescript
import { PGlite } from '@electric-sql/pglite'
import { PGLiteSocketServer } from '@electric-sql/pglite-socket'

const db = await PGlite.create()
const server = new PGLiteSocketServer({
  db,
  host: '127.0.0.1',
  port: 5432,
})

await server.start()
```

The [`pglite-socket`](https://pglite.dev/docs/pglite-socket) package also ships a `pglite-server` CLI that can start your app with `DATABASE_URL` already pointing at PGlite.

You can find the project on [GitHub](https://github.com/electric-sql/pglite/) and join the [Discord](https://discord.gg/pVASdMED).

Most of all, tell us what you're building — or want to build — with embedded Postgres. Thanks to everyone who's helped get PGlite here: users, contributors, extension authors, maintainers, and the teams who bet on it early.