Adding a new column should be fast, safe, and reversible. Yet in many production systems, the process is dangerous. Wrong migrations can lock writes, block reads, or trigger downtime. Even when it works, large table alterations can run for hours and burn IOPS.
A new column is not just a field. It changes the contract between code and data. Every query, every insert, every batch load must know how to handle it. Adding it to PostgreSQL, MySQL, or any relational database requires precision. In PostgreSQL, ALTER TABLE ADD COLUMN is simple, but adding defaults without care rewrites the entire table. In MySQL, even seemingly lightweight changes can be expensive without ONLINE or INPLACE algorithms.
To make it safe, you need a clear migration path. First: create the new column without defaults or non-null constraints. Second: backfill in small batches to avoid lock contention. Third: deploy code that uses the new column. Finally: enforce constraints when you are certain the data is consistent. This approach isolates risk and avoids locking the table for the full duration of the change.