Adding a new column to a production database is not just about ALTER TABLE. It is about performance, null handling, defaults, version control, and rollout strategy. The choice between adding the column with or without a default can decide whether your ALTER runs in milliseconds or locks the table for hours. In PostgreSQL, for example, adding a nullable column without a default is instant. Adding a default to an existing table can rewrite every row.
A new column affects indexes. If you plan to filter by it, create the index after the column exists, but be aware of the time and I/O cost for large datasets. For MySQL, use ALGORITHM=INPLACE when possible to reduce downtime. Evaluate whether the column belongs in a main table or should be normalized to reduce write contention.
Consider application-level changes. Database migrations should be backward-compatible until all services have been deployed with code that can handle the new column. In many teams, the pattern is: deploy migration -> deploy code that reads but does not require the column -> deploy code that writes -> remove old assumptions. This avoids schema drift and breakage during rolling updates.