The query was timing out, and the logs made it clear why—adding a new column had ballooned the table scan cost. You can’t ship like that.
A new column in a production database sounds simple. It isn’t. Schema changes can lock tables, spike CPU, and break queries in ways that surface hours or days later. Whether you use Postgres, MySQL, or a distributed system, the wrong ALTER TABLE can trigger full-table rewrites or block concurrent writes.
The safe path is to treat adding a new column as a migration, not a tweak. Always check the storage engine’s documentation for how it handles schema changes. In MySQL with InnoDB, some column adds are “instant,” others are not. In Postgres, adding a nullable column with a default value rewrites the whole table unless you split the step into two: add without the default, then backfill.
You should profile the change in a staging environment with production-sized data. Watch query plans before and after. If the new column impacts indexes, audit the index usage, because even unused indexes increase write costs. For distributed SQL databases, confirm that schema changes propagate cleanly across nodes without blocking.