SQLite: no such table (tested)

sqlite3.OperationalError: no such table: X means the table named in your query doesn't exist in the database you're actually connected to. We reproduced three distinct ways this happens and measured one surprising non-cause along the way.

1. The table was never created

Querying a brand-new, empty database file:

con = sqlite3.connect("nst.db")
con.execute("SELECT * FROM users")
sqlite3.OperationalError: no such table: users

This is the literal case: no CREATE TABLE ever ran against this file. Running the migration or setup script that creates the table fixes it.

2. Connected to the wrong file — and sqlite3 won't warn you

We created the table in nst.db, then by mistake connected to nst2.db instead:

con2 = sqlite3.connect("nst2.db")
con2.execute("SELECT * FROM Users")
sqlite3.OperationalError: no such table: Users

The trap: sqlite3.connect() silently creates an empty file if the path doesn't exist yet — we confirmed nst2.db existed afterward at 0 bytes. There's no error for "this database is empty" or "this isn't the file you meant"; you only find out when a query against a missing table fails. A relative path run from the wrong working directory is the most common way this happens in practice.

3. A typo in the table name — but NOT a case mismatch

We created a table as Users (capital U) and queried it as users (lowercase):

con.execute("CREATE TABLE Users (id INTEGER)")
con.execute("SELECT * FROM users")  # lowercase
# succeeded — no error, returned rows normally

Measured: SQLite table names are case-insensitive, so casing is never the actual cause of this error, even though it's a common first guess. A genuine typo does fail, though:

con.execute("SELECT * FROM Usres")
sqlite3.OperationalError: no such table: Usres

4. The fix: check which database file you're actually in

Since the error message doesn't distinguish "table was never created" from "wrong file," the fastest check is listing what tables actually exist in the file you're connected to:

SELECT name FROM sqlite_master WHERE type='table';

An empty result confirms you're either in the wrong file or before any migration ran — not a naming or casing issue, which we measured doesn't apply to SQLite table names.

Frequently asked questions

Does SQLite care about uppercase vs lowercase table names?

No — we measured that a table created as Users is successfully queried as users with zero error. Case is never the real cause of 'no such table', even though it looks like an obvious first suspect.

Why didn't sqlite3.connect() warn me I was opening a new, empty database?

By design: sqlite3.connect() creates the file if it doesn't exist, with no warning. We confirmed the new file existed at 0 bytes after connecting — the only way you find out is a later query failing with 'no such table'.

How do I check which tables actually exist in the file I'm connected to?

Run SELECT name FROM sqlite_master WHERE type='table'; on the open connection — we used this to confirm whether a 'no such table' error meant the wrong file or a table that was never created.

Is 'no such table' the same error as a missing database file?

No — connecting to a path that doesn't exist yet succeeds silently and creates an empty file, which we confirmed directly. The 'no such table' error only fires later, when a query names a table that isn't in whichever file you're actually connected to.

Could a schema migration that didn't run cause this?

Yes — this is the same underlying error as repro 1 (table never created). If your app runs migrations on startup and one failed silently or was skipped, every query against the tables it would have created fails identically.

Written with AI assistance. Measured on 2026-10-03 with Python 3.13.5's built-in sqlite3 module across three distinct repro cases: a genuinely empty database, a connection to the wrong file, and a table-name typo. Every error string below is copy-pasted output, not paraphrased. PlainHeaders is our extension; Python's sqlite3 is built in.