Expand and Contract vs. Single-step Migrations for Railway Rollback Safety

The Expand and Contract pattern better minimizes the risk of data loss during a rollback on Railway. Because Railway does not guarantee transactional DDL across all database engines (such as MySQL or Maria), a single-step migration that fails halfway through can leave your database in a 'zombie' state—incompatible with both the old and new application code.

When your database lacks transactional DDL, the recommended strategy is to decouple schema changes from application logic. This ensures that at any point during the deployment, the database remains backward compatible with the currently running version of your app.

Recommended Strategy for Non-Transactional DDL

To manage state safely without atomic migrations, follow this multi-phase approach:

<

• Phase 1: Expand: Add new columns, tables, or indices. Do not remove or modify existing structures. The application continues to use the old schema.
• Phase 2: Migrate: Deploy code that writes to both the old and new structures (dual writing) and migrates existing data.
• Phase 3: Switch: Deploy code that reads only from the new structures. If this fails, you can roll back the code instantly because the old schema still exists.
• Phase 4: Contract: Once the new version is stable, deploy a final migration to remove the old, unused structures.

Why Single-step Migrations Fail on Railway

Single-step migrations often include destructive actions (e.g., DROP COLUMN) in the same deployment. If the Railway deployment fails after the migration but before the new container is healthy, a rollback will trigger a 'down' method. However, if the data was already dropped, the 'down' method cannot recover that information, leading to permanent loss.

Note: This strategy assumes you are using a database like MySQL. If you use PostgreSQL where DDL is transactional, single-step migrations are safer but still lack the flexibility for zero-downtime requirements.