Adding a new column should be fast, safe, and predictable. In most systems, the process is simple on paper—ALTER TABLE, define the column name, set the type, and decide on defaults or nullability. But that’s where performance, locking, and data integrity come into play. The right approach depends on your database engine, traffic patterns, and size of data.
In MySQL, adding a column can trigger a table copy if the change is not online. Use ALTER TABLE ... ADD COLUMN ... ALGORITHM=INPLACE when possible. In PostgreSQL, adding a NULLable column with no default is instant, but setting a default on a large table will rewrite it—use computed defaults or post-insert updates to avoid downtime. For distributed databases, coordinate schema changes with feature flags to prevent mismatches across services.
Schema migrations for new columns should be atomic in code and reversible where possible. Write migration scripts that can run idempotently. Deploy schema changes before application code that depends on them. For critical systems, run migrations in off-peak hours or in small replicated environments before production.