agentleFS
matthullmatthull/my-skills/skills/technical/supabase-migrations/SKILL.md

supabase-migrations

Skill0 starsChanged 55 days agoMITView on GitHub

Guidance for writing Supabase database migrations with idempotent patterns. This skill should be used when creating or modifying database objects (tables, functions, RLS policies, triggers, indexes) or any SQL committed as a migration file.

We split this skill into the rules it gives an agent

3 rules. About 0 are common, 1 is distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Critical rule: Never edit a migration that has already run in any environment.

    line 16
  2. Very specific:

    Modifying existing function?: Use CREATE OR REPLACE in a new migration file

    line 90
  3. Very specific:

    Adding index?: Use CREATE INDEX CONCURRENTLY in its own separate migration file (one index per file)

    line 91

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Supabase Migrations

Supabase uses timestamped SQL migrations in supabase/migrations/. Migrations run once, in order, and cannot be rolled back. This requires idempotent patterns.

Key Constraints

  1. No rollback - Migrations only go forward
  2. No repeatable migrations - Cannot re-run modified files (unlike Flyway's R__ prefix)
  3. No checksum validation - System won't detect edits to already-run migrations

Critical rule: Never edit a migration that has already run in any environment. Create a new migration instead.

Pattern Selection

Object TypePatternRationale
TablesCREATE TABLEOne-time DDL, never modified after creation
FunctionsCREATE OR REPLACE FUNCTIONIdempotent, can be updated in new migrations
RLS PoliciesDROP POLICY IF EXISTS + CREATE POLICYPolicies cannot be replaced, must drop first
TriggersDROP TRIGGER IF EXISTS + CREATE TRIGGERSame as policies
IndexesCREATE INDEX CONCURRENTLY IF NOT EXISTSNon-blocking, separate file per index

Workflow

# Create new migration
npx supabase migration new <name>

# Apply locally (drops everything, runs all migrations + seed)
npx supabase db reset

# Apply pending only (preserves data)
npx supabase db push

# Check status
npx supabase migration list

Command Timeouts

CRITICAL: Supabase commands can be slow. Using insufficient timeouts causes SIGKILL (exit code 137) which looks like a failure but is just a timeout.

CommandMinimum TimeoutNotes
supabase db reset120s (2 min)Drops DB, runs all migrations, restarts containers
supabase db push60sOnly applies pending migrations
supabase migration list30sQuick status check
supabase status30sQuick status check

When using Bash tool, always set appropriate timeout:

timeout: 120000  # for db reset (milliseconds)

Interpreting Output

Success indicators (look for these, not just exit code):

  • "Applying migration XXXXXX_name.sql..." for each migration
  • "Finished supabase db reset on branch main."

Warnings (not errors):

  • WARN: no files matched pattern: supabase/seed.sql - Fine if no seed data yet

Actual errors:

  • SQL syntax errors will show the failing statement
  • "ERROR: relation X already exists" - Table collision
  • "ERROR: column X does not exist" - Schema mismatch

Naming Convention

YYYYMMDDHHMMSS_<action>_<object>.sql

Examples:

  • 20251215100000_create_widgets.sql
  • 20251215100001_add_rls_policies.sql
  • 20251220100000_update_auth_hook_v2.sql

Checklist Before Completing Migration

  1. New table, and this project uses PowerSync for offline/mobile sync? Add it to the sync publication: ALTER PUBLICATION <sync_publication> ADD TABLE new_table;
  2. SECURITY DEFINER / privileged function? Grant and revoke EXECUTE explicitly
  3. RLS on table? Both ENABLE ROW LEVEL SECURITY and FORCE ROW LEVEL SECURITY required
  4. Modifying existing function? Use CREATE OR REPLACE in a new migration file
  5. Adding index? Use CREATE INDEX CONCURRENTLY in its own separate migration file (one index per file)

Detailed Patterns

For structural examples, read references/patterns.md in this skill directory.

Note: Examples show idempotent structure, not business logic. Actual SQL implementation should come from your feature specs and research docs.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.