Databases age. Schema changes are inevitable. Adding a new column sounds trivial, but the reality is sharp edges: performance impact, locking behavior, replication lag, default values, backward compatibility. Every detail matters.
When introducing a new column in production, plan for zero-downtime deployment. In relational databases like PostgreSQL or MySQL, adding a column with a default can lock the entire table. Test on a staging environment with realistic data volumes. Measure how long the ALTER TABLE runs. If necessary, split the operation into multiple steps: add the column without a default, then backfill in batches, then set constraints or defaults afterward.
For distributed systems, ensure schema changes are backward-compatible. Code should accept both old and new versions of data. This means deploying application changes before the database changes, and only removing deprecated fields after confirming every service can handle the new schema. Apply migrations in phases. Rehearse rollback procedures.