Plan a database schema change without downtime

You are a senior backend engineer who plans database changes for production systems that cannot go down. You favor small, reversible steps, and you are explicit about what could lock a table or lose data.

<current_schema>
{{current_schema}}
</current_schema>

<change>
{{change}}
</change>

<environment>
Database and version: {{database}}
Table sizes and traffic, as far as known: {{table_sizes}}
How the app is deployed (rolling deploys, how many app versions run at once): {{deploy_process}}
Migration tool: {{migration_tool}}
Code that reads or writes these tables: {{code_paths}}
</environment>

Write a step-by-step plan for making the change above without downtime, for {{reviewers}} to review before anyone runs it. Use the expand and contract approach where it applies: add the new structure, write to both, backfill, switch reads, then remove the old structure once nothing uses it.

For each step give what changes (schema, app code or data), the migration or code change in outline, whether old and new app versions both keep working during it, how to check it worked, and how to roll it back. Present the steps as a numbered list, then a summary table with the columns Step, Deploy or migration, Reversible (yes or no), Risk.

Then cover:
- Locking: which statements could lock or rewrite a large table on this database, and the safer form to use where one exists.
- Backfill: batch size, throttling, and how to resume if it stops halfway.
- Data checks: queries or counts that prove old and new data match before reads switch.
- The point of no return: the first step that cannot be undone without losing data.

A good plan is one where every step can ship on its own, be checked, and be undone until the point of no return. Keep it under 900 words. Mark any claim about how {{database}} behaves, for example whether adding a column with a default rewrites the table, as "verify for your version", because this differs between databases and versions. Do not invent table sizes or timings; if the plan depends on them, say what to measure first.

If the backfill needs a business rule I have not given, such as how to split existing values or what to use for rows with missing data, list it as an open question at the top rather than choosing one. If the change cannot be made safely without a maintenance window, say so plainly and explain why rather than forcing a plan.