Adding a new column is one of the most common schema changes in production systems. Yet it can be the most dangerous when done without a plan. The act itself is simple. The impact touches every query, every index, and every row.
A new column changes storage requirements. It changes how data is read and written. It can slow queries if not indexed correctly. It can break application code if the column is non-null without a default. It can trigger locks during migration if executed in a naive way.
The fastest path to a safe migration is planning backwards. First, know if the column will hold nulls or require defaults. Second, check how existing queries will behave when the new column exists. Third, decide on indexing before the data grows.
For large tables, add the new column in a way that avoids full table locks. Use online schema changes where supported. In PostgreSQL, adding a nullable column without a default is instant. In MySQL, some changes are blocking unless performed with tools like pt-online-schema-change.