The build had failed again. The log pointed to a single line: ALTER TABLE users ADD COLUMN last_login TIMESTAMP;. One new column, three thousand errors.
Adding a new column should be simple. In reality, it can destroy a deploy if handled without care. Schema changes ripple through code, migrations, and data integrity. A poorly planned ALTER TABLE can lock rows, block queries, and impact uptime.
When working with relational databases, a new column is more than an extra field. It changes your API contracts, impacts indexing strategies, and may require backfilling millions of records. On large tables, this can cause downtime or degraded performance. The key is to design migrations that are safe, atomic, and reversible.
For PostgreSQL, adding a nullable column with no default is instant. Adding a column with a non-null default rewrites the table and can lock it. MySQL behaves differently; even adding a nullable column can be expensive depending on engine and version. Always test on a production-sized dataset in staging before running in production.