The build passed. But the data is missing one thing: a new column.
Adding a new column sounds simple. In production, it is not. Schema migrations change the surface of your database. They must be safe, fast, and reversible. A careless migration can lock tables, block writes, or cause data loss.
Start by defining the new column in your migration file. Use explicit data types instead of relying on defaults. In PostgreSQL, for example:
ALTER TABLE users ADD COLUMN last_login TIMESTAMPTZ;
Avoid nullable columns with no defaults unless you have a plan to populate them. Large tables need special handling. Use ALTER TABLE ... ADD COLUMN in a transaction if your database supports it without locking. For massive datasets, break changes into multiple steps: add the column, backfill in batches, then add constraints.
Test the migration against a copy of production data. Measure execution time. Look for locks. Check index strategies if the new column will be part of queries.
Deploying the new column in an application layer should also be staged. Add the column in one deploy, use it in the next. This prevents runtime errors from missing attributes in older schemas. Backfill scripts should be idempotent and resilient to restarts.
The new column should be part of a version-controlled schema definition. Every environment—dev, staging, production—must apply the change using the same process. Never change the schema manually in production without a migration.
When the deployment is done, verify the column exists, contains expected data, and does not break performance metrics. Add relevant tests to ensure the new column remains in the schema over time.
If you want to add a new column and ship it with zero downtime, see it live in minutes with hoop.dev.