Adding a new column sounds simple. In practice, it can be the pivot point between a clean rollout and a breaking change that hits every downstream system. Database migrations are rarely just about structure. They touch queries, indexes, application code, deployments, and data integrity.
When adding a new column, the first step is to define the exact type and constraints. Avoid defaults that hide bad data. Specify NOT NULL only if you can backfill consistently, or you risk locking writes during migration. Choose data types to match real use cases, not just what is convenient now.
Next, plan the migration to run without downtime. On large tables, an ALTER TABLE can block reads and writes. In Postgres, use ADD COLUMN with a nullable field, backfill in controlled batches, then set constraints. In MySQL, consider online schema changes with gh-ost or pt-online-schema-change. Always measure the migration plan against production data sizes and query latency.
Update application code to handle the new column before it becomes mandatory. Feature-flag reads and writes. Deploy in stages so both old and new code paths can run in parallel. This makes rollbacks simple and avoids data drift if you need to revert.