How to Fix a Corrupted SQLite Database

Your app won't open. The screen sits there with an error about a database that "cannot be accessed" or a file that is "malformed," and nothing you click moves it forward. SQLite is quietly running inside thousands of desktop apps, mobile apps, and browsers, so when its database file goes bad, the whole program can refuse to start.

The good news is that a corrupted SQLite file is usually recoverable, and most of the time your actual data is still sitting inside it. This guide walks you through confirming the corruption, reading exactly what each error means, and repairing the file using the same tools the SQLite team ships for this job. Work through it in order and only reach for paid recovery software if the free methods come up short.

Before you touch anything, copy the database file somewhere safe. Every repair step below works on a copy, never the original, so you always have something to fall back to.

Step 1: Confirm the Database Is Actually Corrupted

Not every database error means corruption. Sometimes the file is locked, sometimes the app is pointing at the wrong path. So the first move is a diagnosis, not a repair.

You need the SQLite command line tool, sqlite3. It ships with macOS and most Linux systems, and on Windows you can download it from the official SQLite site. Open a terminal in the folder that holds your database and run an integrity check.

sqlite3 yourfile.db "PRAGMA integrity_check;"

If the file is healthy, this returns a single word: ok. If something is wrong, it prints a list of the problems it found, like missing pages or broken indexes. For a faster scan on a large file, PRAGMA quick_check; does a lighter version of the same job.

If the integrity check itself fails to run and throws an error such as "database disk image is malformed," that alone confirms corruption and you can move straight to the repair steps.

What Every Common SQLite Error Actually Means

SQLite errors look cryptic, but each one points at a specific problem. Here is what you are really looking at when one of these shows up.

"database disk image is malformed" (code 11). This is the classic corruption message. The internal structure of the file no longer matches what SQLite expects, often after a crash, a forced shutdown, or a storage glitch. This one needs a real repair, covered below.

"file is not a database" (code 26). SQLite opened the file but the header does not look like an SQLite database at all. Usual causes are a wrong file path, a file that was partly overwritten, or an encrypted database opened without its key. Check you are pointing at the right file before assuming the worst.

"database is locked" (code 5). This is almost never corruption. Another process, or a leftover connection from a crashed one, is still holding the file. The fix here is about releasing the lock, not rebuilding the file.

"database or disk is full" (code 13). Your storage ran out of space, or the temp directory SQLite uses for its work files is full. Free up disk space and try again before doing anything drastic.

"disk I/O error" (code 10). The operating system could not read or write the file properly. This often points at a failing drive, a flaky network share, or a permissions problem rather than the database content itself.

"migration was previously applied but has been modified." This one trips up developers using migration frameworks like sqlx. The database is not corrupted in the normal sense. The app's migration checksum no longer matches the file, usually after an update or after the same database folder was shared between two versions of a tool. The fix is different from a true repair, and it has its own section below.

Knowing which bucket your error falls into saves you from running a full rebuild on a file that just needed a lock cleared.

Fix 1: Restore From a Backup (The Safe One)

If you have a recent backup, this is the fastest and cleanest route, and it is the method the SQLite developers recommend first. A clean backup sidesteps every guessing game that comes with repairing a damaged file.

Close the app completely, including any background or tray process still holding the file. Replace the corrupted database with your backup copy. Reopen the app and run the integrity check from Step 1 to confirm the restored file reports ok.

The only catch is that you lose any data created after that backup was taken. If the gap is small, that is usually an easy trade. If you have no backup, or the backup is also damaged, move on to the next fix.

Fix 2: Rebuild the File With .recover (Best for Real Corruption)

SQLite ships a dedicated recovery command, .recover, built specifically to pull as much usable data as possible out of a damaged file. It is more thorough than older methods because it reads the file at a low level and reconstructs what it can, skipping the parts that are beyond saving.

Run it against a copy of your corrupt file and send the output into a brand new database.

sqlite3 corrupt.db ".recover" | sqlite3 recovered.db

When this finishes, recovered.db is your rebuilt database. Check it before trusting it.

sqlite3 recovered.db "PRAGMA integrity_check;"

If that returns ok, point your app at the recovered file, or rename it back to the original filename once the app is closed. Expect that some rows in badly damaged sections may be missing. Recovery extracts what survives, so review your most important tables and test the app before considering the job done.

Fix 3: Dump and Reimport

If .recover is not available in your version, the older dump method still works well for lighter corruption. It exports the database into a plain SQL text file, then rebuilds a fresh database from that text.

sqlite3 corrupt.db ".dump" > dump.sql

sqlite3 new.db < dump.sql

For a corrupt file, add .bail on so the dump stops at the first damaged section instead of producing a broken export. You can recover everything up to that point, then decide what to do about the rest.

sqlite3 corrupt.db ".bail on" ".dump" > dump.sql

If the dump stops early, open dump.sql in a text editor, remove the incomplete final statement at the bottom, and rebuild from the cleaned file. Finish with an integrity check on new.db the same way you did in Fix 2.

Fix 4: When the File Is Locked, Not Corrupted

If your error was "database is locked," do not run a repair. There is nothing to repair. Something is still holding the file.

Close the app fully and check for a second copy of it running in the background or system tray, then end that process too. Look in the database folder for leftover files ending in -wal, -shm, or -journal. When the app is completely closed, these are safe to remove, and SQLite will recreate them on the next clean start. Restarting the computer is the brute-force version of this, since it releases every lock the system was holding.

Once the lock is gone, the app should open normally and your data will be untouched.

Fix 5: When It Is a Migration Checksum Mismatch

The "migration was previously applied but has been modified" error became widely searched in 2026 after a desktop app update caused it for a large number of users at once. The underlying file was fine. The app's migration system simply refused to start because the checksum it stored no longer matched the database.

The fix is to let the app rebuild its own state files. Close the app completely, including any tray process. In the app's data folder, rename the small state and log database files (often named something like state.sqlite and logs.sqlite, sometimes with a version number) by adding .old to the end. Do not delete the folders that hold your sessions, history, or login credentials, as those are stored separately.

Restart the app. It detects the missing state files and rebuilds them automatically, and it opens normally. Because this clears a small internal database rather than your real content, your work and your login stay intact. If running a command line version and a desktop version of the same tool against one shared folder caused the clash, keep them on separate data folders going forward.

How to Stop SQLite Corruption From Happening Again

Most corruption traces back to a handful of avoidable causes. A few habits keep it from coming back.

Turn on Write-Ahead Logging with PRAGMA journal_mode=WAL;. It improves how the database survives crashes and reduces locking conflicts between processes. Always let apps close normally rather than force-killing them, since an interrupted write is one of the most common ways a file gets damaged. Set up regular automatic backups so a bad file is an annoyance instead of a disaster. Keep an eye on disk health, because a failing drive will keep corrupting files no matter how many times you repair them. And avoid pointing two programs at the same database file at the same time unless they are built to share it.

Getting Back to Work

A corrupted SQLite database feels like a dead end, but in most cases the path out is short: confirm the corruption, read the error to know which kind of problem you have, then restore from a backup or rebuild the file with .recover. The errors that look the scariest, like a malformed disk image, are exactly the ones these tools were built to handle.

If you maintain backups and let your apps shut down cleanly, you turn a future incident from a recovery project into a two-minute restore. Save this guide for the next time an app refuses to launch over its database, and start the backup habit now so the next fix is the easy one.

Frequently Asked Questions