Kratos Migration Recovery: Handling Failed Schema Updates Without Built-in Rollback

Problem Statement

Ory Kratos applies database schema migrations automatically during upgrades using the goose migration tool. When these migrations fail or leave the database in an inconsistent state, recovery requires manual intervention since Kratos lacks a built-in rollback mechanism for failed migrations.

Constraints and Uncertainties

• Migration failures can partially apply changes, potentially corrupting user data integrity
• The kratos migrate status command shows current migration state but provides no automated recovery path
• Documentation emphasizes database backups as the primary recovery strategy, but this may not be practical for all deployments
• Recovery process varies significantly between Kratos versions, making version-specific approaches necessary
• Custom schemas may not migrate correctly without manual adjustments

Key Questions

1. Can the migration state be safely restored to a known good state using only Kratos CLI tools, or is manual SQL intervention always required?
2. How can one verify data integrity after rolling back migrations, especially for custom schema modifications?
3. What is the recommended approach for handling partial migrations that have already applied some but not all changes?