Ariga’s Atlas database migration tool is hands-down THE best migration tool out there. The way it works is wonderfully simple and innovative.
The main advantage of Atlas over other tools is that it allows a “declarative workflow”. This means that you no longer need to write migrations as SQL scripts that need to be executed in a particular order, as in Flyway or Liquibase. Rather, you define the schema you desire, and Atlas figures out how to get the production schema to that desired state.
What I consider an incredible UX hack though is that Atlas allows you to define your schema in raw SQL, unlike tools like Prisma that make you learn their own schema definition language that doesn’t work as well as SQL. Not even by a long shot.
It does all this with a simple trick: it runs your imperative SQL schema definition script on a dummy database, then computes the difference between the dummy database and the production database. Based on the diff, it decides which tables and columns it needs to modify in order to make the production DB look like the dummy DB.
This approach makes so much sense! It simply boggles the mind that most of us are still clumsily creating versioned migration files and dealing with stored file hashes of failed migrations. Atlas’s way makes changes to the DB schema similar to any code change: you just open the schema.sql file, and edit the table you want, or add a CREATE TABLE statement to the end of the file.
”Declarative workflow” fits much better with the way we work nowadays. In code reviews, for example, the reviewer looks at migration files and can’t tell what the previous state was. There’s no Git diff! It’s a new file! Another example is rollbacks: you revert the commit with the bad migration, and you’re done! We don’t need two separate versioning systems - Git, and whatever the migration tool does with tables. Git is fine.