Test schema changes at the scale your users depend on.
See how a migration behaves on realistic Postgres data.
Measure locks, blocked sessions, table rewrites, and query plan changes.
Review the findings before merging your pull request.
Large tables plus frequent schema change.
Large tables. Exclusive locks and rewrites that never show up on a laptop database.
Query plans. Plan regressions under production-shaped volume.
- pid 1842ALTER subscriptionsACCESS EXCLUSIVEholds 27.4s
- pid 2210SELECT eventsACCESS SHAREwaiting · p99 6.9s
27.4s hold · events p99 820ms → 6.9s
Inspect the database behind your application.
Measure the migration. Run each pending statement against a masked database branch and record its impact.
Postgres first. Check query plans and lock duration at realistic row counts.
Review test coverage. See which parts of your stack ran and which checks need more setup.
- 01Expand
- col
- access_tier
- null
- yes
- default
- none
- 02Backfill
- batch
- 12k / pass
- dual-read
- on
- pool
- live
- 03Contract
- constraint
- last
- old path
- kept
- safe
- not yet
Publish what the twin reproduced. Do not pretend unsupported components are cloned.
Locks, plans, and release compatibility before deployment.
Lock duration. The strongest mode held per table, how long it was held, and whether another session waited on it.
Schema coexistence. Whether old instances can still read the new schema shows up here first.
Users notice p99 immediately. Large tables plus frequent schema change.
- peak hold
- 27.4s
- events p99
- 820ms → 6.9s
- waiter
- waiting
Another session was left waiting. events p99 moved 820ms → 6.9s.
Bring your next pull request.
See how Antifailure would test your stack, what it would check, and the evidence your team would review before merging.