The data model was wrong, and you knew it the moment the query slowed to a crawl. A missing column. The fix looked simple—add a new column to the table and move on—but reality is never that clean. Schema changes in production can break code, block deployments, and lock up traffic if done carelessly. A new column is not just an extra field. It’s a structural mutation to the datastore that ripples through every layer of the stack.
In SQL databases, adding a new column can trigger a table rewrite depending on the engine and data type. In PostgreSQL, certain ALTER TABLE operations are fast if the new column has a default of NULL. Others will lock writes until the change is complete. MySQL behaves differently depending on storage format, version, and configuration. Understanding execution time, locking behavior, and transaction implications is critical before migrating.
A new column in NoSQL databases has different costs and risks. In MongoDB, the schema is flexible, but queries on new fields may degrade performance without proper indexing. In DynamoDB, writing a new attribute to an existing item is trivial, but reading it efficiently demands careful key design. The absence of enforced schemas shifts the burden to application logic and documentation.