PGlite – Embeddable Postgres

Original Article ↗ Hacker News Discussion ↗

Use cases and current adoption

  • Widely used for local development and tooling: embedded by major CLIs to emulate server products, and popular for spinning up realistic Postgres environments without Docker.
  • Many commenters use it for unit/integration tests:
    • Replace SQLite or Dockerized Postgres to get behavior identical to production.
    • Faster CI: in‑memory DB, quick schema loading, database cloning/checkpoints, and transactional rollback between tests.
  • Used in production browser apps and SPAs to store large per‑user datasets locally and persist them to disk.
  • Also used for interactive prototypes and user research where a “real” relational backend in the browser improves realism.

Comparison to SQLite, DuckDB, IndexedDB

  • Some see it as a Postgres-flavored alternative to SQLite/DuckDB, especially when production already uses Postgres.
  • Advantages over SQLite mentioned:
    • Richer SQL features and a nicer experience for hand‑written SQL.
    • Stricter typing and closer parity with production Postgres, catching bugs SQLite might miss.
  • IndexedDB is criticized as slow, awkward, and crash‑prone; PGlite offers the Postgres feature set and better query ergonomics.

Architecture, limitations, and extensions

  • Based on compiling real Postgres C sources to WebAssembly with JS/TS wrappers.
  • Currently single-connection only; multi-connection support is planned.
  • Supports a catalog of extensions; PostGIS is under active work, TimescaleDB may be possible but isn’t prebuilt.
  • Can be used via WASM runtimes in other languages; third‑party Rust bindings exist.

Native library and non-JS interest

  • Strong interest in a native “libpglite” with C FFI for direct embedding in Go, .NET, C/C++, Python, etc.
  • A separate native-library effort exists but progresses slowly due to limited bandwidth.
  • Some find WASM‑only too niche or an unnecessary layer when the core is already C.

Performance, size, and trade‑offs

  • Benchmarks on the site look good, and several users report significantly faster tests versus containers.
  • Others report PGlite as heavy for certain browser/P2P scenarios and prefer smaller SQLite WASM builds.
  • Concerns raised about memory usage, startup times, and slower inserts/lookups compared to SQLite; performance parity is seen as uncertain.
  • 3MB runtime size is noted as large for browser use; some wish this capability were built into browsers.