A new column alters more than the table. It touches code paths, APIs, and sometimes entire workflows. Done wrong, it can trigger timeouts, data loss, or silent corruption. The safest approach starts with defining the exact column type, constraints, and defaults. Stick to explicit naming. Avoid nullable columns unless there is a clear functional reason.
In PostgreSQL, ALTER TABLE ... ADD COLUMN is straightforward, but large datasets demand care. For massive tables, adding a column with a default non-null value locks writes until the operation completes. The better path is to add the nullable column first, backfill in batches, then enforce constraints. MySQL and other relational systems have similar patterns, with subtle differences in locking behavior.
Application code must handle the new column before and after it exists. This calls for deploy scripts that can run idempotently. For example, always check for column existence before altering the table. Migrations should be tested in staging against production-size data. Monitor I/O load during the migration to avoid cascading slowdowns.