How to handle database migrations?

Just purchased your book, already 50% in. Great content, Michael & Andreas.

I’m wondering how do you handle migrations with RDS? We have a multi-tenant nodejs app, that is to be deployed on Fargate.

I understand it is a big question so I’ll divide it into following ones:

  1. At what stage (from CodeCommit to Fargate service update) you recommend database migration?
  2. Use another separate container to run migrations or the same container as primary app?
  3. How to efficiently redirect traffic while migration is running? Using LB or in-built logic within the app?
  4. Any other tips for handling migrations in multi-tenant apps?

All these questions probably have preferential answers, but I’m just looking for your opinions.

1 Like

Hi @abhi

thanks for your question. I would recommend one of the following two approaches:

  1. Run the migration script before the app starts up in the app container (you will find an example here ruby-rails/docker/)
  2. Run the migration script inside CodeBuild before the new service version is deployed (you have to connect CodeBuild with your VPC here

Option 1 works locally and in the cloud. I recommend this option if migrations take <10 seconds. Otherwise I would recommend option 2.

Both approaches (1 and 2) have the following in common: While the old version of you app is running, the schema is migrated. After migration finished the new app version is deployed. Therefore, the old app version is running against the new schema for a short period of time. If that is not an option (because of non backward compatible schema changes) a “maintenance mode” to show a warning to your users that the app is not available seems the best solution to me.

I hope that helps :slight_smile:

1 Like

thanks, Michael. Will try this… :grinning:

Would love to see a chapter in book about migrations - in future maybe :smile:

1 Like

This topic was automatically closed after 14 days. New replies are no longer allowed.