August 1, 2026
Clone Wars: Database Edition
Pgtestdb's template cloning approach to testing is fast
This database speed trick shocked devs, but the comments turned into a testing civil war
TLDR: pgtestdb showed that copying a prepared Postgres database for tests can be surprisingly fast, challenging the idea that full database setup is always slow. Commenters instantly turned it into a debate over even faster tricks, production realism, fake databases, and one gloriously chaotic “dirty db” approach.
A tiny Postgres testing trick just triggered big main-character energy in the developer comments. The idea is simple: instead of rebuilding a fresh test database every time, pgtestdb makes a super-fast copy of a prepared one. The surprise? It was way faster than people expected. Even the author admitted they had mentally filed “making whole new databases” under slow and annoying. In practice, setup landed around 100 milliseconds either way in this test, which is basically a blink.
But the real show started in the replies, where programmers immediately split into factions like it was a reality reunion episode. One camp yelled, essentially, “Cute, but put it on a ramdisk and go faster.” Another flexed hard: their company clears its database in 5 milliseconds and restores a production-like setup, with a very pointed jab that building from app definitions is what you do if you’re “not serious.” Ouch. Then came the speed demons saying the actual winner is wrapping tests in a transaction and rolling them back, because that cleanup is nearly instant.
And of course, there was a rebel faction asking whether any of this matters when you could just fake the database entirely. Meanwhile, one commenter casually dropped pure chaos: they run tests against a “dirty db” with no cleanup, just unique IDs and vibes. So yes, pgtestdb impressed people — but the community response was less “nice tool” and more full-blown testing philosophy cage match.
Key Points
- •The article evaluates pgtestdb, a Go/Postgres testing package that uses PostgreSQL template database cloning via `CREATE DATABASE ... TEMPLATE ...`.
- •The author compared pgtestdb with River’s existing schema-based test isolation approach by integrating it into River’s test suite.
- •Benchmark results showed both pgtestdb cloning and schema creation plus migration had similar setup times, around 100 ms.
- •River’s schema-based test suite still ran about 3.5x faster overall because it reuses pooled schemas instead of recreating them for each test.
- •The author plans to keep River’s current schema-based testing method but add a documentation recommendation for pgtestdb, especially for end-to-end testing use cases.