The query finished running, but the numbers didn’t line up.
You open the migration file and see it: a new column.
Adding a new column to a database table seems simple. It isn’t. The moment you alter the schema, you touch live data, indexes, cached queries, and code paths you forgot existed. Done right, a new column can unlock features and speed. Done wrong, it can lock up production and burn hours of rollback pain.
Start with schema impact. Identify the table’s size and usage patterns. Adding a column to a large table can trigger a full table rewrite, which may block reads and writes. Some databases allow online DDL, but verify how your engine handles NULL defaults, column ordering, and index backfills before you execute.
Next, decide on data type and constraints. Types define not just storage, but query performance. Avoid overprovisioning; don’t use TEXT when VARCHAR fits. Apply NOT NULL with caution—enforce it only after a backfill succeeds. Adding a default value in a single ALTER TABLE statement can be more expensive than setting it later through batch updates.