Episode 3 - Decoupling Database Migrations at Application Startup
13 mins
- Data models change and evolve with your application.
- There’s plenty of tools that keep track of database schemas and automatically generate scripts to upgrade or downgrade them.
- It’s common for developers to run a migration at the start of their app before running app code.
- Our author explains two common problems with this approach.
- Modern day production deployments and horizontal scaling can get you into a race condition.
- You start assuming that new code will only ever run with the new schema.
- You can decouple migrations from code changes by disabling parallelism during this time.
- Make it a separate command or lock the database during the upgrade.
- We can easily implement locking ourselves in any language.
- Use Redis locks if you’re ok with something external to the DB.
- Use the DB itself by writing to an extra table to say that you’re upgrading it.
- Plan your deployment appropriately so you can run old code with new by making migrations additive in the short term.
- Using a script at startup that optionally performs the migration based on an environment variable integrates wel with Docker and cloud services.
- Upgrades of both code and data should be part of your testing BEFORE releasing to production.
