The database is live. Traffic is climbing. Then the spec changes, and you need a new column.
Adding a new column sounds simple, but in production systems it can be the point where things break. Schema migrations affect performance, block writes, and can take down critical paths if not planned. In relational databases like PostgreSQL, MySQL, or MariaDB, how you add a column depends on size, constraints, and downtime tolerance.
For small tables, an ALTER TABLE ADD COLUMN works instantly. For large tables with millions of rows, the same command can lock the table. This means blocked queries, mounting latency, and potential cascading failures. Options like setting a default value trigger a full table rewrite. That’s hours of work in the wrong scenario.
To avoid downtime, some teams add the new column as nullable, then backfill data in batches. Others use tools like pt-online-schema-change or pg_online_schema_change to run migrations in place. Zero-downtime migrations are essential for high-availability systems. Submitting an empty, nullable field first, then writing data asynchronously, is a pattern that keeps services up while the schema evolves.