Ecto ↔ PostgreSQL: Ensuring Safe Rollback of Schema‑Change Migrations

Direct Answer

Ecto cannot guarantee that a migration's down function restores the database to its pre-migration state. It does not include a built-in mechanism to validate that down is the exact inverse of up. The mix ecto.migrate task does not emit warnings when a migration lacks a down for irreversible changes, and Repo offers no opt-in strict mode that aborts a migration when rollback safety cannot be confirmed. Safety depends on developer-written logic and manual testing.

Confirmed Behavior

For PostgreSQL, Ecto wraps each migration in a single transaction. This ensures atomicity: if any statement fails, the entire migration rolls back and the schema is unchanged. It does not ensure semantic correctness of the down callback. A flawed down can still commit an unsafe state.

The change macro can automatically reverse only certain operations, such as creating or dropping tables and indexes. Destructive or data-dependent changes—dropping a column, altering a column type, adding a NOT NULL constraint without a default, or executing raw SQL—require explicit down logic. Because dropped columns or truncated data cannot be restored by schema-only logic, no automatic inverse exists for those cases. The set of automatically reversible operations may vary across Ecto versions, so verify against your installed version.

Likely Explanation

The absence of a general-purpose verifier likely stems from the fact that many schema changes are lossy or context-dependent. A static checker could not reliably distinguish a correct inverse from an incorrect one without false positives or excessive restrictions. A warning system would also need to classify reversible versus irreversible operations across all supported adapters and Ecto versions, a mapping that is not currently encoded in the migration runner.

Steps to Verify Rollback Safety

1. In an isolated environment, run mix ecto.migrate followed by mix ecto.rollback --step 1.
2. Compare the resulting schema to the original using mix ecto.dump or psql \d before and after the round trip.
3. Audit each migration so that every non-reversible up operation has an explicit, tested down counterpart.
4. Consult the Ecto migration guide for your project's Ecto version to confirm which change operations are automatically reversible.

These steps are necessary because Ecto executes down as ordinary code without verifying that it undoes the prior state.