It seemed simple. One ALTER TABLE, and you were done. But columns are never just columns. They change indexes, query plans, and even how transactions lock. A careless migration can block writes for minutes or hours, bringing production to a standstill.
A new column must be designed and deployed with intent. Define its data type to match the smallest required size. Avoid nullable columns unless they are truly optional; they can complicate query optimization. If the column will be indexed, consider its position in the schema to avoid bloating the index size.
In PostgreSQL, adding a column with a default value forces a table rewrite in older versions. In MySQL, it can affect storage layout and replication lag. Even in systems with online schema changes, the choice between a blocking and non-blocking migration matters. Run the migration in staging under load and watch for lock times and CPU spikes.
If the new column will be part of a frequent query, verify the execution plan before and after deployment. Profile the read and write path. Adding one computed value can cascade into higher I/O and slower joins.