Question
Ory Kratos Schema Migrations: Version Rollback Compatibility
Nia Maple
0 reputation · 25 Mar 2026, 16:46 UTC
120.1K views1
Loading…
0 reputation · 25 Mar 2026, 16:46 UTC
Ory Kratos manages identity data using a SQL database, where schema updates are applied via the ory migrate sql command during version transitions. While the identity attributes are stored in a flexible JSONB format in PostgreSQL, the underlying table structures are subject to version-specific migrations.
Current migration workflows are designed to be additive. However, there is an uncertainty regarding the binary's behavior when a deployment fails midway through a version upgrade. If the database schema has been advanced to a newer version, it is unclear if a previous version of the Kratos binary can maintain operational stability without a full database restore.
Does Ory Kratos support automated "down" migrations to revert schema changes if a version upgrade fails? If not, will a previous binary version successfully initialize against a schema that has already been migrated to a newer version?
34775 reputation · 26 Mar 2026, 03:38 UTC
Ory Kratos does not provide automated "down" migrations. The kratos migrate sql command only applies forward schema changes.
ory
postgresqlkratos migrate down or similar command.Whether an older Kratos binary can start against a schema that has already been migrated to a newer version depends on the nature of the schema changes between those two versions:
pg_dump -Fc -f kratos-backup.dump $DSN).kratos migrate sql --dsn $DSN.kratos migrate status --dsn $DSN (or query the migration table).pg_restore -d $DSN kratos-backup.dump) and treat the database restore as the actual rollback mechanism.To give a definitive recommendation, please specify the exact Kratos versions involved (current and target) so we can check the release notes/UPGRADE guide for any destructive schema changes between them.
Use comments to ask for clarification. Post a solution as an answer.
6,510 reputation · 25 Mar 2026, 23:29 UTC
To build on the previous point regarding additive changes, it is critical to distinguish between schema-level and data-level compatibility during a rollback. While Kratos avoids frequent destructive schema changes, any migration that introduces a NOT NULL constraint without a default value or renames a column will cause an older binary to fail immediately upon executing a query against that table.
For teams implementing Blue/Green or Canary deployments, consider these verification steps before promoting a version:
pg_dump --schema-only to compare the current schema against the target version to identify non-additive changes.Since Kratos does not provide a migrate down command, the only reliable way to ensure a safe rollback after a destructive migration is a full point-in-time recovery (PITR) of the PostgreSQL instance.