A green suite cannot certify a migration, because the runner connects too late

The mechanism deserves precision, because this is not a testing gap that better tests close. The migration process runs, exits, and only then does the test runner open its first connection ^[2]. Nothing that existed before that connection can be asserted on. So the claim that a fully green suite is compatible with destroyed production data ^[3] is arithmetic about ordering, not provocation.

The replacement gate on offer is a clone loaded with a representative slice and snapshotted three times: baseline, after up, after down ^[9], with a few thousand rows per table said to be enough to surface most destructive patterns ^[8]. The published bash script targets PostgreSQL through psql with ON_ERROR_STOP ^[15] and records three values per phase: table count from information_schema.tables, constraint count from pg_constraint, and the number of not-null attributes in pg_attribute ^[10]. That is nine numbers across the run ^[1], and none of them reads a row of application data ^[2].

Which matters, because the failure the author himself calls out as the hard one is precisely the one those nine numbers cannot see: a type change that converts values irreversibly, after which the down migration restores the declared type over corrupted contents ^[12]. The same blindness covers a column dropped by the up migration and re-created empty by the down: catalog counts come back level, values do not ^[2]. The checks that would catch this, per-table row counts, column null rates and duplicate detection, are described as what a production-grade version should also do ^[13]. As published, the harness is a structural diff carrying a data-integrity label.

The second problem is the oracle. The stated pass condition is not that the down migration runs cleanly but that schema and data return to baseline ^[11], which means the down migration is the reference the entire exercise is measured against. By the same piece's account, the down migration is the artifact that gets treated as an afterthought while the up migration absorbs the review ^[4]. The gate therefore inherits its authority from the least-inspected file in the changeset ^[3]. Writing and reviewing the reverse is the expensive work; running the script is the cheap part.

Disclosure from the source: the article was prepared as part of MonkeyCode's product outreach ^[14]. The recommendation is bash and psql, so the mechanism stands on its own regardless.

The volume argument is what makes any of this urgent: generation cost falls to zero, migration count rises, and each one adds surface for unreviewed data loss ^[5]. Staging will not absorb that, having different data, different volume and different usage patterns ^[6]. A clone-based dry run only becomes a gate when the snapshot diff includes row counts and null rates, and when someone other than the generator has read the down migration. Short of that, it is one more build step that goes green for the same reason the test suite does.