The build had passed. The tests were green. But the schema was wrong. You needed a new column in production, and you needed it now.
Adding a new column sounds simple. In practice, it can break queries, stall deployments, or lock tables if handled carelessly. The right path depends on your database engine, your data size, and your uptime requirements.
First, define the column in your schema change script. Include its type, constraints, and nullability. Avoid adding defaults that require rewriting the entire table on creation for large datasets. For example, in PostgreSQL, adding a nullable column without a default is near-instant. Adding a default to an existing column can be slow unless you use the metadata-only path available in later versions.
Second, deploy the schema change in a safe migration process. Run it in separate steps from code changes that depend on the column. This ensures both deploys can be rolled back cleanly. If you’re adding a NOT NULL column, create it as nullable, backfill data in batches, verify, then add the constraint. This avoids table locks and downtime.