Adding a new column sounds simple until it isn’t. Schema changes can trigger locks, blow up indexes, and force downtime. The risks multiply when the table is large, the system is live, and the SLA is strict. A careless ALTER TABLE can cascade into hours of lost access and angry stakeholders.
A new column requires more than just syntax. You need a plan that accounts for data type, default values, null constraints, and indexing strategy before the first command runs. Each choice changes how the database behaves under load. Adding a default value can rewrite every row. Adding a primary key constraint can block write operations. Even the order of changes matters when replicas and sharding are involved.
In production, the goal is zero downtime. That means rolling changes, online schema migrations, and tools that can stage the column before flipping it live. Techniques like adding the column without defaults, backfilling in batches, and then enforcing constraints can keep services responsive. For high-traffic systems, you also need to watch replication lag and monitor for long-running queries during the migration process.