DEV Community

Cover image for Yoyo migrate vs Golang migrate
kiryl kazlavets
kiryl kazlavets

Posted on

Yoyo migrate vs Golang migrate

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.

Pretty quickly we ran into issues that made the workflow harder than expected. 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. And with the default settings we could only run one SQL statement per migration, which was too limiting for our use case.

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 I do not think it needs frequent releases. I decided to give it a try and it worked surprisingly well.

What I liked most is how straightforward it is. It supports multiple SQL statements, runs everything inside a transaction so you do not need to roll anything back manually, and handles stored procedures without issues. It also supports both .sql and .py migrations, which makes it very convenient for pipelines where you need to mix schema changes with data transformations or aggregation logic.

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.

Top comments (0)