企业官网建设流程全解析

PGlite 周下载量突破 1000 万：嵌入式 Postgres 的成长路径、应用生态与演进蓝图

【免费下载链接】electricThe agent platform built on sync.项目地址: https://gitcode.com/GitHub_Trending/el/electric

PGlite 是 Postgres 编译为 WASM 的嵌入式数据库实现，可运行于浏览器、Node.js、Bun 与 Deno 等 JavaScript 环境中。本文围绕其 npm 周下载量突破 1000 万的里程碑，完整梳理它被本地开发、AI 应用、测试套件与浏览器沙盒大规模采用的技术原因，并结合本仓库源码深入剖析其单用户模式原理、扩展机制、同步适配能力以及未来的多连接、多线程与 libpglite 路线图，帮助读者理解"贴近应用运行的 Postgres"这一模式为什么正在成为主流。

里程碑：PGlite 达到 1000 万周下载量

PGlite 的 npm 周下载量已经突破1000 万。团队用这篇博文回顾其成长过程：一个"Postgres in WASM"的小实验，如何成长为被广泛采用的嵌入式 Postgres 项目，以及下一步将去向何方。

就在一年多以前，PGlite 的周下载量才刚刚跨过 100 万。团队从一开始就认为 PGlite 的价值不止于"嵌入到你的应用里"——社区把它用在了本地模拟器、ORM 集成、测试套件、浏览器沙盒、AI 应用，以及 Prisma、Firebase、Netlify、AWS 等厂商所交付的工具链中。这正是一个嵌入式数据库生态走向成熟的典型轨迹。

PGlite 的核心定位可以用仓库中的产品页一句话概括：它是"轻量级 WASM Postgres，打包成 TypeScript 库，面向浏览器、Node.js、Bun 和 Deno"，gzip 后体积不足 3MB，不需要安装任何其他依赖即可在 JavaScript 里运行 Postgres（见 PGlite 产品页）。与早期"Postgres in the browser"项目不同，PGlite 不借助 Linux 虚拟机，而是直接用单用户模式编译出的 WASM Postgres。

什么在推动下载量：五大典型场景

PGlite 的下载量并非由单一场景驱动，而是多个截然不同的需求共同汇流的结果。

本地开发不再依赖 Docker

最大的单一来源是托管 Postgres 产品的本地开发体验。PGlite 让一个 CLI 可以在开发者安装的瞬间就交付一个数据库，之后在应用不修改连接代码的前提下，透明地切换到云上 Postgres：

• Prisma将 PGlite 捆绑为 Prisma Postgres 的本地引擎；
• Firebase在 SQL Data Connect 的本地原型开发中使用 PGlite；
• Netlify用它让开发者在启动 Netlify Database 时立即获得一个数据库；
• AWS Blocks将 PGlite 作为Database与DistributedDatabase的本地实现随产品发布，应用部署后则映射到 Aurora Serverless v2 与 Aurora DSQL。

这些产品差异巨大，但解决的是同一个问题：如何让开发者在安装的瞬间就拿到一个数据库，并且这个数据库的行为与最终上线的 Postgres 完全一致。PGlite 恰好提供了这个"最小但真实"的中间层。

本地 AI 与向量搜索

AI 应用需要存储嵌入向量、元数据、会话历史与文档分块，还需要在其上运行全文检索与 join 查询。PGlite 为整条链路提供本地 Postgres，pgvector也一并包含在内。

一个非常清晰的近期案例是 GBrain——Y Combinator 总裁 Garry Tan 为自己运行 agents 而构建的个人 AI 大脑。GBrain 已将 PGlite 设为个人大脑的默认引擎，官方描述是"数据库 2 秒就绪，无需服务器"，基于pgvector上的混合 HNSW + BM25 检索，可以在开发者自己的机器上支撑约 5 万页规模的 brain。

同类用法还出现在 Hugging Face Transformers.js 的语义搜索演示、Obsidian Smart Composer、Infio Copilot、ElizaOS、多个 agent-memory 包，以及"对 GitHub 星标仓库做本地语义搜索"之类的实验中。

这意味着推理、嵌入与向量检索都可以与应用同处一地——在浏览器里或应用进程内，而不是一个需要网络往返的独立服务。

针对真实但微型的 Postgres 进行测试

测试套件需要启动快、用例间相互隔离、结束后不留痕迹的数据库。PGlite 把这一切放进测试进程内部，同时不需要退化成 mock 或换一种 SQL 方言：

