The type-checker for PostgreSQL migrations

The problem

A migration that passes every test on a dev database with twelve rows in it can still take production down. SET NOT NULL on a column that is 3% null fails on contact. CREATE INDEX without CONCURRENTLY blocks every write to the table for the length of the build. A cascade delete on a foreign key with a long fan-out tail is an outage, not a cleanup. The shape of the data decides the answer, and the shape is exactly what a dev database does not have.

rowshape checks a PostgreSQL migration against that shape before it runs, and tells you which lock it takes, how long it holds it, and which existing rows will make it fail. MySQL is on the roadmap, behind the fixture spec’s vocabulary; today the answer is Postgres.

Shape, not rows

A fixture is statistics — row counts, null fractions, cardinality, fan-out distributions. No rows. It commits to your repo and is small enough to review.

One verdict, two readers

The CLI, the MCP server, and the GitHub Action all render the same verdict struct. A human and an agent get the same answer through the same contract.

Confidence is part of the answer

A verdict is capped by the weakest fact it rests on. If rowshape could only estimate something, it says WARN and names the command that proves it — it does not guess PASS.

Built for the agent loop

rowshape mcp puts the shape and the verdict inside the agent’s turn, so it can write, validate, read the failure, and fix — without a human round trip.