The query ran without errors, but the result looked wrong. You checked the schema twice. The problem was obvious: the table needed a new column.
Adding a new column should be fast and predictable, but in production systems it can create downtime, lock tables, and block writes. The way you handle a schema change depends on your database engine, the table size, and latency budgets. In PostgreSQL, adding a nullable column without a default is fast because it only updates metadata. Adding a column with a non-null default rewrites the table, which can be slow. In MySQL, ALTER TABLE can trigger a full table copy unless you use ALGORITHM=INPLACE or ALGORITHM=INSTANT when supported.
Plan schema changes before they land in production. For high-traffic systems, run the change in a migration tool that can break it into safe steps. First, add the column as nullable. Backfill data in batches. Then set constraints. Avoid large lock times that can stall reads and writes under load. If you must add a column with a default value, consider applying it in an update instead of in the ALTER TABLE statement itself.