The query finished, but the table was wrong. The business team needed data for Q4, but the schema had changed overnight. The fix was clear: add a new column.
A new column can seem trivial. In practice, it changes how systems store, query, and deliver data. You need to decide column name, type, constraints, defaults, and indexing strategy. Get one wrong, and downstream services will fail, reports will break, and performance will slow.
When adding a new column in SQL, start with a migration. In PostgreSQL, use ALTER TABLE … ADD COLUMN. In MySQL, do the same but watch for lock behavior in production. For high-traffic tables, batch your changes. In large datasets, adding a column with a default value can rewrite the entire table, causing downtime. Consider adding it as nullable first, then backfilling values asynchronously.
Plan for compatibility. Older code may not expect the column. API contracts might fail if responses suddenly include extra fields. Deploy schema changes before the application code that depends on them. This minimizes race conditions and rollback complexity.
Document every new column. Define its purpose, allowed values, and how it relates to other columns. Without documentation, data drift is inevitable.