Adding a new column is never just adding a new column. It changes data shape. It shifts query plans. It breaks fragile assumptions in downstream code. Done wrong, it risks corrupting data or locking a production table under load.
The first step is planning. Define the column in precise terms: name, type, nullability, default value, and purpose. Document it before you touch the database. Align the new column with current indexing strategy. Blindly creating indexes can slow writes and increase storage costs.
In relational databases, adding a new column in a large table can cause long locks and downtime. On MySQL with older storage engines, ALTER TABLE can block writes until completion. PostgreSQL can add certain column types instantly, but adding defaults that rewrite data may not. Always measure the impact in a staging environment with production-sized data.
Migrations should be atomic, reversible, and tested. Use version control for schema changes. Write migration scripts that handle existing data safely. For large tables, consider rolling updates: add the nullable column first, backfill in controlled batches, then enforce constraints.