The query hit the database like a hammer, but the result needed something more: a new column.
Adding a new column is one of the most common schema changes, but it can also be one of the most dangerous if done poorly. In production, the cost of an ALTER TABLE can cascade through indexes, replication, and live queries. The wrong move freezes connections, balloons I/O, and leaves you rolling back in panic. The right move keeps uptime high and deployments smooth.
When you add a new column, start with intent. Define the column name, type, nullability, and default values with precision. Avoid defaults that require backfilling every row during the migration. For large datasets, this can mean seconds or minutes of locked writes. Instead, create the column as nullable, deploy, then backfill in small batches. After the data is populated, add constraints and defaults in a follow-up migration.
Know how your database engine handles schema changes. MySQL with InnoDB and PostgreSQL differ in performance impacts and lock behavior. Use online DDL tools or native features like PostgreSQL’s ADD COLUMN without rewrite where possible. Keep migrations in source control and tie them to application code changes to maintain integrity between schema and logic.