A new column sounds simple. In practice, it can be the line between a clean migration and a broken production service. Adding it the wrong way risks locking tables, delaying queries, or introducing null integrity issues. Doing it the right way means understanding how your database handles schema changes, how to populate default values without blocking, and how to roll out code changes in sync with the database state.
Start by defining the exact type for the new column. Mismatched data types cause silent bugs later. Use a migration tool that supports transactional DDL where possible, but know that some databases like MySQL may still rebuild the table for certain operations. Plan for online schema change techniques such as pt-online-schema-change or native features like PostgreSQL’s ADD COLUMN with a default that doesn’t rewrite the table.
Avoid adding a NOT NULL constraint with a default in a single step if your engine rewrites the entire table. If you need constraints, add the column as nullable, backfill data in batches, then enforce NOT NULL in a separate migration. This reduces lock time and speeds up deploys.