Adding a new column sounds simple. In practice, it can bring down production if done wrong. Schema migrations rewrite storage layouts. Locking tables during heavy load stalls applications. Missing defaults or null handling can break queries. A careless change can cascade into outages.
A new column should start with a clear definition. Pick the smallest and most efficient data type that fits the requirement. Decide on nullability. If the column should have a default, set it in the migration itself. Avoid using UPDATE on the entire table in a single transaction when backfilling values. Instead, batch updates in small commits to reduce lock contention.
For large datasets, online schema change tools like pt-online-schema-change or native database features can add a column without blocking reads and writes. In PostgreSQL, adding a nullable column without a default is an instant metadata-only change, but adding a default rewrites the table. In MySQL, certain changes are fast in recent versions, but older versions require full table copies. Know your engine’s behavior before you run the migration.