The database table was perfect until it wasn’t. A product change landed. New data had to be tracked. The schema had to change. You needed a new column.
Adding a new column sounds simple. It can be. But the wrong approach in production can lock queries, stall writes, or even bring down critical services. The key is understanding the impact on existing data, indexes, and downstream systems before you type ALTER TABLE.
First, check the table size. On small tables, adding a new column is fast and safe. On large tables with billions of rows, a blocking schema change can run for hours. Use ONLINE schema change options if your database supports them—MySQL’s ALGORITHM=INPLACE, PostgreSQL’s ADD COLUMN with a default of NULL, or a tool like gh-ost or pt-online-schema-change.
Second, consider the default value. Adding a non-nullable column with a default triggers a full table rewrite in many databases. This slows deployments and increases risk. A safer pattern: add the new column nullable, backfill data in batches, then set it to non-nullable.