Django pytest running many migrations after tests - django

Question

I am running pytest-django with a legacy database that was not created by Django (e.g. all my models use managed=False). In production, everything is fine but in testing Django wants to apply a bunch of curious migrations.
For testing, I have a pre-populated test database and I want my tests to commit changes to the database (because we have logic in db views and triggers that needs to get run). All that is working fine but afterwards a ton of migrations are run and it takes my test suite time from 1s to 70s.
The migrations are overwhelmingly this type: ALTER TABLE [DeprecatedLegacyTable] CHECK CONSTRAINT [FK_dbo.DeprecatedLegacyTable_dbo.User_DeprecatedServiceId]. The tables aren't even in any models.py, so I guess Django is digging this up with inspectdb.
I've looked around a bit and it seems this is a "feature" of Django but it is hurting my workflow. Is there any way to to apply these migrations once and for all rather than replay them every test run? I've run makemigrations and showmigrations and there is nothing to apply.
EDIT:
I think that everything is related to TransactionTestCase. pytest-django actually warns that using transaction=True will be slow. Also, I don't think that these are migrations; it is the database flush procedure. The queries being run are the same as when I do django-admin sqlflush. So, I guess I am trying to override that flush behavior.
EDIT2:
What a ride. I see that Dj defers to the vendor database module for flush functionality, meaning each vendor can do it differently. I'm using mssql and they chose some questionable operations. Here's the part where they do the ALTER TABLE on every constraint:
COLUMNS = "TABLE_NAME, CONSTRAINT_NAME"
WHERE = "CONSTRAINT_TYPE not in ('PRIMARY KEY','UNIQUE')"
cursor.execute(
"SELECT {} FROM INFORMATION_SCHEMA.TABLE_CONSTRAINTS WHERE {}".format(COLUMNS, WHERE))
fks = cursor.fetchall()
sql_list = ['ALTER TABLE %s NOCHECK CONSTRAINT %s;' %
(self.quote_name(fk[0]), self.quote_name(fk[1])) for fk in fks]
In the end, I decided to try to monkeypatch the sql_flush functionality to return an empty list since I don't need any actual flushing done.
This is from a conftest.py:
#pytest.fixture(scope="session")
def django_db_setup():
# Turn the database flush procedure into a no-op
def mock_flush(*args, **kwargs):
return []
import django.core.management.sql
django.core.management.sql.sql_flush = mock_flush
settings.DATABASES["default"] = {
"ENGINE": "mssql",
"HOST": os.environ["SERVER_URL"],
"NAME": os.environ["TEST_DATABASE"],
}