The database waits, empty in one place, and the need for a new column is urgent.
Adding a new column sounds simple. In production, it can be dangerous. Schema changes under load can lock tables, drop queries, and stall the system. Without planning, a migration can turn a minor change into an outage.
The first step is knowing why the column exists. Define its type, nullability, default values, and expected growth. Every decision here impacts performance and storage. Use explicit types. Avoid guesswork.
For relational databases, ALTER TABLE ADD COLUMN is the common path. Under the hood, this can be instant or blocking depending on the engine. PostgreSQL can add nullable columns with defaults instantly in newer versions. MySQL often still requires a table rebuild for certain changes. If the table is large, test the effect on a staging copy that matches production size.
When the new column needs a default value but downtime is unacceptable, split the deployment. First, add the column without the default and allow it to be null. Then backfill data in small batches. Finally, set the default for new rows. This avoids heavy write locks.