SQLite: file is not a database

Result code

SQLITE_NOTADB (26)

Product

SQLite library

Versions

SQLite 3.x (examples run on 3.39.2; shell output from 3.50.6)

Category

Files & Permissions

Last reviewed

24 October 2026

What it means

This error means the file SQLite opened does not start with a valid SQLite database header, so it is a different kind of file, an encrypted database opened without the right key, or a file whose header was damaged.

Every SQLite 3 database starts with a 100-byte header whose first 16 bytes are the text SQLite format 3 followed by a zero byte. Opening a file does not read it, so the open succeeds and the error appears on the first statement that needs the database: a query on a table, sqlite_schema or a PRAGMA such as journal_mode. Statements that do not touch the file (SELECT 1, SELECT sqlite_version()) still work, which can make the connection look healthy. A zero-byte file is not an error: SQLite treats it as a new, empty database, so you get no such table instead.

SQLite reports this code when the header is missing or invalid, not when the content behind a valid header is damaged; that is database disk image is malformed. An encrypted database (SQLCipher, the SQLite Encryption Extension and similar) looks like random bytes without its key, so a plain SQLite build, or the right build with a wrong or missing key, reports the same error.

Common causes

• The path points to a different kind of file: a CSV export, a JSON or text file, a ZIP or backup archive, or a file saved with a .db or .sqlite extension that is not SQLite.
• A download or sync stored something else under the database name: an HTML error or login page, or a Git LFS pointer file when the repository was cloned without LFS.
• The database is encrypted and was opened without the key, with the wrong key, or with a library that has no encryption support.
• The first bytes of the file were overwritten, for example by a program that wrote to the wrong file or an incomplete copy.

Diagnose it

Read-only These statements only read the schema (sqlite_schema and read-only PRAGMA queries) or your own data. They do not change data, settings or the database file, so they are safe to run first.

PRAGMA database_list;

SELECT COUNT(*) AS objects FROM sqlite_schema;
PRAGMA quick_check;

How to fix it

Each fix is labelled with what it changes. Try read-only checks and the least invasive fix first, and test changes outside production.

-- sqlite3 new_shop.db
.import --csv customers.csv customers
SELECT COUNT(*) FROM customers;

Examples

A CSV file opened as a database

-- shop.db is really a CSV export:
--   id,name
--   1,Sara

SELECT * FROM customers;

file is not a database

A Git LFS pointer file instead of the database

-- shop.db was cloned without Git LFS, so it holds the pointer text:
--   version https://git-lfs.github.com/spec/v1
--   oid sha256:...
--   size 81920

PRAGMA journal_mode;

file is not a database

The header of a real database was overwritten

CREATE TABLE orders (id INTEGER PRIMARY KEY, total REAL);
INSERT INTO orders (total) VALUES (10);
-- then another program overwrites the first 16 bytes of shop.db

SELECT * FROM orders;

file is not a database

An encrypted database opened without the right key

Shown as documented in the SQLite documentation; not reproduced here, because the lab's SQLite build has no encryption extension. The SQLite Encryption Extension documentation says a wrong key gives SQLITE_NOTADB on first access, worded there as "file is encrypted or is not a database".

-- vault.db was created with an encryption extension;
-- it is opened with plain SQLite, or with the wrong key

SELECT * FROM accounts;

file is not a database

How to prevent it

Give database files a consistent extension and keep exports (CSV, JSON, dumps) under their own extensions, so a wrong file is not picked up by name. When an application downloads or syncs a database, write it to a temporary name, check the first 16 bytes or run a quick check, and only then rename it into place.

For encrypted databases, keep the key handling in one place and fail with a clear message when the key is missing. Keep regular backups made with VACUUM INTO or the backup API, because a checked backup is the dependable way back from a damaged file.

Common questions

Learn more on CodeWithSQL

• How to install SQLite
• Best SQLite GUI tools

Official documentation

• SQLite result and error codes (SQLITE_NOTADB)
• Database file format: the database header
• SQLite Encryption Extension: wrong keys
• sqlite3 shell: importing CSV files

Last technically reviewed 24 October 2026; examples and diagnostics run on SQLite 3.39.2 (PHP PDO_SQLITE) and the sqlite3 shell 3.50.6. Messages are the text the SQLite library itself returns (sqlite3_errmsg) for the versions shown.