Adding a new column sounds simple. In production, it can break everything if done wrong. The change touches schema, application code, queries, and sometimes replication or backups. The database doesn’t care about your deploy window. It locks, it waits, it can block writes. That’s why the process must be deliberate.
Start with the purpose. Is the new column for new data, denormalization, indexing, or a rollout path for a feature flag? Define the type, nullability, default value, and constraints. Adding a column with the wrong default or null setting can lead to massive table rewrites.
For large tables, avoid operations that require a full table rewrite. Use database-specific methods for online schema changes. PostgreSQL can add nullable columns instantly. MySQL may need pt-online-schema-change or gh-ost. Test the migration against a clone of production to see locking behavior and execution time.
Update your application code in a controlled sequence. Deploy code that can handle the old and new schema before running the migration. This ensures that no request fails due to missing or mismatched columns. Use feature flags to control rollout and test reads and writes in the new column under real conditions before making it critical.