A Postgres you can allocate like an object, not provision like a server

What it does

PGX is a single-process Postgres-compatible database engine built for short-lived databases: agent sandboxes, CI runs, per-PR test databases. It speaks the Postgres wire protocol and SQL dialect, so Rails, Django, Prisma, SQLAlchemy and node-postgres run their full migrate → test → schema-change lifecycles unchanged. One runtime hosts hundreds or thousands of isolated databases, each created from a sealed template in milliseconds and dropped automatically a grace period after its last session.

The interesting bit

The core idea is “share everything immutable, pay for divergence.” Databases cloned from the same template share relation-cache entries and catalog state, so an idle database costs roughly 70 KB of memory. On ZFS, file_copy_method = clone turns database creation into block clones — a branch of a 10 GB template is ready in ~674 ms and starts at ~13.6 MB of its own storage.

Key highlights

• ~6.2 ms warm database mint (p50); 1,000 untouched idle databases fit in 128–155 MB total
• PostgreSQL’s own regression suite: 219/231 byte-exact against PG 18.6, 0 result differences (the 12 outliers differ only in EXPLAIN plan text)
• Isolation at every level: session/database/runtime memory limits (SQLSTATE 53200), per-database connection caps, and a Linux cgroup as the last line
• Framework lifecycles (Rails 8.1, Django 5.2, Prisma 6, SQLAlchemy 2, node-postgres) pass 36/36, within 0–15% of PostgreSQL 18
• No Docker required; runs natively on Mac and Linux, with a janitor that drops databases after their last session

Caveats

• Explicitly not for production data: the PGX profile runs with fsync = off, it’s one process (one crash domain), and there’s no HA or PITR
• No PostgreSQL C extensions — only built-in contrib modules (pgvector included); no PL/Python, PL/Perl or PL/Tcl
• Slower than real Postgres on queries: point SELECTs ~0.05–0.15 ms slower, large single-threaded scans 1.5–2.2× slower
• It’s v0.1.2 — early, with known limitations in the release notes

Verdict

If you run agents, CI, or preview environments and want a real Postgres per workload without the per-server overhead, this is worth a look. If you need a system of record, keep actual PostgreSQL — the README says so itself.