Find out what your migration locks before production does

Paste the migration — raw SQL, a Django migration, a Kysely or Drizzle file, a golang-migrate pair, a Prisma migration.sql. You get every statement with the lock it takes, a safe / caution / block verdict against your table size and your downtime budget, the findings with corrected SQL, an expand-contract rollout with the deploy gates between steps, the migration rewritten safely, and the queries that prove it landed.

Both examples ship with a saved model run, so you can see the whole audit — including the rewritten migration — without signing in and without spending a credit.

Your migration nothing pasted yet

Drag your migration files in, or Everything is read in your browser. Nothing uploads until you run.

Database

Largest table this touches

Downtime budget

Context — optional, but it changes the ordering

Paste a migration to price the run.

verdict

dialect

tool

largest table

findings

critical + high

Statement by statement

Ref	Operation	Lock	Blocks	Cost	Verdict	Note

The Ref column is your browser's own numbering of the statements it split out of the paste, so a row here and a finding below always point at the same SQL.

Checks

Check	Status	Evidence	Requirement

Findings

The migration, rewritten

This block is a rewrite of the text you pasted, not a tested migration. It was re-analysed by the same prescan that read your original — the line above says what that analysis found in it — and it still has to be run against a copy of production-sized data before it goes near the real thing.

Verify

Read every line before running it. Nothing here is executed by this page.

Prescan reconciliation

Quick wins

Focus areas

Summary

Raw model reply

The reply did not parse as the structured audit, so it is shown as it arrived.

What this does, and what it does not

The prescan is a real statement splitter, not a keyword search. It walks the paste character by character, so a semicolon inside a string literal, inside a $$ … $$ function body or inside a comment is not mistaken for a statement boundary — which matters immediately, because the batched-backfill loop the good version of this migration uses is one statement containing several. Each statement is then classified by the lock PostgreSQL or MySQL actually takes for it, and every flag it raises is handed to the model as a fact it must reconcile one by one. If the audit skips a flag, this page says so.

The check that matters most runs after the answer arrives: the rewritten migration is fed back through the same analyzer, so “this rewrite is safe” is something the page verifies rather than repeats. A rewrite that still contains a plain CREATE INDEX is reported as such, above the block, before you copy it.

It reads; it does not connect to your database, it never runs anything, and it cannot see your row counts, your index bloat or your replication lag — which is why the form asks how big the table is and why the verification queries exist. This is a review of pasted text, not a rehearsal on production-sized data, and it is not a substitute for one.

Nothing to hand? Load the , a four-statement golang-migrate file that adds a NOT NULL column, builds an index and backfills 40M rows in one transaction, or the , an expand-phase migration that is mostly right and wants a second opinion. Both replay a saved run for free.

Find out what your migration locks before production does

Instant prescan — free, in your browser, no model

Assumptions and open questions