Ory Kratos Schema Migrations: Version Rollback Compatibility
27K reputation · 25 Mar 2026, 16:46 UTC
Database Schema Transition
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.
Migration Constraints
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.
- Target Version: Latest stable release
- Database: PostgreSQL (JSONB)
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?
ory
postgresql1 answer
1 question comment
Use comments to ask for clarification. Post a solution as an answer.
2,190 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:
- Schema Diffing: Use a tool like
pg_dump --schema-onlyto compare the current schema against the target version to identify non-additive changes. - Startup Validation: Verify if the older binary version fails during the initial connection check or only when specific identity endpoints are hit.
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.