Database Changes — Runbook (backup first)

Standing rule: never run a data- or schema-changing statement against the live Supabase database (import, migration, update, delete, policy change, alter table) without taking a backup first and verifying the result after.

Every SQL change follows this shape: backup → change → verify → keep the backup until confirmed, then drop it.

1 · Backup (same-database snapshot — instant, no tools)

Replace <table> and use today's date in the copy name:

create table if not exists public.<table>_backup_YYYYMMDD as
  select * from public.<table>;

select count(*) from public.<table>_backup_YYYYMMDD;   -- confirm the copy

For the important tables, also take an off-database copy: Table Editor → open the table → ••• → Export to CSV.

2 · Restore (if the change goes wrong)

-- Option A: put the rows back (id / unique conflicts are skipped)
insert into public.<table>
  select * from public.<table>_backup_YYYYMMDD
  on conflict do nothing;

-- Option B: full swap back to the snapshot
alter table public.<table>                 rename to <table>_broken;
alter table public.<table>_backup_YYYYMMDD rename to <table>;

3 · Clean up (only after the change is confirmed good)

drop table if exists public.<table>_backup_YYYYMMDD;

In-app rollback (Waitlist dashboard)

Beyond database backups, the Founders' Waitlist dashboard has a built-in undo: every Add, Edit and Delete asks for confirmation, then shows an "Undo" bar for a few seconds that rolls the action back (re-inserts a deleted row, restores previous values on an edit, or removes a just-added row). Database backups remain the durable safety net; the in-app undo is for quick corrections.

Notes

• Snapshots copy rows only — not indexes, constraints, RLS policies or triggers. For a data change that's all you need; for a risky schema change, also note the table's policies (select * from pg_policies where tablename = '<table>';) so they can be recreated.
• Keep backup tables short-lived; they are not RLS-protected, so drop them once done.