No one asked if the schema was stable. No one cared that a migration in production meant sleepless nights. The feature needed data, and the data needed a place to live.
Adding a new column sounds simple. In practice, it can trigger cascading changes across your stack. The choice of migration strategy decides whether your users notice a hiccup or your on-call pager lights up.
Start with the database. For relational systems like Postgres or MySQL, use ALTER TABLE with precision. Adding a nullable column is fast. Adding a column with a default value on a large table can lock writes and reads. To avoid downtime, create the column with NULL allowed, backfill data in batches, then enforce constraints. For high-traffic environments, run migrations during low-usage windows or behind feature flags.
In distributed systems, a new column ripples through APIs, serialization, and storage layers. Before the migration, update your read and write code to handle both old and new schemas. Deploy these changes first, even if the column doesn’t yet exist. This makes the system safe for a rolling migration.