Adding a new column should be quick, safe, and predictable. Done wrong, it can lock tables, stall queries, and break production. Done right, it expands your schema with zero downtime and zero drama. The difference comes down to method, tooling, and discipline.
A new column changes the shape of your data. Before you run ALTER TABLE, you must know the table size, index impact, and replication lag. In large datasets, a blocking ALTER can halt writes and freeze reads. Use an online schema change tool like pt-online-schema-change or gh-ost to avoid downtime. They copy the table in the background, apply changes incrementally, and swap in the new structure with a final instant rename.
Default values and nullability matter. Adding a non-null column with a default can rewrite every row, triggering massive I/O. For safer migrations, add the column as nullable first, backfill in batches, then enforce constraints in a later migration. This makes your rollout safe in live environments.