Adding a new column is one of the most common schema changes in SQL. It sounds simple. It is not. Every decision—type, nullability, defaults, indexing—affects performance, availability, and future changes. Done carelessly, it triggers table-wide rewrites or unexpected locks. Done well, it’s seamless.
Start with the migration script. In PostgreSQL, ALTER TABLE ADD COLUMN is straightforward, but choices around default values are critical. Setting a non-null default forces a rewrite of the entire table. On large datasets, this can freeze writes for minutes or even hours. If you must assign a default, add the column as nullable first, backfill it in batches, then enforce constraints in a separate migration.
MySQL behaves differently but carries the same risks. Even small changes can trigger table copies without an online DDL strategy in place. Tools like gh-ost or pt-online-schema-change can mitigate downtime by copying and swapping tables while writes continue.
For distributed systems, schema changes need coordination. Ensure all application nodes can handle both the old and new schema before deploying the change. This means code that doesn’t assume the column exists yet, and deployments staged so both versions work until the migration completes.