The query returned in milliseconds, but the schema had changed without warning. The table now needed a new column.
Adding a new column sounds simple. In production, it can break services, slow queries, or trigger full table rewrites. The stakes depend on table size, indexes, foreign keys, and database engine specifics. A careless ALTER TABLE can lock rows, block inserts, or cause replicas to lag.
In relational databases like PostgreSQL and MySQL, adding a nullable column with a default is often safe if the database stores metadata instead of rewriting rows. But not all engines handle this the same way. MySQL before 8.0 rewrites the whole table for many schema changes. PostgreSQL handles some changes in constant time if defaults are null. Always test in staging with production-scale data.
When adding a new column, define the exact type and constraints. Decide if the column should allow nulls. Avoid adding heavy indexes until after initial deployment. If you need a default value, consider adding the column without it first, then backfilling in controlled batches. This reduces locks and keeps systems responsive.