The table needs a new column, and the deadline means zero room for mistakes. You open the schema, run the migration, and watch for anything that will break in production. Adding a column seems simple, but it’s rarely just one command. The right approach depends on schema design, database engine, and existing load.
A new column changes storage requirements. It may trigger locks, slow queries, or force a full table rewrite. On large datasets, this can stall production for minutes or hours. Understand how your database handles schema changes. Postgres uses ALTER TABLE ADD COLUMN, often fast for nullable fields. MySQL can be slower unless you use instant DDL changes on supported versions.
Decide the type with precision. Avoid TEXT when VARCHAR is enough. Set defaults carefully—the wrong default can bloat rows or cause queries to scan irrelevant data. Always test migrations against staging with production-scale data.
Index only when necessary. Every index speeds certain reads but costs memory and write performance. For a new column used in high-traffic queries, add the index during off-peak hours or in a separate migration.