Migrations can, and do, run arbitrary SQL. At the end of the day the migrations framework is just a SQL dependency graph, it can be used without models if that's what you wish. By itself that is way better than ad-hoc scripts.
> At the end of the day the migrations framework is just a SQL dependency graph.
It's not quite. During operation it actually mutates an in-memory shadow of your model structure. And that's really clever, but if you've got a large set of models it can be really slow.
If it gets too slow you can always squash migrations. But since Django 2 I haven't seen the need to do it, runs in a few seconds even with hundreds of migrations.
It also breaks in interesting way: I discovered just today that constants defined on the Model subclass are not available when you use 'get_model()'. I suspect methods wouldn't be accessible either?
As far as I know, this is by design; your migrations are supposed to operate on a frozen state of what your models and code _were at a point in time_.
If you would rely on code outside of said migration, you would be breaching that frozen state and potentially end up with unintended side-effects (e.g. running a migration created 2 years ago that imports your code that changed today). This is why you might have to sometimes copy-paste logic to your python migrations, but you also guarantee that the migration always runs the same way.
That's built on top of the dependency graph though. You can use it without any models - just a bunch of inter-dependent `RunSQL` statements across different apps in your project.
