Episode 3 - Decoupling Database Migrations at Application Startup

• 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.
  1. Modern day production deployments and horizontal scaling can get you into a race condition.
  2. 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.

References

• Redis Locks
• Flyway
• Alembic
• Django ORM Migrations