Adding a new column to a production database is not just a schema change. It is a contract update with every part of your system. The database migration must be atomic and reversible. Queries need to handle both the old and new states during rollout. Code that writes to the new column should not assume its presence until the migration completes on all environments.
Start by defining the column with the exact type and constraints you need. Avoid nullable types unless you plan for their meaning. If the column will hold indexed data, create the index in a separate migration to reduce lock time. For large tables, use tools like pt-online-schema-change or online DDL features in your database to avoid blocking writes.
Deploy migrations before the code that depends on the new field. Read paths should remain compatible with missing data until you fully backfill. For big backfills, batch updates in transactions to avoid load spikes. Track progress, and only cut over when completeness is confirmed.