Josh, nice yo see you around!
The usual cause of slowness when applying migration is model rendering. Nowadays most Operation.state_forwards implementations avoid model rendering entirely by operating solely from ModelState instance which has the side effect of making the creation of project state used to apply migration forward relatively fast as until changes need to be effectively applied no dynamic model creation is performed.
Since migrations operation don’t implement a state_backwards method a lot more state alterations have to take place to emulate them and this encouraged us to force the rendering of models prior to attempting any change. This has the unfortunate side effect of making most of the state_forwards extremely costly when dealing with a large model graphs as state mutation forces the reloading of tons of model clases. I wouldn’t be surprised if in your case removing the forced model rendering made things faster.
In order to make migrations truly faster we know that we must make schema editors treat with model state instead of rendered models and implementing state_backwards would certainly help to a certain extent. Until then we’ll have to keep finding ways to defer model rendering as much as possible while making sure our invalidation logic on state alterations accounts for all the layers of caching that rendered models have.