• Drizzle在自己的集成测试中使用 PGlite；
• Supabase把它拉进本地 mock 与测试脚手架；
• Prisma 项目可以通过 PGlite Prisma adapter 使用 PGlite，得到一个快速、可丢弃、但 SQL 行为与生产一致的数据库。

Drizzle 的 PGlite 集成测试正是这种模式的标准示范：启动 PGlite、重置 schema，然后针对真实查询结果做断言：

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' }]) })

这样，测试与数据被完全约束在 JS 引擎之内，行为却与生产环境非常接近。此外，PGlite 的cloneAPI 可以克隆既有实例，当上千个测试用例都需要数据库访问、又互不干扰时非常有用——在实践中几乎等于"即时的数据库分支"。

ORM 与框架生态

PGlite 的普及在很大程度上依赖其周围的 Postgres 生态，而不只是 PGlite 本身。一旦 Drizzle 或 Kysely 把 PGlite 当作普通 Postgres 目标，整个项目链路上的工具也就随之打通了。

当前 PGlite 已出现在 Postgres 工具链的各个层面：Drizzle、Kysely、Prisma、MikroORM、Effect SQL、Knex、TypeORM、Orange ORM 等都文档化了对它的接入方式。核心价值在于：嵌入式 Postgres 只有在开发者无需丢弃现有迁移、schema、查询构建器与类型安全数据库代码时，才真正有用。

浏览器沙盒与交互式文档

PGlite 还能让 Postgres 出现在数据库服务器原本到不了的地方——浏览器产品、文档、演示乃至研究论文内部：

• Supabase 在 PGlite 之上构建了database.build，一个完全运行在浏览器中的 AI 辅助数据库设计工具；
• Supabase Studio 用 PGlite 作为测试 RLS 策略的沙盒，不触碰真实数据库；
• Key Joins 提案把定制的 PGlite 构建直接嵌入论文本身，读者可以在阅读时直接运行论文提出的 SQL 语法；
• 在 Bolt.new 这类 AI 应用构建器中，PGlite 可以把真实数据库放进沙盒，让生成的应用无需先配置外部 Postgres 即可运行（详见仓库内博客 《Vibe coding with a database in the sandbox》）。

更轻量的工具则用 PGlite 搭建交互式代码游乐场：LiveCodes 与 Codapi 都允许作者在文档中直接嵌入可运行的 Postgres 片段。这类场景的共同点是：数据库成为文档或应用的一部分，而不是通过网络指向的某个服务——这是传统 Postgres 服务器无法复刻的体验。

模式本身：Postgres 正在进入更小的运行环境

上述所有场景共享同一个底层需求：让数据库贴近应用运行。本地模拟器、测试套件、浏览器沙盒、AI 运行时，都希望在应用附近得到真实的 Postgres，却不想运维一个独立的 Postgres 服务器。

当开发、测试、本地状态与生产使用同一个数据库时，环境之间的"翻译层"就变少了，只在某个环境出现的 bug 也变少了。对在沙盒中写代码的 AI 编码 agent 而言，这一权衡更加尖锐：沙盒既要足够像生产环境以保证 agent 的产出有意义，又必须便宜、快速、可丢弃。完整的 Postgres 服务器太重，换成别的本地数据库又差异太大。

PGlite 正是为这些"需要比完整数据库部署更轻、更可嵌入"的场景而打包的 Postgres。它目前运行在单用户模式下，但仍然带来项目成长时人们最常需要的那些能力：类型、索引、约束、持久化、全文搜索、pgvector、PostGIS 以及其他扩展（特性清单见 PGlite 产品页）。

从本仓库的示例项目也能直观看到这种"数据库贴近应用"的落地方式。linearlite示例（一个类 Linear 的离线优先看板应用）在浏览器里通过 Web Worker 启动 PGlite，并挂载live（实时查询）与electricSync（同步）两个扩展（见 examples/linearlite/src/App.tsx）：

async function createPGlite() { return PGliteWorker.create(new PGWorker(), { extensions: { live, sync: electricSync(), }, }) }

随后它把服务端 Postgres 的表以 Shape 形式同步进本地 PGlite，并用实时查询驱动 UI（见 examples/linearlite/src/sync.ts）。也就是说，一个完整的数据驱动应用可以只依赖浏览器内的嵌入式 Postgres 运行起来。

PGlite 是如何走到今天的：从 WASM 实验到主流嵌入式数据库

