Check a migration before it locks a table
Paste the SQL you are about to run. You get the exact lock-safety and Row Level Security findings our migration runner enforces on every Scribase project — which statements block reads or writes, which ones ship a table with RLS off, and the fix for each.
Make this unskippable
On Scribase, every migration runs through this same lint before it applies — an unsafe migration is refused, not merely flagged. $25 a month flat, Supabase-compatible.
Questions people ask
Does this run my migration against a real database?
No. It parses the statements and checks them against the same rules the migration runner enforces before anything executes — no connection, no schema, nothing stored.
Why does a plain ALTER COLUMN ... TYPE lock the table?
Changing most column types forces Postgres to rewrite every existing row to validate it fits the new type, holding an ACCESS EXCLUSIVE lock (blocks reads and writes) for the whole rewrite.
Why does CREATE INDEX need CONCURRENTLY?
A plain CREATE INDEX takes a SHARE lock for the whole build — reads still work, every INSERT/UPDATE/DELETE blocks until it finishes. CONCURRENTLY avoids that at the cost of needing to run outside a transaction.
What counts as "RLS off"?
A table created without ROW LEVEL SECURITY enabled, or a policy missing WITH CHECK on an insert/update path — both are how a Supabase project most commonly leaks data.