Disposable databases are not a toy

The expensive database habit

Most teams have exactly one shared non-production database, lovingly polluted by years of test runs, half-applied migrations, and rows named asdf. Everyone is a little afraid of it. Nobody resets it, because somebody's in-progress work is always in there. It is the worst of both worlds: too dirty to trust, too load-bearing to clean.

The fix is not a better shared database. It is making databases cheap enough that you stop sharing them.

How CapyDB handles them

A preview database starts empty or cloned from the current state of the project database, gets its own generated credentials, and exposes the same direct-and-pooled connection pattern as production — so the thing you test against behaves like the thing you ship against.

Every preview carries a TTL: 24 hours by default, 7 days maximum, extendable while it is alive. When the TTL expires, the worker deletes it. Cleanup is a property of the system, not a hope that a deletion hook fires or that someone remembers.

capydb preview create --mode clone --name pr-42 --ttl-hours 72 --wait
capydb psql --preview <preview-id>

Where they earn their keep

Pull requests. The GitHub Action creates an idempotent preview per PR and exports DATABASE_URL into the job. The Vercel and Netlify integrations go further: every git branch gets a clone-mode preview named after it, with branch-scoped env vars. Review apps get real data shapes instead of seed-file fiction.

Bug reproduction. Clone production's current state, reproduce the bug with real data, try the fix, throw the database away. No "can someone refresh staging?" in sight.

Restore inspection. This is the one people underestimate: a restore from a backup or a point-in-time lands in a fresh preview by default. "Is this the right backup?" becomes a question you answer by looking, not by overwriting production and finding out.

Trying something questionable on purpose. A destructive migration, a bulk update with a WHERE clause you are only 90% sure about — rehearse it on a clone. If the rehearsal turns out to be the state you want, a cutover can promote it to production, with a verified pre-cutover backup taken first.

Why this matters

Disposable infrastructure lowers the cost of curiosity. When a realistic database costs one command and cleans itself up, you test more, debug faster, and stop taking risks against the database you actually need to keep healthy.

The shared staging database does not need a cleanup rota. It needs to stop being the only option.