Adding a new column is one of the most frequent schema changes in modern applications. It sounds simple. It can wreck production if done without care. The size of the table, the type of the column, the locks applied by your database, and the rollout process all decide whether your app keeps serving traffic or stalls hard.
In relational databases like PostgreSQL and MySQL, creating a new column is usually fast if it’s nullable with no default. But as soon as you add a non-null constraint, a default value, or use a type that needs recalculation, the database may rewrite the entire table. This can cause long locks, blocked queries, and outages. Engineers working with large datasets or high-read/write systems know that schema changes like this are not just a migration; they are a deployment event.
The safe pattern is to break the change into stages. First, add the new column as nullable with no default. Next, backfill the data in small batches to avoid load spikes. Once the column is fully populated, add constraints or defaults in a separate step. This reduces downtime risk and keeps the application responsive.