The database was fast, but the request still failed. The missing piece was a new column.
Adding a new column is the smallest change that can break the biggest things. Schema changes are not just about storage. They affect queries, indexes, constraints, migrations, and uptime. A careless ALTER TABLE can lock rows, block writes, and trigger cascading failures.
When adding a new column, start with the target schema written out in full. Define the name, type, nullability, defaults, and if it needs indexing. In many SQL databases, adding a new nullable column without a default is instant. Adding it with a default or NOT NULL can trigger a full table rewrite. That difference decides whether the migration runs in milliseconds or hours.
Use transactional DDL if the database supports it. Keep migrations idempotent so they can be retried. Split dangerous changes into multiple steps: create the new column as nullable, backfill data in controlled batches, then set constraints once the backfill is done.
If the column needs indexing, create the index concurrently where possible. This reduces lock contention and keeps the system responsive. Monitor the database during the migration for replication lag, slow queries, or lock waits.