Django no such table error after migrate

A diagnostic guide for Django's OperationalError: no such table after makemigrations and migrate, with ordered checks, fixes, and escalation criteria.

The problem and the useful takeaway

You reload a Django page and receive django.db.utils.OperationalError: no such table: app_model even though you just ran makemigrations and migrate. The useful takeaway is that creating migration files is not the same as applying them to the database your running process is connected to. Start by confirming which migrations Django thinks are applied, then verify the database alias and file path before editing or deleting migration files.

Terms used below: a migration is a Python file in an app's migrations/ directory that describes schema changes. The django_migrations table is Django's internal record of which migrations have been applied. An OperationalError is a database-level error, not a Python code error.

Recognizable condition

The traceback contains no such table followed by an app and model table name.
The model exists in models.py and a migration file exists in migrations/.
The error appears after running makemigrations and migrate, often on the first request that queries the model.
It can happen in the development server, a management command, or a production worker.

Common causes and diagnostic signals

\n\n\n\n\n\n\n\n\n\n\n\n\n

Observed condition	Likely cause	First signal to check
Migration files exist, but `showmigrations` shows empty boxes `[ ]`	Migration was never applied or was rolled back	Run `showmigrations` for the app
`showmigrations` shows `[X]`, but the table is absent	Table dropped manually, or migration applied to a different database	Inspect `django_migrations` and the actual table list
`DATABASES` points to a different SQLite file or database instance	Migrations ran on another database file or host	Print `settings.DATABASES` from the running project
Multiple database aliases or `DATABASE_ROUTERS` are configured	Migration applied to one alias; the app queries another	Run `showmigrations --database=<alias>`
SQLite database file or directory is read-only	`migrate` could not create the table	Check file and directory permissions
Migration file deleted after being applied	Migration history out of sync with files	Compare `django_migrations` rows against `migrations/` files

Ordered checks

Check which migrations Django considers applied
\n
Run from the project directory that contains manage.py, with the project's virtual environment activated:
\n
```
python manage.py showmigrations
```
\n
For one app:
\n
```
python manage.py showmigrations <app>
```
\n
Look for [X] (applied) versus [ ] (not applied). If the migration for the missing table shows [ ], the table was never created. You can also query Django's history table directly, for example with SQLite:
\n
```
sqlite3 db.sqlite3 \"SELECT * FROM django_migrations WHERE app = '<app>';\";
```
\n
Required access: read permission on the database file or instance. Risk: none; this is read-only.
\n
Confirm the database the running process is using
\n
Open settings.py and inspect DATABASES. For SQLite, note the NAME path. Relative paths resolve from the current working directory, so starting the server from a different folder can create or open a different db.sqlite3 file.
\n
Print the active configuration from the same environment the server uses:
\n
```
python manage.py shell -c 'from django.conf import settings; print(settings.DATABASES)'
```
\n
Compare the printed path or host with the database you inspected in step 1. If they differ, Django applied migrations to a different database than the one serving requests.
\n
Check multi-database routers and aliases
\n
If DATABASES contains more than a default alias, or if DATABASE_ROUTERS is set, migrate targets default unless you specify another alias:
\n
```
python manage.py migrate --database=<alias>
```
\n
Check the other alias:
\n
```
python manage.py showmigrations --database=<alias>
```
\n
If the migration appears under a non-default alias, the app's database router may be sending queries to a database that never received the migration.
\n
Check SQLite file permissions
\n
For SQLite, the user running the web server or worker needs write permission on both the .sqlite3 file and its directory, because creating a table modifies the file and may create temporary files:
\n
```
ls -l db.sqlite3
```
\n
If the file is read-only or owned by another user, migrate may fail silently or raise a permission error instead of creating the table.
\n
Look for an interrupted migration
\n
If a previous migrate command crashed, the database may be partially updated. Most Django backends run each migration in a transaction, but manual SQL or disabled transactions can leave the schema and django_migrations out of sync.
\n

Fixes tied to findings

Fix 1: Apply the missing migration

If showmigrations shows [ ], run:

python manage.py migrate <app>

This applies all unapplied migrations for that app. Back up the database first in production. This command changes database state.

Fix 2: Correct the database path or alias

If settings.DATABASES points to the wrong SQLite file or database instance, update NAME, HOST, PORT, or other connection parameters, then restart the application process so it picks up the new setting. Alternatively, if the migration was intentionally applied to another alias, run:

python manage.py migrate --database=<alias>

and update the router or application code so queries use the intended alias.

Fix 3: Recreate a deleted migration file safely

If django_migrations contains a row for a migration whose file is missing, do not delete the row. Recreate the migration file with the same name and dependencies, then mark it applied without running SQL:

python manage.py migrate <app> <migration_name> --fake

Risk: --fake records the migration as applied without executing its SQL. If the table is genuinely missing, the error will persist. Only use --fake after confirming the schema already matches the migration, or after manually creating the missing table.

Fix 4: Recover from manual schema changes

If you dropped or renamed the table with direct SQL, either recreate the table to match the migration's intended schema, or restore from a backup. In development only, you can reset migration history for the app and reapply migrations, but this deletes data.

Fix 5: Fix SQLite permissions

Change ownership or permissions on the database file and directory so the application user can write. Then rerun migrate.

Fix 6: Resolve migration dependency loops

If migrations reference each other in a loop, edit the dependencies list in the migration files to remove the cycle, then run makemigrations and migrate again.

Rollback guidance

migrate changes state. To reverse a specific migration:

python manage.py migrate <app> <previous_migration_name>

Back up the database first. Rolling back removes data stored in tables created by the reversed migration. Do not roll back in production unless you have confirmed the data loss is acceptable.

Escalation criteria

You are in production and cannot identify which database file or instance the running process uses.
django_migrations and the physical schema disagree across multiple apps.
The error returns after migrate reports success.
You suspect corruption in django_migrations or repeated partial migrations.

In these cases, take a database backup, stop further state-changing commands, and involve a database administrator or engineer with access to the production environment.

Limitations and practical verification

showmigrations reflects Django's tracking table, not the physical schema. A row can exist while the table is absent. Use sqlmigrate to inspect the SQL Django intends to run:

python manage.py sqlmigrate <app> <migration_number>

Compare that SQL against the actual tables in your database. After applying a fix, verify by running the request or management command that previously failed, or by running:

python manage.py check --database <alias>

check validates configuration but does not confirm table existence; the real test is querying the model through the application.

Diagnosing Django \"no such table\" After makemigrations and migrate

The problem and the useful takeaway

Recognizable condition

Common causes and diagnostic signals

Ordered checks

Check which migrations Django considers applied

Confirm the database the running process is using

Check multi-database routers and aliases

Check SQLite file permissions

Look for an interrupted migration