You need a new column, and the schema must change without breaking production. The clock is running.
Adding a new column is not just an insert statement in a migration file. It is a decision that ripples across APIs, tests, and user-facing features. The wrong move can lock tables, stall writes, and flood error logs. The right move keeps your service running while the structure evolves.
Start by defining the exact purpose of the new column. Make the type explicit. Avoid nullable types unless required. Set defaults carefully; a wrongly chosen default can mask logic errors.
Choose a migration strategy that works for your deployment model. Online schema changes are safer for high-traffic tables. Use tools that support concurrent writes, such as pt-online-schema-change or native database capabilities. Split the process into steps:
- Add the new column without constraints.
- Backfill data in batches to avoid locking.
- Add constraints or indexes only after the data is stable.
Update your application code to read and write to the new column without breaking backward compatibility. Deploy those changes separately from the migration. This isolates risk and makes rollback possible without losing data integrity.