The migration stopped. The logs showed nothing unusual. But the query failed because the table needed a new column.
Adding a new column should be simple, but in production it can break deployments, block writes, or lock tables. The wrong approach can cause downtime. The right approach turns it into a safe, predictable change.
A new column in SQL is added with ALTER TABLE. In MySQL and PostgreSQL, the syntax is straightforward:
ALTER TABLE users ADD COLUMN last_login TIMESTAMP;
On small tables, this runs instantly. On large tables under heavy load, it can trigger locks that stall reads and writes. PostgreSQL versions before 11 rewrote the entire table when adding a column with a default value. MySQL’s behavior differs by storage engine. Understanding these details avoids production incidents.
For zero-downtime changes, avoid adding non-null columns with defaults in one step. First, add the column nullable. Then, backfill data in controlled batches. Finally, apply the NOT NULL constraint when the column is populated. This pattern keeps queries responsive and reduces replication lag.