Skip to main content
Status: Findings only. No rewrites recommended without per-migration spec verification. Scope: All 892 files in supabase/migrations/, filtered to those containing DROP TABLE or DROP COLUMN statements outside SQL comments. Driver: .cursor/BUGBOT.md rule — “Dropping columns or tables: NOT OK. Prefer deprecation or a spec-approved multi-phase migration.”

​
Findings

10 migrations contain destructive DDL outside comments. Triage:

​
Recommendations

  1. No rewrites required from this audit. Most destructive statements are intentional schema-redesign migrations (V1→V2 permissions, HR redesign, GR field deprecation). Per .cursor/BUGBOT.md, these are acceptable when documented; absence of explicit spec links should be remedied by adding header comments referencing the originating ticket/spec.
  2. 20260311000823 lacks IF EXISTS on its DROP COLUMN. This breaks replay-from-empty-DB if for any reason the column is absent. Low priority because the migration is ~6 months old and presumably already applied everywhere it needs to go, but flag for any future “rebuild from migrations” exercise.
  3. Going forward, the .cursor/BUGBOT.md rule should be enforced by the BUGBOT pre-merge check rather than relying on review discipline. P1 of the broader hardening plan adds a pre-commit guard for migration filenames; consider adding a lint-migrations.ts extension that fails on DROP (TABLE|COLUMN) without an IF EXISTS guard and without a -- spec: … header comment.

​
Out of scope

  • The 150 other migrations containing DROP (mostly DROP POLICY, DROP TRIGGER, DROP FUNCTION, DROP INDEX) — those are routine and not destructive in the BUGBOT sense.
  • Post-squash drops embedded in 20260211182655_*.sql (the squash itself) — already deployed; not separately classified.