pgmem

One test suite, two execution models

A small shop’s data layer with 70 tests: 50 that only read, 20 that write. On a shared PostgreSQL server, here one started with Testcontainers, the writing tests have to wait for each other, each behind a reset of the shared data. With pgmem the suite takes one snapshot after the migrations and seed data; the read-only tests share that database and every writing test forks its own copy, so everything after the snapshot runs in parallel.

The same 70 tests (50 read-only, 20 writing) on the same schema, migrations and seed data, run with go test at parallelism 8. Each timeline is the run whose total was the median of 5 runs on Apple M3 (8 cores). Bars are the nodes of each execution model; lower and to the left is faster.

Whole suite, wall clock

• pgmem204 ms
  196 ms–219 ms over 5 runs
• Testcontainers, one shared server1.73 s
  1.70 s–1.81 s over 5 runs
• PostgreSQL, one shared server646 ms
  633 ms–671 ms over 5 runs
• docker run, one shared server2.48 s
  2.26 s–3.59 s over 5 runs

Tests are drawn in the 8 slots of go test -parallel; a slot shows the tests that ran in it one after another. All timelines share one time axis.

• Boot database
• Import schema + seed master data
• Snapshot
• Fork (a writing test's own copy)
• Input sample data
• Reset data
• Test that queries data
• Test that modifies a table

pgmem 204 ms totalin the test process; read tests share the template, each writing test forks the snapshot, all in parallel20 forks, one per writing test (20); the 50 read tests use the template database without a fork.

Testcontainers, one shared server 1.73 s totaltestcontainers-go postgres module on the official image, in memory (tmpfs, no fsync); writing tests take turns after a resetno copies: the 50 read tests and the 20 writing tests share one database.

The suite, the harness and every node’s timing are described on the benchmarks page; the project is in bench/modelcase.

The real thing

PostgreSQL 18.3 compiled to WebAssembly and translated to Go. Your SQL, planner behaviour and error codes are PostgreSQL’s, not an emulator’s.

Nothing to install

Install the library and its platform binary. No Docker daemon, no container runtime on CI, no database files written to disk.

Share reads, isolate writes

Run migrations and seed data once, then share a fork across read-only tests and give writing tests isolated copies. Writing tests can run in parallel.

Any driver

pgmem listens on the PostgreSQL wire protocol, so pgx, psycopg, JDBC, node-postgres, ORMs and migration tools work unchanged.

Five lines to a database

Go

s, err := pgmem.Start(ctx, pgmem.Options{Database: "app"})
if err != nil {
  t.Fatal(err)
}
defer s.Close()
db, _ := sql.Open("pgx", s.DSN())

Python

import pgmem, psycopg

with pgmem.start(database="app") as pg:
    with psycopg.connect(pg.template.dsn) as conn:
        conn.execute("SELECT 1")

Java

try (Pgmem pg = Pgmem.builder().database("app").start();
     Connection conn = DriverManager.getConnection(pg.template().jdbcUrl())) {
    conn.createStatement().execute("SELECT 1");
}

Node.js

import { PgmemServer } from '@pgmem/core';
import pg from 'pg';

const server = await PgmemServer.start({ database: 'app' });
try {
  const pool = new pg.Pool({ connectionString: server.url });
  try { await pool.query('SELECT 1'); }
  finally { await pool.end(); }
} finally { await server.close(); }

Compared with the usual options

The same schema, queries and per-test isolation, measured on one machine against the official image with docker run, Testcontainers, and a devbox-installed PostgreSQL.

pgmem values are medians from 5 runs on 2026-09-18; the Docker, Testcontainers and devbox comparison baselines are from 2026-09-14. Docker and Testcontainers memory uses 3 fresh OrbStack runs. Bars scale to the largest value in each card; lower is better.

Start to first query

From command start to TCP SELECT 1; downloads are excluded and Devbox uses an initialized cluster.

• pgmem · Go library70 ms
• Docker · PostgreSQL 181.65 s
• Testcontainers · Go1.09 s
• devbox · services up411 ms

Fresh copy per test

Median time to create an isolated database copy and run a join.

• pgmem · Go library15 ms
• Docker · PostgreSQL 1861 ms
• Testcontainers · Go21 ms
• devbox · services up83 ms

Indexed SELECT

Warm indexed SELECT over TCP.

• pgmem · Go library29 µs
• Docker · PostgreSQL 1893 µs
• Testcontainers · Go102 µs
• devbox · services up28 µs

Sort 200k rows

Median time to sort and count 200k rows.

• pgmem · Go library117 ms
• Docker · PostgreSQL 18259 ms
• Testcontainers · Go258 ms
• devbox · services up228 ms

Backend + test-process memory

After setup, before queries. Docker and Testcontainers sum container usage (PostgreSQL, plus Ryuk for Testcontainers) and benchmark-process growth. OrbStack VM changes are reported separately.

• pgmem · Go library103 MiB
• Docker · PostgreSQL 1877 MiB
• Testcontainers · Go137 MiB
• devbox · services up36 MiB

Initial download footprint

Same MB scale; Go link growth, compressed image layers, and devbox cache download measure different things.

• pgmem · Go library33.1 MB
• Docker · PostgreSQL 18117.9 MB
• Testcontainers · Go120.0 MB
• devbox · services up112.7 MB

The current stripped darwin/arm64 pgmem binary is 36.7 MB, including the export-pruned AOT backend. The benchmark page records the latest pgmem-only rerun and keeps the comparison baselines reproducible.

Query latency, methodology and how to reproduce are on the benchmarks page.