Branch a database per pull request without going bankrupt

We give every PR a branched Postgres with production-shaped data. The trick is copy-on-write at the storage layer plus aggressive_sleep: branches auto-sleep after 30 idle minutes, wake in ~800ms, and die with the PR. Storage cost per branch is roughly the diff, not the database.

Rules that keep it cheap: seed with a 2% sample plus all lookup tables (nobody needs 40M events to test a migration), block branches from production secrets (separate role, read-only seeds), and run migrations against the branch in CI before touching staging.

Biggest surprise: developers started testing migrations voluntarily once it took one click. The bottleneck was never discipline, it was friction.

This is the correct shape. Question: how do you stop a migration that passes on the 2% sample but dies on the full dataset? Lock timeouts and backfill duration are the usual killers.

Two gates. The branch runs the migration for correctness; a nightly job replays the week's migrations against a full restore and times them. Slow migrations get flagged before they ever meet production. Caught three this quarter.

Logpond-adjacent pain: our problem is not branches, it is seed realism. Sampled data never contains the one cursed row that breaks the index. Do you inject edge cases?

Yes, a "cursed rows" fixture pack: nulls where nulls should be impossible, emoji in latin1 columns, timestamps from 1970. Every branch seeds them. The cursed rows have caught more bugs than the sample.

Security corner: branch + production-shaped data means PII in N branches. How do you scrub?

Scrub at seed time, deterministically: same fake email per real user across branches so joins still work, plus a scanner that fails the branch if it finds anything matching production patterns. The scanner has false positives and we accept that.