Adding a new column is one of the most common schema changes in production databases. It sounds simple. It can be safe. It can also break queries, slow writes, or lock tables. The difference comes down to planning and execution.
First, define the purpose of the new column. Decide its data type, constraints, and default values. Avoid nulls unless they are intentional. A well-defined schema change starts here, not in the migration script.
Second, assess impact. On large datasets, adding a column may trigger a full table rewrite. In systems like PostgreSQL, a column with a constant default can be added instantly in newer versions. In MySQL, the same change might block writes for seconds or minutes, depending on the storage engine and index structure.
Third, stage the migration. Roll out the new column without immediate writes from application code. Backfill in small batches to avoid spikes in CPU, I/O, and replication lag. Monitor closely. Once the column is populated, switch the application to read and write it.