The table was ready, but it needed a new column. One more field to store the data that would make the feature work. The difference between a clean release and a broken build was a single line of SQL.
A new column can be trivial or dangerous. In relational databases, it changes the schema and the shape of every query that touches it. In production systems, the risk is not in adding it—it’s in how it’s added. Blocking writes for a migration on a busy table will lock upstream services. Adding the wrong default can trigger full table rewrites, grinding CPU and I/O. Skipping null handling will break API contracts without warning.
The fastest approach in PostgreSQL for a new column with no default is ALTER TABLE ... ADD COLUMN. This is instant for most cases because it updates only metadata. Adding a default with NOT NULL will rewrite the table—avoid doing both at once. Add the column as nullable, backfill in smaller batches, then enforce NOT NULL if required. In MySQL, ALTER TABLE often copies the table under the hood, so large datasets demand online DDL via tools like pt-online-schema-change or native ALGORITHM=INPLACE operations.