A new column sounds small. It is not. In production systems, changing a table schema carries risk: downtime, locks, data migration failures, and performance hits under load. The wrong approach can block writes or crash critical services. The right approach avoids both outages and late‑night rollbacks.
First, decide if the new column requires backfilling. If it does, you must plan the migration in stages. Add the column with a default of NULL. Deploy that change to production. Verify replication lag, disk growth, and query plans. Then roll out backfill jobs in batches, keeping an eye on transaction time. Once backfill finishes, you can apply constraints, defaults, and indexes.
For columns without backfill, adding them is simpler but still demands caution. Always measure the table size. On large datasets, even adding metadata can trigger table rewrites. If your database supports it, use ALTER TABLE ... ADD COLUMN with ONLINE or CONCURRENTLY options to reduce lock contention.
Coordinate schema changes with application changes. The application should not reference the new column until it exists in production. Use feature flags or backward‑compatible queries to bridge rollout windows. Avoid deploying schema changes and dependent code in the same release.