A new column alters schema and can affect queries, indexes, constraints, and application code. Before running an ALTER TABLE command, review the data model and map dependencies. Identify all SQL queries, ORM models, and API contracts that will touch the column. Make sure tests cover these paths so failures appear early.
Adding a nullable column is often the safest first step. It avoids blocking writes and allows backfilling data asynchronously. For high-traffic tables, adding a column with a default value can trigger a full table rewrite. This can lock the table and harm performance mid-deployment. Use online schema change tools or database-specific features to reduce downtime.
When backfilling, run updates in batches to limit load. Monitor replication lag if the database has read replicas. For non-nullable columns, populate data first, verify integrity, then apply a constraint in a follow-up migration.
Watch type choice carefully. A poorly chosen type can waste storage or force expensive casts later. Consider indexing only after the column is stable and query patterns are known. Adding indexes at the wrong stage increases migration time and locks.