Should Unmanaged Models Be Excluded from Django Migrations?

I work extensively with both unmanaged and managed models, often dealing with read-only access to third-party databases as well as specific views and stored procedures on our own databases.

I’m wondering if there’s merit in having an option to "not track changes" for particular (or all) unmanaged models during migrations. Since unmanaged models aren’t controlled by Django, shouldn’t there be instances where tracking their changes isn’t necessary? This could add flexibility by excluding some models—similar to how we ignore third-party libraries in version control (like venv directories or node_modules).

Drawing from the Django docs:

You should think of migrations as a version control system for your database schema. makemigrations is responsible for packaging up your model changes into individual migration files - analogous to commits - and migrate is responsible for applying those to your database.

For models related to databases or tables outside our control, do we really need historical changes? Excluding them from migrations might align Django’s behavior more closely with its documentation and reinforce the idea of migrations as commits in version control.

Regarding unmanaged models, here are my thoughts:

• The current goal is to have Django track everything with unmanaged models (similar to managed ones) so migrations function as a version control system (see this ticket).
• Allowing certain unmanaged models to be excluded would validate the docs’ analogy to VCS, much like excluding third-party libraries.

An issue was brought up by @charettes:

• What happens if we stop ‘not including migrations’ halfway through?

I think we should treat this option similar to the current managed/unmanaged toggle. In cases where a model’s status changes, migrations could be generated accordingly.

We could implement checks in the autodetector:

Scenario 1 (no-migrations → migrations):
We could generate a migration for the change (perhaps a CreateModel type).

Scenario 2 (migrations → no-migrations):
We could generate a migration that acts as a DeleteModel type, after which further changes would be untracked.

This is just opening up ideas for discussion. I’m interested in hearing thoughts and insights on this potential feature.