Handling drift between my schema and the atlas_schema_revisions table
Question
My revisions table lists the following versions:
mysql> SELECT * FROM "atlas_schema_revisions";
+-------------------------+---------+-----+
| version | applied | ... |
+-------------------------+---------+-----+
| .atlas_cloud_identifier | 0 | |
| 20251007053111 | 1 | |
| 20251007051222 | 1 | |
| 20250618084333 | 1 | |
+-------------------------+---------+-----+
However, when I inspect the target database, the schema changes from 20250618084333
were never applied. How can I delete the latest row(s) so the revision history reflects the actual state?
Answer
Use the atlas migrate set
command to reset the recorded version to the last state that truly matches the database. For example:
atlas migrate set 20251007051222 \
--url "postgres://user:pass@localhost:5432/app"
This removes every row whose version is greater than 20251007051222
from the revision table. After the command finishes, the latest recorded version is 20251007051222
:
mysql> SELECT * FROM "atlas_schema_revisions";
+-------------------------+---------+-----+
| version | applied | ... |
+-------------------------+---------+-----+
| .atlas_cloud_identifier | 0 | |
| 20251007053111 | 1 | |
| 20251007051222 | 1 | |
+-------------------------+---------+-----+
atlas migrate set
updates the revision table only. It does not run or roll back SQL statements. Use it exclusively to fix situations where the revision table is ahead of the real schema.
When to use atlas migrate set
vs atlas migrate down
Use atlas migrate set
when:
- You are certain that the database schema already matches the version you are setting.
- You encounter an unexpected state during development and want to realign the revision table with the actual schema.
If the statements from the latest version(s) were in fact executed and must be reverted, run atlas migrate down
instead. This command computes a safe downgrade plan that undoes the schema changes and updates the revision history. Using atlas migrate set
alone in this case would hide applied changes and leave the database inconsistent.
After resetting the revision table, rerun atlas migrate apply
when you are ready so the skipped migration can be applied once the underlying issue is resolved.