The migration was supposed to be simple. Just add a new column. But every database engineer knows this is where small decisions can create years of technical debt.
Adding a new column in production is never just a schema change. It affects query plans, indexes, replication, backups, and application code paths. Get it wrong, and you risk downtime, data inconsistency, or silent failures that surface months later.
First, define the purpose of the column with precision. Is it nullable? Will it hold default values? Does it require constraints? Avoid implicit defaults without understanding their impact on row storage and performance. In PostgreSQL, for example, adding a column with a default value rewrites the entire table unless you use a newer version that makes it a metadata-only change.
Next, consider how the new column changes your indexes. Adding it to an existing index can slow down inserts and updates. Creating a brand-new index should be weighed against the read/write patterns of your workload. In MySQL or MariaDB, a blocking ALTER TABLE can lock large tables, so online schema change tools may be necessary.