Adding a new column is one of the most common schema changes in relational databases. Done right, it is instant, predictable, and safe. Done wrong, it locks tables, blocks writes, and takes production down. The difference is in how you design and run the migration.
A new column in PostgreSQL or MySQL can be added with a simple ALTER TABLE statement. On small tables, this runs fast. On large or high-traffic tables, the cost can be severe. Some engines rewrite the entire table or acquire locks that block reads and writes. The first step is knowing how your database engine handles column addition in your specific version.
Plan the new column carefully. Define the exact data type. Decide if it can be NULL to avoid rewrite-heavy defaults. If you must set a default value, consider adding the column without the default, then updating rows in batches, and finally setting the default in a second migration. This avoids long-running transactions and reduces downtime risk.
For distributed systems, coordinate schema changes across services. A new column might require code changes in APIs, background jobs, and analytics pipelines. Make the column optional in code before making it required in the database. Deploy changes in stages so systems stay compatible during the migration window.