Django — "no such table" after starting the server

Diagnose Django "no such table" errors by confirming which database the running process uses and whether migrations were applied to it.

beginnerdebuggingpythondjango

Symptoms

OperationalError: no such table: app_model when the app queries the database
The error appears on the first query but not during a simple health check
Running tests passes while the running server fails
The table exists when you inspect one database file but not the one the app uses

Possible causes

Migrations were never applied to the database the running process connects to
The app points at a different database file or name than the one you migrated
A test settings module using an in-memory or separate database is loaded in production
A migration added the model but was not committed or was rolled back

Diagnosis steps

Confirm which database the process is connected to

python manage.py dbshell

Interpretation

The dbshell uses the same settings and database as the app. Listing tables here shows whether the missing table is present for this process.

List applied migrations and compare with models

python manage.py showmigrations

Interpretation

Unchecked boxes mark migrations that were never applied. If the model migration is unchecked, the table genuinely does not exist in this database.

Check the active settings module

python manage.py diffsettings --output unified | head

Interpretation

The output reveals which settings module and database alias are active. A leftover DJANGO_SETTINGS_MODULE often points at the wrong database.

Inspect the database file or schema directly

sqlite3 db.sqlite3 ".tables"

Interpretation

Confirms whether the table exists on disk. If it does here but not via the app, the process is using a different file or database.

Root cause

The running process connects to a database that never received the migration that creates the table. This is usually a settings or environment mismatch rather than a broken migration.

Fix

Apply migrations to the exact database the app uses with python manage.py migrate, and verify the settings module and database alias match the deployment. Commit migrations so every environment can apply them.

Risk note

Running migrate against the wrong database can create tables in a development file while production stays broken. Always confirm the target connection before migrating.

Verify the fix

Restart the server, run the failing query, and confirm it succeeds. Then run showmigrations again to confirm the migration is applied on the target database.

Symptom walkthrough

The application starts normally and health endpoints respond, but the first query against a model raises OperationalError: no such table. The message names the table Django derived from the app label and model name. Tests may pass because they build their own schema, while the running server fails, which is the clue that the two processes are not using the same database.

Fix in practice

Run migrate against the precise database the application uses and make sure the settings module selects it. Commit migration files so every environment can apply the same schema, and avoid silently falling back to a different database when an environment variable is missing.

Verification

After fixing, restart the server and repeat the failing request, then run showmigrations on the target database to confirm the migration is applied. A successful query and a checked migration together prove the table now exists where the app expects it.

Diagnostic commands

Check the behavior with commands like these:

python manage.py dbshell
python manage.py showmigrations
python manage.py diffsettings --output unified | head