Adding a new column is one of the most common schema updates in production systems. It is also one of the easiest to get wrong. Downtime, failed migrations, or broken queries can follow a poorly handled change. Treat every new column as both a schema update and a contract update for every service and query that depends on it.
Before creating a new column, define its name, type, nullability, and default value. Use consistent naming conventions. Choose a type that suits the actual data, not just the nearest available type. Avoid implicit conversions that can slow queries or create unexpected results.
In relational databases like PostgreSQL or MySQL, adding a nullable column without a default is fastest because it avoids rewriting the table. Adding a column with a default that is not NULL forces a full rewrite, which can lock the table on large datasets. In high-traffic systems, break the work into two steps: first add the nullable column, then backfill data in small batches, and finally set the default. This prevents service degradation.
Update your application code to handle the existence of the new column gracefully. In systems with multiple deployments or services, the schema change must be backward compatible. Deploy code that can work without the column before adding it. Once the column is in production, deploy code that uses it, then clean up old logic. This three-phase rollout pattern reduces risk.