The dashboard showed errors. A migration had failed. The log told the story: the database schema lacked a new column. Code waited on it. Users hit dead ends.
Adding a new column should be simple. In practice, it can break production if planned poorly. Schema changes alter the contract between your application and its data. An unchecked new column can slow queries, lock tables, or trigger transaction failures.
In relational databases like PostgreSQL or MySQL, a new column can be added with a single statement:
ALTER TABLE users ADD COLUMN last_login TIMESTAMP;
This works in development. In production, it deserves more thought. Consider the size of the table, default values, indexing, and backward compatibility. Large tables can lock under heavy load. Adding a column with a default can rewrite every row, blocking queries for seconds or minutes.
For zero-downtime changes, deploy in phases. First, add the column without defaults or constraints. Deploy code that writes to the new column. Then backfill in small batches. Once complete, enforce constraints and update indexes. This minimizes impact while allowing new features to ship.