Supabase
Releases
Security & compliance
Stability
Performance
Migration & schema safety
The migration that locks the table or loses the column.
Overview
Reads the SQL in your migrations directory for operations that are destructive, irreversible, or blocking under load, and reports what each one would do to a table with production data in it.
What it looks for
- DROP statements with no rollback path
- Column type changes that silently truncate existing values
- CREATE INDEX without CONCURRENTLY
- RLS enabled on a table with no policy created, locking the app out
- Postgres extensions enabled without review
Why it matters
CREATE INDEX without CONCURRENTLY takes a write lock for the length of the build, which on a large table is a deploy-time outage. A dropped column with no rollback path cannot be recovered from the migration that removed it.
Rules in this check
| What it reports | Fix path |
|---|---|
| Migration drops a table or column with no rollback path | Pull request |
| RLS enabled on a table but no CREATE POLICY found — app rows locked out | Pull request |
| Column type change may silently truncate data | Guide |
| CREATE INDEX on a table without CONCURRENTLY — locks writes during deploy | Pull request |
| Postgres extension enabled without review | Guide |
How the fixes arrive
Pull requestLow-risk changes arrive as a pull request on a lumioguard branch, with a breakage analysis attached. You review and merge it.
GuideChanges only you can make safely arrive as a step-by-step guide you can follow yourself or hand to your coding agent.
Run them all on your app
Connect your repo and your live services with read-only scopes. The first scan is free, and nothing changes without your approval.