Show HN: PGlite – in-browser WASM Postgres with pgvector and live sync

Original Article ↗ Hacker News Discussion ↗

Overview and Main Use Cases

  • PGlite is a WASM build of PostgreSQL (~3MB) that runs in-browser and in Node/Bun, acting like an in‑process Postgres similar to how SQLite embeds.
  • Commonly cited uses: local/dev environments without Docker, quick onboarding (“npm install” gives you a working DB), integration tests, CI, offline‑capable or local‑first apps, and desktop/kiosk-style apps.

Persistence, Filesystems, and Environments

  • Browser-side persistence is via IndexedDB and OPFS; Node/Bun can use the normal filesystem.
  • IndexedDB is currently recommended for browser persistence due to incomplete OPFS support (e.g., Safari).
  • It can be configured per browser (e.g., detect OPFS availability and switch VFS).

Integration with Tooling and Other Languages

  • Works with Next.js and some ORMs (e.g., Drizzle); Prisma support currently requires a pg-compatible connector.
  • Supabase’s pg-gateway can expose PGlite over the Postgres wire protocol, allowing standard PG clients (including Go, etc.) to connect.
  • Strong interest in non-JS use. The roadmap includes:
    • A native “libpglite” C library.
    • A WASI build with a low-level API to be wrapped by language-specific clients.
  • Some ad‑hoc workarounds shown: calling Node from Python, using Pyodide proxies.

Performance, Size, and Architecture

  • Built on Postgres single‑user mode with added wire-protocol support; avoids multi-process/forking, which isn’t available in WASM.
  • Benchmarks (linked in thread) show WASM is slower than native but “very performant” for embedded use; VFS performance is critical.
  • Comparison with Redis is deemed not meaningful due to different database models.

Testing, CI, and Dev Workflows

  • Many see it as a strong alternative to Docker/testcontainers for Postgres in tests and CI.
  • Particularly attractive for projects that currently fake Postgres with SQLite for testing.
  • Some prefer fully local stacks over shared dev databases; others argue shared DBs can be useful but acknowledge pollution and reproducibility issues.

Comparison to SQLite and Other DBs

  • Positioned as “like SQLite, but Postgres”: full PG types (arrays, JSONB), extensions (e.g., pgvector; PostGIS planned), and live query API.
  • SQLite is seen as more mature and lighter, but PGlite offers richer type/extensibility.
  • Some desire head‑to‑head comparisons vs SQLite and DuckDB; existing benchmarks linked but not deeply debated.

Limitations, Bugs, and Open Questions

  • Reported issues: a REPL bug in full-text search, a “memory access out of bounds” in early experimentation, and sparse migration/tooling docs (e.g., Vite/webpack).
  • Production-readiness is questioned by some; others already use it in CI/dev.
  • Questions raised about:
    • License implications for commercial use (not fully answered).
    • At-rest encryption (considered feasible via extensions or encrypted VFS).
    • Data scale limits (e.g., 1TB local) — performance and practicality remain unclear.

ElectricSQL and Sync / Live Queries

  • PGlite is developed alongside ElectricSQL and is intended as a client store/sync target, supporting partial replication and local‑first patterns.
  • Live queries work with joins/aggregations by materializing queries as views and tracking table dependencies; future integration with pg_ivm is planned for more efficient incremental maintenance.