The query returned in under a second. But the schema had changed. You need a new column.
In data systems, adding a new column sounds trivial. It isn’t. Done carelessly, it locks tables, stalls writes, and creates race conditions. In production environments with heavy traffic, the wrong migration can cascade into downtime.
A new column must be planned at the database, application, and deployment levels. First, assess the column’s purpose. Is it nullable? Does it require an index? Will it store static or dynamic values? Small decisions at this stage can multiply in cost later.
Use non-blocking migrations when possible. Many relational databases support adding a nullable column instantly or near-instantly. If defaults are needed, backfill in controlled batches to avoid table-wide locks. In distributed systems, ship schema changes before deploying the code that uses them. This prevents writes from failing when the schema and the application code are out of sync.