Database migration at app start-up?

Questions and Answers
1

We are in the process of deploying a new project on Qovery, and we are questioning our usual database migration process.

We used to have a separate script to launch the migration, script that we can reproduce as a Lifecycle Job on Qovery, at the start of each deployment. However, that would require to create a new Docker image to run our migration. Not impossible nor too complex, but still an extra image to maintain.

Hence, we had another idea: what about launching all the migrations when our app starts? Our migrations are built to be compatible with both the current and the new versions, so it shouldn’t break it anyway.

This idea would remove an extra Dockerfile, while simplifying our code base. No need to execute a migration in our integration tests for instance: they would be played automatically when we run our test server.

Are there any drawbacks that we are missing with this approach? It would be interesting to hear other Engineers’ opinions about the process.

Thanks!

2

Assuming we are using Lifecycle Jobs to handle our migrations, how could we identify if we should play the up or down migration? If it’s a rollback, we would indeed like to rollback the database to its previous state. But from my understanding, it will just be another deployment on Qovery, right?

3

Hey @jpetitcolas

Can you give more details about your app / migration script?

Usually, if I take Django example, what you will have is two commands:

  • one to run the migration (which will run the migration against the db with the current app version migration files)
  • one to start the server

What is usually done is:

  • you have one stage before your app starts running the migration with the current app version
  • then server is started once migration is done

I don’t know how your app behaves though.

Of course you can also as you said do the migration in your app directly, you just need to make sure:

  1. your app is compatible with both with version and new version or version and previous version
  2. your probes are properly configured to tell kubernetes that your app is not ready until the migration is done, you can use this guide

let me know if it helps !

4

Hi @bchastanier,

Thanks for the reply. Our Node application is using node-pg-migrate to handle our migrations.

We generate migration files, with both an up and a down methods. The up version allows to migrate the database to the new state, while the down one restore the database at his previous version.

However, this is true that having only the up should be fine. Especially as our code is compatible with both versions, which is a strong requirement due to the deployment process.

For the probe, thanks for the link. This is super useful to understand the difference between readiness and liveliness probes.

I think we’ll use a separate stage ran before our app, following your message.

Thanks!

1 Like
5

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.