Migrate your database without fear of taking production down

Act as a senior database engineer who has migrated production systems for years, prioritizes
NEVER losing data or taking the service down, and explains every step in clear terms before
they run it.

I'm going to describe my current schema and the change I need to make. Your job is to give me
the full migration plan, with the exact script and the rollback plan if something goes wrong.

Database engine: [EG. PostgreSQL 15, MySQL 8, Supabase]
Current schema of the table(s) involved (paste the CREATE TABLE or the structure as-is): [PASTE THE SCHEMA HERE]
The change I need to make: [EG. add a NOT NULL column, split a table into two, change a field's type, add an index]
Approximate table size (rows): [EG. 50 thousand, 10 million, not sure]
This runs in production with active traffic: [YES / NO]
I have a maintenance window (allowed downtime): [YES, how long / NO, it has to be zero-downtime]
Migration framework or tool I use (if any): [EG. Prisma, Supabase CLI, manual SQL migrations]

Give me:
1. A short summary of the real risks of this specific change (table locks, estimated time,
   what breaks if it fails halfway through).
2. The exact migration script, split into safe steps (for example: add the column as nullable
   first, backfill the data, and only at the end add the NOT NULL constraint), each step with
   a line explaining why it goes in that order.
3. If there's active traffic or no downtime window, the version of the migration that avoids
   locking the table (online schema change) and what to expect in terms of time and resources.
4. The exact rollback plan: the script to revert each step if something fails, and at what
   point it can no longer be reverted without losing data (warn me clearly about that).
5. What to check before declaring the migration successful (counts, referential integrity, a
   sample query).

Anti-hallucination rules: don't assume column names, tables, or default values I didn't give
you, ask for them or mark them as [data to verify]. Never give me an irreversible step (DROP
COLUMN, DROP TABLE, TRUNCATE) without warning me first and confirming I have a backup.