Adding a new column should be simple. But in production systems, every schema change carries risk. A new column changes the shape of the data. It can break queries, slow writes, and lock large tables in high-traffic databases. Done wrong, it triggers downtime. Done right, it becomes invisible to the user.
The first step is deciding the column type and default value. Avoid heavy operations like adding a column with a non-null default on massive tables. Instead, create the new column as nullable, backfill in batches, and then set constraints. This avoids full table rewrites that block the system.
Consider index strategy before deployment. Adding an index on a new column increases read performance but can slow inserts and updates. Test under realistic load. Never assume a local environment tells the truth about production impact.
In distributed systems, schema changes must be backward-compatible. Roll out code that can handle both the old and new schema before the migration. This prevents runtime errors when nodes have different versions of code.