起点：一次公开提问与 Neon 的概念验证

2024 年 1 月，Jarred Sumner 公开提问"PostgresLite"何时会成真。这个提问让整个想法显得正当其时，也让团队重新审视 Neon 的 Stas Kelvich 更早分享的一个概念验证：运行在 WASM 中的 Postgres。

Electric 的视角：同步保真度问题

Electric 团队当时正从另一个方向撞上相关的问题：他们要把服务器上的 Postgres 同步进客户端的本地数据库，而最困难的部分始终是保真度。Postgres 拥有极多的类型、语义与扩展，把它翻译成另一种本地数据库，几乎每次都会在某处泄漏行为差异。

单用户模式：关键突破

Stas 已经做出的突破，是在 WASM 内以单用户模式运行 Postgres。Postgres 本质上是多进程系统——postmaster 接受连接并 fork 后端进程来处理它们——这根本无法映射到 WASM。单用户模式把这一切收敛为"一个进程 + 一个连接"，恰好足以把结果打包成一个库来分发。

从概念到可运行：2024 年 2 月

Electric 于 2024 年 2 月接手这个方向，当月底就做出了可运行的东西。第一版相当朴素：单用户模式、hack 进去的 JSON 输出、基于内存或虚拟文件系统的持久化。虽然粗糙，但是真实的——你可以在 Node.js、Bun 或浏览器里导入 PGlite 并运行真正的 Postgres 查询。随后不久团队就发布了"got it working"的公告。

让它"像 Postgres"：协议、实时查询与扩展

早期版本能跑查询，但从 JavaScript 使用它的体验还不太像在操作 Postgres。

实现 wire protocol

实现 wire protocol改变了这一切。参数化查询、类型元数据、Postgres 客户端所期望的连接生命周期，都在 PGlite 使用与所有 Postgres 客户端相同的协议之后成为可能。同时把Asyncify从主循环中移除，让查询在此基础上快了许多。

pg_notify 与本地实时查询

在查询之外，pg_notify解锁了本地实时查询：当底层表变化时，SQL 查询会响应式地重新执行。这正是 PGlite 产品页 中所说的"reactive"能力，也是linearlite示例中pg.live.query(...)驱动 UI 更新的基础。

扩展让它成为 Postgres

扩展支持把 PGlite 从"WASM 里的 SQL"进一步推向"真正的 Postgres"——先是 contrib 扩展与pgvector，然后是 PostGIS 和越来越多的社区构建扩展。

PostGIS 是呼声最高的扩展之一（v0.4 版本中正式发布，见仓库博客 《Announcing PGlite v0.4》）。安装方式如下：

npm install @electric-sql/pglite-postgis

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;')

社区贡献者还带来了 Apache AGE、pg_uuidv7、pgTAP、pg_hashids、pgcrypto等扩展。这等于把 Postgres 的扩展模型引入了嵌入式环境——生产环境里人们伸手就用的 Postgres 组件，在本地也同样触手可及。

浏览器中的 Postgres

在浏览器中运行 Postgres，还改变了文档与演示能做什么。与其让读者自己安装数据库，不如把一个活的数据库直接摆在他们面前——PGlite 的 REPL 就是在网页内部运行着 PGlite。

这个模式意味着什么

没有单一"杀手级应用"把 PGlite 送到 1000 万周下载量。它来自不同起点的团队持续不断的积累——大家都在伸手去拿"应用在哪就能在哪运行"的 Postgres：在 CLI 里、在测试里、在浏览器标签页里、在 AI agent 里——同时不牺牲最终部署目标托管 Postgres 时才能获得的行为。

Electric 自己的PGlite sync 适配器也在其中：远端 Postgres 数据同步进本地的 PGlite，落地后依然是 Postgres，而不是在下行途中被翻译成另一种本地数据模型。仓库中的同步示例展示了完整的接入方式（见 website/src/partials/sync-into-pglite.tsx）：

import { PGlite } from '@electric-sql/pglite' import { live } from '@electric-sql/pglite/live' import { electricSync } from '@electric-sql/pglite-sync' import { useLiveQuery } from '@electric-sql/pglite-react' // 创建一个持久化的本地 PGlite 数据库 const pg = await PGlite.create({ dataDir: `idb://my-database`, extensions: { electric: electricSync(), live, }, }) // 初始化本地数据库 schema await pg.exec(` CREATE TABLE IF NOT EXISTS items ( id SERIAL PRIMARY KEY, ); `) // 建立持久化的 Shape 订阅 await pg.electric.syncShapeToTable({ shape: { url: `${BASE_URL}/v1/shape` }, table: `items`, primaryKey: [`id`], }) // 用针对本地嵌入式数据库的实时查询把数据绑定到组件 const Component = () => { const items = useLiveQuery(`SELECT * FROM items;`) return <pre>{JSON.stringify(items)}</pre> }

