Adding a new column sounds simple. It is not. Schema changes are where clean theory meets operational risk. A single ALTER TABLE command can block queries, lock writes, or cascade performance issues across services. The right approach depends on scale, uptime requirements, and how your system handles schema migrations.
A new column can store critical data, enable new features, or optimize queries. But at the wrong moment, it can trigger downtime. For small datasets, adding it directly may work. For large or production-grade tables, you need controlled deployment: create the column with default NULL, backfill in batches, and only add defaults or constraints after migration is complete.
If you use PostgreSQL, ALTER TABLE ADD COLUMN without defaults is fast, but adding a default with a rewrite can be expensive. In MySQL, adding a column can require a full table copy. Modern engines and tools offer online schema changes, but they must be tested to verify query plans and performance remain stable.