Schema changes look simple. They are not. Adding a new column to a production database can break queries, trigger hidden bugs, and cause outages if done without a plan. The right approach makes it safe, predictable, and fast.
Start by defining the new column in migrations, not in ad-hoc SQL. Use explicit types and constraints. Name it with intent; changing it later is costly. Run the migration on staging with real data to measure execution time and lock behavior. Track changes in version control so rollbacks are immediate if needed.
In large datasets, adding a new column with a default value can lock tables for minutes or hours. Avoid this by creating it as nullable first, then backfilling in small batches, then applying constraints. For time-critical systems, add the column without a default, update code to handle nulls, and backfill asynchronously.
Update code paths before the column is live in production. Read paths must tolerate missing data until the backfill completes. Write paths should populate the new column as soon as migration starts, not after. Test all APIs, background jobs, and ETL processes that touch the table.