The query returned fast, but the table was missing something. You needed a new column, and you needed it without breaking production or waiting for a migration window.
Adding a new column should be simple. In practice, it often triggers downtime risks, locks tables, or slows every active connection. The impact grows with table size and query volume. On most relational databases, ALTER TABLE ADD COLUMN is blocking by default. Large tables can take minutes or hours to alter, halting writes and locking out users.
A better approach is to plan schema changes with zero-downtime patterns. For PostgreSQL, that means adding the column with a default of NULL first, avoiding costly rewrites. Populate the column in small batches. Add constraints and indexes only after the data is in place. MySQL and MariaDB require similar care, using algorithms like INPLACE or tools like pt-online-schema-change.
When designing a schema from the start, keep space for future new columns by avoiding overly rigid structures. Wide tables are harder to alter, and denormalization can make column changes more expensive. Document every schema change in version control to track intent and impact.