A new column sounds simple. It rarely is. At scale, schema changes can stall deployments, lock tables, and crush performance. The wrong approach can mean hours of downtime. The right approach makes the change invisible to end users.
In SQL, adding a new column is straightforward:
ALTER TABLE users ADD COLUMN last_login TIMESTAMP;
In production, you need more. You need to think about default values, nullability, indexing, and how your application reads and writes to the new column. Adding a column with a non-null constraint on a large table can rewrite the entire dataset. That’s expensive. Many teams add the column as nullable first, backfill in small batches, then apply constraints later.
PostgreSQL, MySQL, and other relational databases handle column additions differently. PostgreSQL can add a new nullable column instantly. MySQL may lock the table unless you use online DDL. Understanding these differences matters when uptime is critical. If you run migrations through an orchestrated system, ensure it can handle phased changes.