Adding a new column is one of the most common schema changes. It sounds simple. It rarely is. In production systems, even the smallest schema migration can block queries, cause downtime, or corrupt data if handled carelessly. Speed, correctness, and safety matter.
A new column starts with defining its purpose and data type. Know exactly why it exists. Avoid nullable unless needed. Decide on constraints before writing a migration. For large tables, adding a non-null column with a default can rewrite the entire table and stall the database. Use online schema change tools when possible. Break the change into steps—first add the column, then backfill data, then enforce constraints—so production impact stays low.
In PostgreSQL, ALTER TABLE ADD COLUMN is straightforward but can still lock writes briefly. In MySQL, the storage engine determines how disruptive the operation is. Use gh-ost or pt-online-schema-change for big tables. Document each change in your migration system. Keep migrations idempotent. Always test them against production-like datasets before rollout.