The migration was supposed to be simple: add a new column, deploy, move on. But small changes in production never stay small.
Adding a new column in a database can be fast or it can bring the system to its knees. The difference comes down to how you design, run, and validate the migration. In relational databases, ALTER TABLE operations vary in risk. On smaller tables, adding a new column with a default value might be instant. On massive tables, the same command can lock writes, spike CPU usage, and stall replication.
Before you add a new column, start with the schema. Decide the exact data type, nullability, and default. Keep it as lean as possible. Avoid wide types that waste storage and slow queries. If the column will index in the future, add it later—never during the first migration if you can avoid it.
In PostgreSQL, adding a nullable column without a default is nearly instant. Setting a default will rewrite the table. In MySQL, even non-blocking schema changes can depend on the version and storage engine. Every production environment has its own rules. Test in staging with production-size data before touching the real system. Measure the impact—row count, locks, replication lag, and query performance—so you know the cost.