The database schema just changed, and now you need a new column.
Adding a new column should be fast, safe, and reversible. It should not require downtime, block queries, or create risk in production. Yet poorly planned column changes can lock tables, break queries, or cause silent performance issues. The key is understanding the impact before you run the migration.
A new column affects storage, indexes, and query execution plans. In PostgreSQL and MySQL, adding a nullable column without a default value is often instant because the database updates metadata only. But adding a column with a non-null default can rewrite the entire table, causing long locks and slow performance. Large datasets make every mistake more costly.
Schema migrations should be tested against production-like data. Measure the migration time. Check how the new column will affect indexes and queries. If the column will be part of an index, add it in a separate step. If it needs a default value, set it after the column exists to avoid locking during the add.