Why do SQLite databases get corrupted?

SQLite databases get corrupted when something outside the engine breaks its write guarantees: an interrupted write or power loss mid-transaction, copying a database while it is still in use, mishandling the WAL or journal files, unreliable locking on network shares, or failing storage. SQLite itself is highly reliable, so the cause is almost always environmental.

Can copying a database file corrupt it?

Yes, if you copy it while an application is still writing. An ordinary file copy captures the main file and the journal or WAL at different instants, so they no longer agree and SQLite reports the image as malformed. Use the .backup command or VACUUM INTO for a consistent snapshot, and always copy the -wal and -shm files with a WAL-mode database.

Does WAL mode cause corruption?

WAL mode itself is safe and improves concurrency, but its companion -wal and -shm files must be respected. Deleting the WAL, moving the database without its companions, or running WAL on a network share with unreliable file locking can all lead to corruption. The mode is not the problem; mishandling its files is.

Why does a database on a network drive keep corrupting?

SQLite depends on the operating system's file locking to stop two writers from clashing. Many network filesystems and cloud-synced folders implement locking unreliably, so concurrent writes can overwrite the same pages and corrupt the file. Keep SQLite databases on local storage and share access through a server process instead.

Is a corrupted SQLite database always recoverable?

Often, but not always fully. Corruption from interrupted writes, bad copies, or localized faults usually touches only some pages, so a repair tool can salvage the rest into a clean file. Truncated files that lost their tail recover only up to the point the data ends, because the missing pages were never written.

Why SQLite Databases Get Corrupted

Understanding why SQLite databases get corrupted is the difference between fixing one broken file and quietly breaking the next one the same way. SQLite is famous for reliability; its own developers describe it as one of the most rugged database engines available, and a healthy setup can run for years without a single fault. So when a file goes bad and greets you with database disk image is malformed, the cause is almost never a bug in SQLite itself. It is something the file was subjected to: a write that never finished, a copy taken at the wrong moment, or storage that lied about what it saved.

This article walks through the real, documented reasons SQLite databases get corrupted, in roughly the order you are likely to meet them. Each cause has a matching prevention, and knowing which one hit you tells you whether a simple recovery will bring the data back. When you need to salvage a damaged file, the repair SQLite tool reads the surviving pages and rebuilds a clean database.

How a Healthy Write Is Supposed to Work

To see why SQLite databases get corrupted, it helps to know what a correct write looks like. A SQLite database is a single file of fixed-size pages. When you change data inside a transaction, SQLite does not scribble over those pages haphazardly. In the classic rollback-journal mode it first copies the original pages into a side journal, then modifies the main file, and only deletes the journal once everything is safely on disk. In WAL (write-ahead logging) mode it appends changes to a separate -wal file and later folds them back into the database during a checkpoint. Either way, the design guarantees that an interruption leaves enough information to roll the file back to a consistent state.

Corruption happens when that carefully ordered dance is broken from the outside, before it can complete or by tampering with its files midway.

Cause One: Interrupted Writes and Power Loss

The most common cause is a write that never finishes. A power cut, a hard reboot, a killed process, or a laptop that runs out of battery mid-transaction can stop SQLite halfway through updating pages. On its own, SQLite is built to survive this: on the next open it replays or rolls back the journal and recovers automatically. The danger appears when the journal or WAL is missing or the storage layer reordered the writes, so the main file ends up with some new pages and some old ones that no longer agree. The result is a mismatched B-tree and the malformed-image error.

This is why durable storage and letting transactions complete matter so much. If power loss is a real risk, an uninterruptible power supply for servers and simply not force-quitting an application mid-save go a long way.

Cause Two: Copying a Database That Was Still in Use

This is the trap that catches the most developers, because it feels perfectly safe. You copy a .db file, or back up a running server's data directory, while an application still has the database open and is writing to it. The copy captures the main file at one instant and any pending changes in the journal or WAL at another, so the pieces do not line up. The copy looks fine until you open it and SQLite reports corruption.

The rule is simple: never copy a live SQLite database with an ordinary file copy. If you must copy while the database is in use, use SQLite's own .backup command or VACUUM INTO, which take a transactionally consistent snapshot. And if you copy a WAL-mode database at rest, you must copy the -wal and -shm files along with it, because the most recent committed data may still live in the WAL and has not yet been checkpointed into the main file.

Cause Three: WAL and Journal Mishandling

WAL mode is excellent for concurrency, but it introduces companion files that must be respected. Several failure modes trace back to mistreating them:

Deleting the WAL file while it still holds committed but un-checkpointed changes throws away real data and can leave the main file inconsistent.
Moving a database without its companions. If you rename or relocate the main file but leave the -wal behind, or vice versa, the two can drift out of sync.
Network filesystems and locking. SQLite relies on the operating system's file locking to coordinate writers. On many network shares (NFS, SMB, some cloud-synced folders) that locking is unreliable, so two processes can write at once and shred the pages. Running a SQLite database off a synced Dropbox or network drive is a classic source of corruption.

Cause Four: Filesystem and Hardware Faults

Sometimes the software did everything right and the storage let it down. A failing hard drive or SSD, a flaky USB stick, bad RAM that flips a bit before it is written, or a filesystem bug can all silently alter the bytes SQLite stored. A particularly nasty variant is a disk or controller that reports a write as complete before the data is truly durable, defeating SQLite's ordering guarantees during a power loss. When integrity_check reports damage on a file that was always closed cleanly and never copied while open, suspect the hardware.

Cause Five: Truncated or Incomplete Files

A database is only sound if all of its pages are present. A download that was interrupted, a file transfer that dropped the connection, or a disk that filled up mid-write can leave a database missing its tail. SQLite opens it, walks a B-tree, follows a pointer past the end of the file, and reports the image as malformed. Unlike a torn write, a truncated file has genuinely lost data: the missing pages were never written, so recovery salvages whatever survived up to the cut.

Which Causes Are Recoverable

Most corruption from interrupted writes, bad copies, and localized filesystem faults is very recoverable, because the damage touches only some pages while the rest of the data sits readable on disk. The repair SQLite tool reads the schema from sqlite_master, walks every intact B-tree, and rebuilds a clean file from the survivors. Truncated files recover partially, up to the point the data ends. To actually perform the salvage, follow our step-by-step guide on how to repair a corrupted SQLite database, or dig into the internals in recovering data from a corrupt SQLite file.

Conclusion

SQLite databases get corrupted not because the engine is fragile but because something outside it broke the rules the engine depends on: a write cut short by power loss, a live file copied at the wrong moment, WAL and journal files mishandled, a network share with broken locking, or hardware that failed to store what it promised. Match your symptom to its cause, recover the data with the repair SQLite tool, and then close the door for good by reading how to prevent SQLite corruption.