The table was live in production when the request came: add a new column. No downtime. No broken queries. No surprises.
Adding a new column sounds simple. In high-traffic systems, it can be dangerous. Schema changes lock tables, rewrite data, and trigger cascading migrations. The right approach depends on the database engine, the column type, and the constraints in place.
In PostgreSQL, adding a nullable column with no default is fast. The operation updates metadata only, so it completes in milliseconds, even for large tables. Adding a column with a default value on an existing row set, however, can rewrite the entire table, causing lock times to spike. Use ADD COLUMN ... DEFAULT ... carefully. If possible, add the column as nullable first, then backfill in small batches, then apply the default and constraints in a separate step.
In MySQL, operations on large InnoDB tables can be more disruptive. Even "instant" DDL has caveats, and certain column types or constraints fall back to table copies. Use ALGORITHM=INSTANT where supported, but always confirm behavior in a staging environment.