Adding a new column in a live system is not just a schema change. It is a precision operation that can change performance, unlock features, or break production if done wrong. At scale, ALTER TABLE can lock writes, spike CPU, and make end users feel the lag. The trick is knowing how your database engine handles the change and how to design the migration to avoid downtime.
In PostgreSQL, adding a new column without a default is fast. With a default, the engine rewrites the whole table. That rewrite can be deadly for large datasets. The solution is to add the column as NULL, then backfill in controlled batches, and finally add the default with an ALTER COLUMN SET DEFAULT. In MySQL, using the right algorithm flag determines whether the change can run online. For systems with sharding, the plan needs to run per shard with strict version alignment.
Schema migration tools like Liquibase, Flyway, or custom migration pipelines can track and deploy a new column across environments. For continuous delivery, each migration should be small, reversible, and tested against real data snapshots. Adding indexes right after a new column should be deferred until after deployment to spread out the load.