A new column changes the shape of a table. It sounds simple, but in production systems it can be the most dangerous kind of change. Every query, index, view, and downstream job that touches that table might break. Every migration can lock the database, block writes, or cause silent data errors.
The process starts with clarity. Define the exact name, data type, and nullability of the new column. Check for defaults. Decide whether it will store computed values or raw inputs. Audit all dependent code: ORM models, ETL scripts, APIs, and dashboards. Document every reference path before writing a single migration file.
When you run the migration, choose the right strategy for your database. In PostgreSQL, an ADD COLUMN for a nullable field is fast, but adding a non-null column with a default will rewrite the entire table. In MySQL, certain column types will lock the table unless you use online DDL. For large datasets, consider backfilling in small batches to avoid downtime.