The query failed. The migration stopped mid-flight, leaving a hole where the data should have been. You stare at the schema and see the mistake: the new column is missing.
Adding a new column sounds trivial, but it can bring an application to a halt if handled carelessly. Databases do not forgive locking the wrong table in production. In many systems, a single blocking ALTER TABLE can freeze writes for minutes or hours. The correct approach depends on your database engine, schema scale, and uptime requirements.
In PostgreSQL, adding a new column with a default value will rewrite the table. On large datasets, this is slow and dangerous. The safer pattern is to add the column without a default, update in small batches, then set the default. In MySQL, the storage engine determines whether the operation is instant or blocking. Percona and newer MySQL versions offer instant column addition for some types, but matching exactly the right definition is critical.
Production migrations demand planning. Test your new column change on a staging environment with realistic data volume. Measure the migration time. Identify the locking behavior. Monitor replication lag to avoid breaking replicas. Use feature flags to roll out read and write paths separately, so old code and new schema can coexist during the transition.