Adding a new column is simple in theory but dangerous in practice. The wrong approach can lock your table, block writes, or grind production to a halt under load.
The database does not care about your sprint deadline. A ALTER TABLE ... ADD COLUMN on a large table might scan and rewrite billions of rows. That can spike I/O, lock metadata, and cascade slowdowns across dependent services.
Before you add a new column, define its default and nullability. Understand how your database engine handles the operation. PostgreSQL can add a nullable column instantly with no rewrite, but adding a column with a non-null default on older versions can rewrite the entire table. MySQL may behave differently based on storage engine and version.
Plan migrations to avoid downtime. In systems with continuous traffic, create the new column with safe defaults, backfill asynchronously, then update application code in a separate deploy. Monitor replication lag if you run replicas; adding a new column can cause schema drift if not applied consistently.