The migration ran at 2 a.m. and the log showed a single line: ALTER TABLE users ADD COLUMN last_seen TIMESTAMP;. One new column. It looked simple. It wasn’t.
A new column changes the shape of your data. It changes queries, indexes, caching, and the way services talk to the database. In high-traffic systems, adding a new column without strategy can trigger lock contention, increase disk I/O, and create cascading failures in downstream systems that expect a fixed schema.
The safest way to add a new column is to plan for both schema and application changes. First, verify your database engine’s behavior. MySQL, PostgreSQL, and SQLite all handle ADD COLUMN differently. Some allow instant metadata changes; others rewrite the entire table. On large datasets, that distinction decides whether you finish in milliseconds or hours.
Second, decide on nullability and defaults. A NOT NULL column with a default value can backfill instantly in some databases, but in others it forces a table rewrite. For non-blocking operations, consider adding the column as nullable, deploying the code to write to it, backfilling in small batches, and then setting constraints later.