Adding a new column should never be a high-risk step, yet it often breaks production. Schema changes are brittle. They can lock tables, block writes, or trigger deployment rollbacks. The key is to treat a new column as a controlled operation, planned for both the database engine and the application logic.
When adding a new column, start with a null-safe type and a default that does not conflict with existing rows. In PostgreSQL, adding a nullable column without a default is typically instant. Adding a column with a default value forces a table rewrite, which can stall large datasets. In MySQL, the cost depends on the storage engine and version. For high-traffic systems, run the operation in a migration tool that supports online schema changes, such as pt-online-schema-change or gh-ost.
Deploy the schema in two phases. First, add the new column in a way that is invisible to users. Second, update the code to write to and read from it. This prevents race conditions and ensures the old code still works if the column is present but unused. For critical tables, run load tests that simulate production queries against the altered schema before go-live.