这里的 Shape 是 Electric 同步体系的核心原语，用于定义要同步到本地的数据子集（表 + 可选的 where 过滤、列选择、可查询列限制，详见 Shapes 指南）。在linearlite示例中，syncShapeToTable配合commitGranularity: 'up-to-date'、useCopy: true以及初始同步完成后的索引重建，实现了一套完整的"云端 Postgres ↔ 浏览器内 PGlite"双向同步链路。

PGlite 接下来走向何方

团队希望 PGlite 从"聪明的 Postgres-in-WASM 移植"持续演进为一流的嵌入式 Postgres，以下工作正在推进之中。

架构简化：减少自定义 Postgres 代码

近期架构工作大幅削减了 PGlite 携带的自定义 Postgres 代码量。这让上游升级的代价更低，贡献者进入代码库的门槛更友好，也让 PGlite 成为向其他目标平台移植时更现实的选择。

pglite-icu-full

团队已发布pglite-icu-full，一个为 PGlite 准备的 ICU（Unicode 国际化组件）构建，可为多语言应用提供国际化能力。

更多扩展

让 Postgres 之所以是 Postgres 的，首先是它的扩展生态——PGlite 里能跑的扩展越多，它就越有用。团队正在关注 TimescaleDB 这类时序扩展，以及 ParadeDB 这类基于 Rust 的扩展，并且还有更多扩展在计划清单上。

多连接支持

下一个要落地的重大组件是多连接支持。Postgres 通常通过为每个连接 fork 一个后端进程来获得并发能力；WASM 不提供fork，所以 PGlite 目前依赖 Postgres 单用户模式。团队正在 WASM 中模拟足够的后端模型，让多个连接可以对话同一个嵌入式数据库，而开发者无需离开 JavaScript 运行时或启动独立服务器。

多线程 Postgres 探索

一条更实验性、也更激进的道路是让 Postgres 本身线程化。Sam 正在 multithreaded Postgres 分支中探索：PostgreSQL 能否在保留 process-per-backend 模型的兼容性与隔离性的同时，支持远多于当前的并发客户端会话。这对 PGlite 意义重大——如果 Postgres 能把逻辑数据库会话与操作系统进程分离、在单一地址空间内运行会话，那么 WASM 中的多会话 Postgres 就会容易得多。

逻辑复制

逻辑复制也在同一张路线图上。能够向 PGlite 内/外复制，将让 PGlite 置身于 Postgres 拓扑之内，而不是旁边。

libpglite：像 SQLite 一样可嵌入

更长期的愿景是libpglite：一个面向移动端、桌面端以及其他非 JavaScript 环境的原生可嵌入 Postgres 库。目标是让 Postgres 能像 SQLite 一样被广泛嵌入，同时保留完整的 Postgres 特性集与工具链。

立即上手：安装、查询与 socket 模式

安装 PGlite：

npm install @electric-sql/pglite

创建数据库并执行查询：

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

或者把它运行在 Postgres socket 之后，供那些期望普通数据库连接的工具使用：

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

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()

pglite-socket包还附带一个pglite-serverCLI，可以让你的应用以DATABASE_URL直接指向 PGlite 的方式启动——这也是 AI 应用构建器在沙盒里免配置数据库的关键。你可以继续在仓库内了解 PGlite 的完整同步接入方式（PGlite 产品页、同步示例）或参考 linearlite 示例 这样的完整离线优先应用；也可以查看本仓库examples/linearlite/package.json中 PGlite 相关依赖（@electric-sql/pglite、pglite-react、pglite-repl、pglite-sync）的组合使用方式。

无论是本地开发、测试隔离、浏览器沙盒还是 AI agent 运行时，"应用在哪、Postgres 就在哪"这一模式正随着嵌入式 Postgres 的成熟而变得更加可及——1000 万周下载量正是这一趋势的注脚。

【免费下载链接】electricThe agent platform built on sync.项目地址: https://gitcode.com/GitHub_Trending/el/electric