The schema was locked, but requirements shifted. You need a new column, and you can’t wait for the next release cycle.
Adding a new column should be fast, predictable, and safe. It needs to work in production without freezing queries or corrupting data. When handled wrong, migrations can block writes, break downstream services, or cause silent data loss. Done right, they are invisible to users and hold up under real traffic.
The first step is planning. Understand the current table size, indexes, and read/write patterns. Adding a column to a small table is trivial. Adding one to a billion-row table is not. Analyze schema dependencies: triggers, stored procedures, materialized views, and integrations that rely on explicit column lists.
Choose the right type. In most systems, you cannot change it later without another migration. For null-safe rollouts, add the column as nullable or with a default value that does not block. Avoid complex expressions or defaults that require full-table rewrites during creation.