The query finished running, but the logs showed something strange. A new column had appeared in the dataset, and no one had touched the migration scripts.
Adding a new column is the smallest unit of schema change, but it’s never trivial. It can unlock features, capture new data, and fix design mistakes. It can also break pipelines, bloat storage, and silently cause bugs if not handled with precision.
In relational databases, a new column must be defined with type, nullability, and default value. These choices have immediate effects on performance and behavior. Adding a nullable column might be fast in PostgreSQL, but a non-null with default will rewrite the entire table. In MySQL, the cost depends on storage engine and version. Some systems now add columns instantly, but their semantics still demand care.
Backward compatibility is critical. Applications reading from the table must handle the new column gracefully. Avoid assumptions about order in SELECT * queries. Always version your schema changes and run them in controlled environments before production.