Apply SQL Manually

An approved migration is committed before it is run against a hosted database. Compute its checksum from the committed file so an operator can confirm that the selected SQL matches the reviewed artifact.

shasum -a 256 supabase/migrations/YYYYMMDDHHMMSS_description.sql

• Confirm the intended hosted Supabase project and environment alias immediately before running SQL.
• Ensure no other migration application is in progress for that environment.
• Paste and execute the exact committed migration in Supabase SQL Editor.
• Run post-apply inspection queries and behavior tests supplied with the migration.
• Never treat an owner/admin SQL Editor query as proof of ordinary user RLS behavior.

After successful verification, create a Git-tracked record under supabase/deployments/<environment>/. If execution failed and might have left partial effects, record that result too before corrective work.

# Migration Deployment Record

Environment alias: production
Migration file: supabase/migrations/YYYYMMDDHHMMSS_create_documents.sql
Migration Git revision: <commit SHA>
Migration SHA-256: <checksum>
Applied by: <operator>
Applied at (UTC): <YYYY-MM-DDTHH:MM:SSZ>
Execution method: Supabase SQL Editor (manual)
Result: applied | failed-partial | corrected
Pre-apply checks completed: <checks and result>
Post-apply verification completed: <checks and result>
Authorization/API-path tests completed: <actor tests and result>
Observed deviations or follow-up migration: none | <details>

Use a separate hosted Supabase staging project before production for RLS or grant changes, functions/views exposed to clients, Storage or Auth behavior, Realtime behavior, data backfills, destructive changes, constraints on populated tables, or indexes on actively written tables. This preserves the manual SQL Editor workflow without requiring a local database stack.