The build was red. The schema had changed. You needed a new column, and everything downstream broke.
Adding a new column should be simple. In practice, it often triggers a cascade of failures — schema drift, stale migrations, unexpected type mismatches. The longer it takes to resolve, the more it costs.
A new column in a database schema means altering table structure to store new data. In SQL, this means using ALTER TABLE with ADD COLUMN. In modern systems, that’s only half the work. You have to account for production migrations, zero-downtime requirements, and backward compatibility.
In PostgreSQL, adding a column with a default value rewrites the whole table in older versions. That can lock writes for minutes or hours. Version 11+ optimizes this for most cases, but you still need to consider index creation, triggers, and replication lag.
In MySQL, ALTER TABLE can be online for certain engines like InnoDB, but not for all modifications. Large datasets make blocking operations dangerous. Even safe, “online” operations can slow queries if buffer pools churn.