supabase-migrationslisted

# Supabase migrations Self-hosted Supabase fails differently from managed Supabase. The failures are quiet: the migration succeeds, the API returns an empty array, and nothing anywhere reports an error. This skill is the checklist that catches those before they ship. ## When to use this Writing a migration, reviewing one, or debugging "the table exists but the API says it does not". ## The order that matters 1. **Take the next free number.** Never reuse one, never renumber an applied migration. ```bash ls migrations/ | sort -V | tail -1 ``` 2. **Write the DDL idempotently.** `create table if not exists`, `add column if not exists`, `drop policy if exists` before `create policy`. A migration that cannot be run twice will eventually be run twice. 3. **Grant, then policy, then enable.** Row Level Security without a grant returns permission-denied; a grant without RLS exposes every row. Both, in that order. 4. **End with the schema reload.** ```sql notify pgrst, 'reload schema'; ``` This is the one that gets forgotten. PostgREST caches the schema at boot. Without this line the table exists in Postgres and does not exist over the API, and every symptom points at your client code. 5. **Verify against the database, not against the file.** ```bash bash scripts/verify.sh <table_name> ``` ## Template ```sql -- 00NN_<what_it_does>.sql -- <one line: why this exists> create table if not exists public.thing ( id uuid p