The table was ready, but the data was wrong. A missing field held up the release. You needed a new column, and you needed it fast.
ALTER TABLE is simple until it isn’t. On small datasets, adding a new column to a database table takes seconds. On production systems with millions of rows, it can block writes, lock reads, or trigger unwanted downtime. Getting it right means understanding how your database engine processes schema changes.
In PostgreSQL, ALTER TABLE ADD COLUMN is typically instant if you define it with a NULL default. But adding a NOT NULL constraint with a default forces a full table rewrite. MySQL behaves differently: some storage engines can add a new column in place; others require copying the whole table. SQLite, without a dedicated online schema change mechanism, may need application-level migration handling.
When you design migrations for a new column, you balance speed against consistency. You might first add the column as nullable, backfill in batches, then add constraints. You might split schema changes and data changes into separate deployments. Tools like gh-ost or pg_repack can mimic online migrations for critical systems.