The danger was real. One wrong migration and the app could stall, corrupt data, or force a rollback at 2 a.m.
A new column in a database table seems small. In practice, it touches schema design, migrations, indexing, and application logic. Choosing the right data type matters. So does setting default values and handling nulls. In systems under load, even an ALTER TABLE can lock rows and block queries. The safest path is to plan ahead.
Start with a migration script. Make the change reversible. Instead of adding the new column with constraints immediately, add it as nullable, backfill data in small batches, test reads and writes, then apply constraints when traffic is low. This reduces locking and avoids downtime.
For large datasets, consider creating the new column in a shadow table and syncing it with triggers or application code until fully ready. Many relational databases support adding columns online, but behavior varies between PostgreSQL, MySQL, and SQL Server. In PostgreSQL, adding a nullable column with no default is instant; adding a column with a default on a large table will rewrite the table and can halt writes.