The migration had stalled. Everyone stared at the schema diff, and there it was: the new column. Adding it was simple. Handling the consequences was not.
A new column in a production database is more than a line of SQL. It changes read patterns. It changes write paths. It reshapes APIs. Done wrong, it can block deploys, lock tables, and trigger downtime. Done right, it appears silently, ready for use, without a blip in service.
First, choose the migration strategy. On small tables, ALTER TABLE ADD COLUMN works instantly. On large datasets, the alter can lock writes. Avoid that by using tools like gh-ost or pt-online-schema-change for MySQL, or Postgres' native ADD COLUMN when adding nullable columns or ones with default values that don't require rewrites in newer versions. Audit your database version and features before running the change.
Second, deploy in stages. Add the column with a safe default. Backfill data in controlled batches to prevent replication lag and I/O spikes. Wrap changes in transactions when possible, but know your engine's limits. Monitor metrics throughout the process: lock times, query throughput, replication delay.