SQLite: database disk image is malformed

Result code

SQLITE_CORRUPT (11); extended SQLITE_CORRUPT_INDEX (779) when an index no longer matches its table

Product

SQLite library

Versions

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

Category

Corruption & Storage

Last reviewed

24 October 2026

What it means

SQLite found something in the database file that breaks its own file format, so it stopped the statement rather than return or write wrong data. Stop writing to the file, keep a copy of it, check it with PRAGMA integrity_check and recover from the copy or a backup.

A SQLite database is one file made of fixed-size pages (4096 bytes by default) that hold B-trees: one for each table and one for each index, plus the schema on page 1. Each page starts with a small header that says what kind of page it is and where its cells are. When SQLite reads a page whose header, cell pointers or record format make no sense, it returns SQLITE_CORRUPT with this message. It is detected on read, so the damage is usually older than the error.

The error only appears when a statement touches a damaged page. In the lab below, with one table page overwritten, SELECT COUNT(*) still answered (SQLite counted the index, which was intact) while SUM(total) failed, and a damaged index entry made a lookup return no rows without any error until a DELETE needed that entry. So a database can look fine for weeks. When only an index is affected, the extended code is SQLITE_CORRUPT_INDEX (779), which the SQLite documentation says REINDEX may fix if nothing else is damaged.

SQLite does not corrupt its own files without outside help (SQLite FAQ, question 21). The usual causes are copying the file during a write, deleting or separating the -wal or -journal file, power loss on storage that ignores flush requests, network file systems with broken locking, and settings that turn off the protections (synchronous = OFF, journal_mode = OFF). A file that is not a SQLite database at all gives file is not a database instead.

Common causes

• The file was copied, backed up or synced (cloud folder, backup agent) while a transaction was writing, so the copy mixes old and new pages.
• The -wal or -journal file next to the database was deleted, renamed or left behind when the database file was moved or copied on its own, so committed changes or the rollback information were lost.
• A power failure or crash on a disk, virtual machine or USB device that reports writes as done before they are stored, or with PRAGMA synchronous = OFF or journal_mode = OFF.
• Several computers write the same file over a network share (SMB, NFS) whose file locking does not work reliably.
• Another part of the program wrote into the file: a stray file handle, a buggy tool, or editing the schema with PRAGMA writable_schema.

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 integrity_check;

PRAGMA quick_check;

PRAGMA database_list;
PRAGMA journal_mode;

*** in database main ***\nTree 2 page 12: btreeInitPage() returns error code 11\nwrong # of entries in index ix_orders_customer\nRuntime error near line 1: database disk image is malformed (11)

sqlite3 shop-copy.db "PRAGMA integrity_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.

REINDEX ix_orders_customer;  -- or REINDEX orders; for every index of the table
PRAGMA integrity_check;

sqlite3 shop-copy.db ".recover" > recovered.sql
sqlite3 recovered.db ".read recovered.sql"
sqlite3 recovered.db "PRAGMA integrity_check;"

sqlite3 shop-copy.db ".dump" > dump.sql
-- edit the last line of dump.sql from ROLLBACK; -- due to errors  to  COMMIT;
sqlite3 recovered.db ".read dump.sql"

sqlite3 shop.db ".backup shop-backup.db"

Examples

A damaged table page: one query works, the next fails

Lab file: a throwaway database with an orders table (2000 rows) and an index on customer; then 8 bytes at the start of one table page (page 12, offset 45056) were overwritten. Any statement that reads that page fails; statements that can be answered from other pages still work.

SELECT COUNT(*) FROM orders;  -- answers 2000 (counted from the index)
SELECT SUM(total) FROM orders;  -- has to read every table page

database disk image is malformed

An index that no longer matches its table (SQLITE_CORRUPT_INDEX)

Lab file: the same database with one byte of one index entry changed. The lookup through the index silently finds nothing; the DELETE must remove the matching index entry, cannot find it and fails with extended code 779 (SQLITE_CORRUPT_INDEX). REINDEX repaired this file.

SELECT * FROM orders WHERE customer = 'customer 1500';  -- no rows, and no error
DELETE FROM orders WHERE id = 1500;

database disk image is malformed

The schema page is damaged, so nothing can be read

Lab file: the page header of page 1, which holds the schema, was overwritten (4 bytes at offset 100). SQLite cannot read the list of tables, so every statement fails, even PRAGMA page_count. Only page-level recovery (.recover) or a backup can help here.

SELECT name FROM sqlite_schema;

database disk image is malformed

After a power failure with the journal deleted

Shown as documented in the SQLite documentation (How To Corrupt An SQLite Database File); not reproduced here, because it needs a real power failure or crash during a write followed by deleting the hot journal, and the result depends on which pages were written. Without the journal, SQLite cannot roll back the half-written transaction, so some pages are new and some old.

SELECT * FROM orders;

database disk image is malformed

How to prevent it

Keep the protections on: the default synchronous setting (FULL, or NORMAL with WAL), a rollback journal or WAL, and never journal_mode = OFF for data you care about. Keep the database on a local disk; if several machines need it, use a client/server database instead of sharing one file over the network.

Back up with .backup, the backup API or VACUUM INTO, not by copying a file that may be open. Move or copy the database only while it is closed, and always together with its -wal and -journal files. Run PRAGMA quick_check regularly (and integrity_check when there is time) so damage is found while a good backup still exists.

Common questions

Learn more on CodeWithSQL

• Install SQLite (including the command-line shell)
• SQL transactions and ACID explained

Official documentation

• SQLite FAQ: what is an SQLITE_CORRUPT error?
• How To Corrupt An SQLite Database File
• Recovering data from a corrupt SQLite database
• PRAGMA integrity_check and quick_check

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.