Yoyo migrate vs Golang migrate

Source: Dev.to

Background

Recently I had to integrate a database migration tool into our CI pipeline. At first we picked golang-migrate because it is popular and widely recommended. Everything looked fine until we started running real migrations.

Issues with golang-migrate

• Stored procedures caused trouble because of delimiter handling.
• If a migration failed, it often ended up in a dirty state and we had to roll it back manually.
• There was no built-in history table, so tracking what actually happened required extra effort.
• With the default settings we could only run one SQL statement per migration, which was too limiting for our use case.

Switching to yoyo-migrate

After spending time trying to work around these problems, I started looking for alternatives and found yoyo-migrate. It has not been updated for about a year, but the functionality is so simple that frequent releases do not seem necessary. I decided to give it a try and it worked surprisingly well.

What I liked most

• Supports multiple SQL statements.
• Runs everything inside a transaction, eliminating the need for manual rollbacks.
• Handles stored procedures without issues.
• Supports both .sql and .py migrations, making it convenient for pipelines that mix schema changes with data transformations or aggregation logic.

Conclusion

yoyo-migrate is not as popular as golang-migrate, but in my case it did the job better. It was easier to work with, caused fewer problems, and fit the workflow without forcing us into hacks or manual fixes. Sometimes the less popular tool simply fits the real task better.