Adding a new column sounds simple until you face the realities of schema changes in a distributed system. You need to consider locking behavior, migration speed, indexing, and data population—without breaking queries or API contracts. The type, default values, nullability, and constraints all determine if your migration is fast or dangerous.
In most relational databases, adding a nullable column without a default is safe and instant. Adding a column with a default value often rewrites the table, which can block writes for minutes or hours. In PostgreSQL, newer versions avoid full rewrites for certain defaults, but MySQL or older engines may still lock rows. For large tables, online schema change tools like gh-ost or pt-online-schema-change let you add columns without downtime by copying data in chunks and swapping the table in place.
When the new column needs backfilled data, split your migration into steps. First, create the column as nullable. Then run background jobs to populate values in small batches. Only after backfill is complete should you add constraints or make the column non-nullable. This reduces lock times while keeping the system usable.