The query ran for hours before anyone noticed the missing field. Adding a new column should be the fastest fix in the book. Too often, it becomes a slow-motion disaster. Schema changes lock tables. Migrations block deploys. Users feel the lag before you even hit merge.
A new column in a relational database is not just metadata. On large datasets, it can rewrite entire storage blocks. That means higher I/O, potential downtime, and operational risk. On production systems with billions of rows, an ALTER TABLE ADD COLUMN can turn into a major incident.
Plan the change. Confirm if the column has a default value. Adding a non-nullable column with a default can backfill data row by row, making the operation expensive. When possible, add nullable columns first. Update values in batches. Then enforce constraints later.
Use online schema change tools. For MySQL, consider gh-ost or pt-online-schema-change. For Postgres, some column additions are instant if they meet certain conditions—like adding a nullable column without a default. Always test on a snapshot of production data to predict the migration time.