Adding a new column can be the simplest task in the database—or the one that breaks production. It depends on how you handle schema changes, defaults, and locks. In relational databases, a poorly planned ALTER TABLE can block writes, cause replication lag, or force a full table rewrite. The difference between smooth and catastrophic lies in knowing the mechanics.
In PostgreSQL, ALTER TABLE ADD COLUMN is straightforward when the new column allows NULLs or has a lightweight default. A constant default that does not touch existing rows will not rewrite the table. A default derived from an expression, however, can trigger a full rewrite. On large datasets, that can lock things for minutes or hours. MySQL behaves differently: adding a column may be online in InnoDB if certain conditions are met, but not if you change the row format or affect indexes.
For safe schema changes, avoid setting defaults that write immediately to every row. Instead, add the column nullable, backfill in small batches, then set the default and constraints. For critical systems, run the change in a staging environment that matches production scale. Use tools like pg_stat_activity or performance_schema for visibility during the operation.