You can do three stage:

1. Make a schema migration that will work both with old and new code

2. Make a code change

3. Clean up schema migration

Example: deleting a field:

1. Schema migration to make the column optional

2. Remove the field in the code

3. Schema migration to remove the column

Yes, it's more complex than creating one schema migration, but that's the price you pay for zero-downtime. If you can relax that to "1s downtime midnight on sunday", you can keep things simpler. And if you do so many schema migrations you need such things often ... I would submit you're holding it wrong :)

I'm doing all of these and None of it works out of the box.

Adding a field needs a default_db, otherwise old-code fails to `INSERT`. You need to audit all the `create`-like calls otherwise.

Deleting similarly will make old-code fail all `SELECT`s.

For deletion I need a special 3-step dance with managed=False for one deploy. And for all of these I need to run old-tests on new-schema to see if there's some usage any member of our team missed.

I was just in the middle of writing something similar above, thanks!