Claude Templates / C-tier · Discipline

Discipline

The Supabase Migration Playbook

Migration discipline — numbering, guards, application, and the never-destructive rule.

SUPABASE-MIGRATION-PLAYBOOK.md · 14 sections · 1,767 words · 14 KB · markdown

How to change a production schema without losing data. Sequential numbering, IF NOT EXISTS guards so a re-run is a no-op, applying via the Management API, tracking what's actually been applied, and the hard rule that sync routines never delete.

What's inside

When to use it

Every migration. Every time.

Build these first

App Infrastructure

Straight from the file

Every migration must be safe to re-apply against a DB where it has already run. Real-world reason: applied-state tracking drifts; you WILL re-run a migration by accident; the migration must no-op gracefully instead of crashing.

Table of contents

  1. 0. Use this spec
  2. 1. File naming convention (load-bearing)
  3. 2. Idempotency is mandatory
  4. 3. Application: how to actually run a migration
  5. 4. Applied-migration tracking
  6. Applied
  7. Pending (in repo, not yet live)
  8. Skipped (intentionally not applied)
  9. 5. RLS hygiene — non-negotiable
  10. 6. Never destructive on user-owned data
  11. 7. Schema patterns that age well
  12. 8. Approval + backup workflow
  13. 9. Common pitfalls
  14. 10. Kickoff prompt

How to run it

Drop SUPABASE-MIGRATION-PLAYBOOK.md into your repo, then tell Claude Code: “Read SUPABASE-MIGRATION-PLAYBOOK.md and implement it in this codebase.” It's written for an agent to execute end to end. Search the file for angle-bracket placeholders and swap in your own project names, domains, and keys before the first run.

↓ Download the playbook

More discipline playbooks

← All 28 Claude templates