The migration is done, but the schema is missing a new column your feature depends on. You can’t deploy until it’s there. You need it in production now, without risking downtime or corrupt data.
Adding a new column sounds simple. In practice, it means making the database change safe, consistent, and visible to all parts of the system at the right time. The steps vary by database engine, but the principles hold:
- Define the new column in your schema with the correct data type and constraints.
- Use a migration tool that can run in your CI/CD pipeline.
- Deploy the migration separately from application code that reads or writes the column.
- Backfill data in small batches if needed to avoid locking large tables.
- Test queries for performance impact.
In PostgreSQL, ALTER TABLE with ADD COLUMN is straightforward when adding a nullable column. For non-nullable columns with default values, the engine writes the default to every row, which can lock the table. To avoid this, create the column as nullable, backfill it in batches, then set NOT NULL when the data is ready.
In MySQL, large table changes may require pt-online-schema-change or native online DDL to avoid blocking writes. In systems with strict uptime SLAs, verify the migration on a replica before touching production.