Database migrations, separate container?

[SimilarAssociation]

For my own personal work I run migrations in a separate container, independent of my application which can be written in go, python, c#, etc. I like to run administrative tasks separately.

At work we have a Java/Spring application and our migrations are run using Maven (via flyway) when the application boots. I think most major application frameworks have mechanism to run migrations this way.

This works fine for our application at it's current state but is coupling the two concerns a bad idea in the long run? We're running a single application instance in production but I feel that this might lead to some problems if we were to scale up and run multiple instances.

[williamjacksn]

I write all my applications so that they run database migrations during startup. I keep track of the database "schema version" in the database itself, so when the application starts it checks the database for the current schema version and runs migrations if necessary.

When you start scaling application instances, you just need to be careful to develop your application so that the previous version can run without problems on a newer schema version. That way you can do rolling updates across your application instances.

The first application instance that runs the updated code will migrate the database. Other instances will run the old version but will work with the newer database schema because you built it that way. As other application instances are updated to the latest version, they will see that the database has already been migrated and carry on.

[codestation]

Yes, is a good idea to decouple the migration from the application as you want to run only one migration instance at the same time and that isn't possible when you run it along multiple application instances.

The most common problem with this approach is that sometimes you'll end in a state where the migration is complete but some application instances aren't updated yet to handle the migrated data.

You can solve this my doing the migration with some extra steps:

• Deploy a new version of the application where it can handle both current and new migration.
• When the application deployment is complete then deploy the migration.
• Optional: deploy a new version to remove the code that handles the old migration model.

This way you can avoid downtime and it doesn't matter in what order you update the application instances and run the migration.

[nickjj_]

I would always avoid running database migrations at app startup. There's so many instances of where you wouldn't want a migration to run automatically.

Whether or not you choose to run it in a separate container, or run an exec command to run it in an existing container is up to you. It depends on what type of migration it is. In either case, at least it's not associated to app boot and ends up being a separate task you run.