One post tagged with "migrate down"

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       |     |
+-------------------------+---------+-----+

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.