The build was running fine until the schema changed. A new column dropped into the table definition, and suddenly, every assumption about the data was outdated.
Adding a new column can be trivial or catastrophic. It depends on how you plan it, deploy it, and handle existing code paths. The database does not care about your roadmap; it cares about structure, constraints, and atomic operations.
Start with intent. Decide the column name, data type, nullability, default value, and purpose. Document them. A new column that is optional today may become required tomorrow. Plan for that migration now, not later.
In SQL databases, ALTER TABLE is your tool, but it varies in performance and locking impact. On large datasets, adding a column with a default value can lock writes. Use migration tools that batch changes or create the column without defaults, then populate it incrementally.
If you work with NoSQL or schemaless databases, you still need discipline. Adding a new field in documents changes queries, indexes, and potentially API responses. Version your data contracts and test against both old and new shapes until all systems are updated.