When you add a new column to a database, you are changing the structure of the schema. Done right, this feels instant. Done wrong, it locks your data, blocks writes, or turns a simple change into a deployment delay. Large tables make it worse. Billions of rows mean migrations take time, and time means downtime.
Plan the migration. First, understand the database engine. PostgreSQL handles ALTER TABLE ADD COLUMN without rewriting the table for nullable columns without defaults. In MySQL, you must check the version and storage engine to know whether the operation locks rows. For production, defaults that trigger a full table rewrite should be avoided until after the column exists.
Use tools that support online schema changes. PostgreSQL can batch update defaults after adding the column with ALTER TABLE ... SET DEFAULT and backfilling in controlled steps. MySQL pairs well with gh-ost or pt-online-schema-change for zero-downtime column additions. For distributed SQL databases, confirm that replicas and shards receive schema changes in sync.