The query ran fast, but the table was wrong. You needed a new column, and you needed it now. No waiting for the next release. No painful migrations that break everything. Just a clean, atomic change that goes live without shutting the system down.
Adding a new column sounds simple until it isn’t. Schemas in production are under constant pressure: write-heavy traffic, locked rows, replication lag, brittle client code. A schema change that works fine locally can stall a live database or create integrity problems that burn time and money.
Start with intent. Define exactly what the new column must hold. Choose the correct data type from the start. Avoid nullable traps unless they are true requirements. Align constraints with business rules to stop bad writes early.
For heavily used tables, adding a new column should be online and non-blocking. Postgres offers ALTER TABLE ... ADD COLUMN which is fast for most types, but adding defaults with non-null constraints can still lock writes. MySQL’s ALTER TABLE can be instant in modern versions, but engine choice and column definition matter. For massive datasets, tools like gh-ost or pg_copy patterns can stage the change without halting traffic.