Adding a new column should be simple. In a relational database, a new column often unlocks a feature, stores essential state, or supports a new query path. Done right, it improves schema design and application speed. Done wrong, it causes downtime, broken deployments, or silent data loss.
When you add a new column in production, you control three variables: definition, data population, and deployment order. First, define the column with the correct type, constraints, and defaults. Avoid implicit type conversions that trigger table rewrites. Second, decide how to backfill. For large datasets, use batched updates to avoid locks and performance cliffs. Third, deploy in stages. Update the schema, roll out code that writes and reads the new column, then remove old references.
In PostgreSQL, adding a nullable column without a default is near-instant. Adding a column with a non-null default rewrites the table and can block traffic. In MySQL, behavior depends on storage engine and version. Always test in a staging database with a snapshot of production data. Measure execution time and check for locks.