Adding a new column should be fast, reliable, and reversible. In modern systems, schema changes are not just database updates—they are potential production risks. The wrong approach can lock queries, slow down transactions, or cause inconsistent states under load.
In PostgreSQL, adding a new column without a default is immediate, but setting a default on large tables can trigger a rewrite. MySQL uses ALTER TABLE that may block writes unless paired with ONLINE options or tools like gh-ost or pt-online-schema-change. For distributed databases, such as CockroachDB or Yugabyte, schema migrations often roll out changes in stages and require careful coordination across nodes.
The primary best practice: make the new column nullable, backfill the data in small batches, and set constraints or defaults afterward. This avoids long locks and reduces operational risk. Always deploy schema changes with explicit migrations in version control to maintain a consistent history. Pair each structural change with application code updates that handle the absence or presence of the new column gracefully.