PGlite reaches 10M weekly downloads

samwillis1 pts0 comments

PGlite reaches 10 million weekly downloads | Electric

Skip to content

Go to Cloud<br>Cloud<br>Go to Cloud

Return to top

← Blog

PGlite reaches 10 million weekly downloads

By Sam Willis and Tudor Zaharia

Are you an LLM? You can read better optimized documentation at /blog/2026/06/25/pglite-reaches-10-million-weekly-downloads.md for this page in Markdown format<br>PGlite has reached 10 million weekly npm downloads. 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.<br>🪧  Quicklinks<br>PGlite is Postgres compiled to WASM, packaged for JavaScript environments including browsers, Node.js, Bun, and Deno.<br>PGlite docs<br>PGlite REPL<br>GitHub<br>Discord

What's driving the downloads ​<br>Local development without Docker ​<br>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.<br>Prisma bundles PGlite as the local engine for Prisma Postgres. Firebase runs it under SQL Data Connect for local prototyping. Netlify uses it to give developers an instant database when they spin up Netlify Database. And AWS Blocks 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.<br>Local AI and search ​<br>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.<br>A particularly clear recent example is 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 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 semantic search demos, in Obsidian Smart Composer and Infio Copilot, in ElizaOS, in a number of agent-memory packages, and in experiments like local semantic search over your starred GitHub repos.<br>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.<br>Tests against real, but tiny, Postgres ​<br>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.<br>Drizzle uses PGlite in its integration tests. Supabase pulls it into local mocks and test harnesses. Prisma projects can use PGlite through the PGlite Prisma adapter, giving them a fast, throwaway database that still talks the same SQL as production.<br>The useful part is that tests can exercise real Postgres behavior, not just adapter wiring. Drizzle's own PGlite integration tests spin up PGlite, reset the schema, then assert against real query results:<br>tsimport { PGlite } from '@electric-sql/pglite'<br>import { sql } from 'drizzle-orm'<br>import { drizzle } from 'drizzle-orm/pglite'<br>import { beforeAll, beforeEach, expect, test } from 'vitest'

let db

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

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

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

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

Like this, tests and data remain completely constrained to the JS engine and behave very close to production.<br>PGlite also make it trivial to 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.<br>ORMs and frameworks ​<br>A lot of adoption depends on the Postgres ecosystem around PGlite, not just PGlite itself. Once Drizzle...

pglite postgres local database downloads tests

Related Articles