Ecto Migration Zero-Downtime Deployment Across Phoenix Application Boundaries

Goal

Migrate a small Phoenix application's database schema without service interruption during deployment.

Constraints

Ecto migrations execute within a single transaction by default, which can cause timeouts and locks on large tables. The application must remain queryable throughout the migration process, including both the Ecto ORM layer and the underlying PostgreSQL database.

Uncertainty

While Ecto.Multi supports atomic grouping of related operations, the framework does not provide built-in orchestration for multi-phase migrations that require data backfilling between schema changes. Standard migration patterns assume immediate completion, but zero-downtime requires intermediate states where the application can handle partial schema evolution.

Questions

1. How can Ecto migrations be structured to separate schema changes from data population while maintaining referential integrity?
2. What patterns exist for coordinating Phoenix application code changes with staged database migrations?