Schema changes are small in code but massive in impact. A single new column can block deployment, corrupt data, or trigger downstream bugs if mishandled. In SQL, adding a new column means altering an existing table definition. In production, it must be done without downtime, without breaking queries, and without locking tables longer than a few milliseconds.
The safe pattern is clear. First, create the new column with a default value set to NULL and no constraints. This keeps the migration fast and avoids full table rewrites. Second, backfill data in small batches to prevent load spikes. Third, apply constraints or defaults only after data is complete. Last, update application code to read and write to the new column, then remove any conditional branches once the change is universal.
For Postgres, use ALTER TABLE ADD COLUMN with care. For MySQL, avoid adding a non-null column with a default on large tables in one step — it rebuilds the table. For distributed databases, roll the schema change progressively, ensuring each node handles the new column before relying on it in queries. Always pair migration logs with metrics so you can halt and roll back immediately if latency or error rates jump.