> I've always had luck just running the migrations before hand -- the only real caveat there is that you need to do a two-step migration process if you're remov

> I've always had luck just running the migrations before hand -- the only real caveat there is that you need to do a two-step migration process if you're removing fields. If all your changes are additions, and your app is managed by supervisord, it's fairly trivial to pull the code updates, run the migrations, then bounce your supervisor instance. The problem is that some configurations need workers to restart every X requests to avoid memory leaks, and that makes the deployment process completely non-deterministic if you're pushing new code and expecting workers to still serve the old one. There are troubles with dynamic imports too, which happen on large codebases.