How do I prevent SQLite corruption?

Enable WAL mode for safer concurrent writes, always close the database cleanly so transactions finish, never copy a live database with an ordinary file copy, back up regularly with VACUUM INTO or the backup API, and keep the file on reliable local storage rather than a network or synced drive. Periodic integrity_check runs catch trouble early.

Does WAL mode prevent corruption?

WAL mode greatly reduces corruption in busy applications by letting readers and a writer work at once and updating the main file only during controlled checkpoints. Enable it with PRAGMA journal_mode=WAL. It is not a cure-all, though: you must still keep the companion -wal and -shm files with the database and never delete them while it is in use.

What is the safe way to back up a SQLite database?

Use SQLite's own tools rather than copying the file. Run VACUUM INTO 'backup.db' for a one-line consistent, defragmented copy, or use the sqlite3 .backup command, both of which take a coherent snapshot even while the database is being written. Schedule them regularly, keep several generations, and store at least one copy off the machine.

Why should I not put a SQLite database on a network or cloud drive?

SQLite relies on the operating system's file locking to stop two processes writing at once. Many network shares and cloud-sync folders implement locking unreliably or sync partial files, so concurrent writes can corrupt pages. Keep the database on local disk and share access through a server process if multiple machines need it.

How often should I check a SQLite database for corruption?

Run PRAGMA integrity_check against a copy of important databases periodically, or the faster PRAGMA quick_check on very large ones. A result of ok confirms the file is sound. If a check reports errors, recover the data immediately while it is still mostly readable rather than continuing to write to a failing file.

How to Prevent SQLite Corruption

The best time to think about how to prevent SQLite corruption is before it happens, because a few simple habits eliminate almost every cause of the dreaded database disk image is malformed error. SQLite is one of the most reliable pieces of software ever shipped; a correctly used database can run for years without a single fault. Corruption is rarely the engine's doing. It comes from the environment around it: writes cut short, live files copied at the wrong moment, companion files mishandled, and storage that fails to keep its promises. Close those doors and your databases stay healthy.

This guide turns SQLite's reliability rules into a practical checklist for developers. Follow it and you will rarely need a repair, but if a file ever does go bad, the repair SQLite tool can salvage it. Prevention and recovery are two halves of the same discipline.

Use WAL Mode for Safer Concurrent Writes

The single most effective step to prevent SQLite corruption in a busy application is to enable WAL (write-ahead logging) mode. Run PRAGMA journal_mode=WAL; once on the database and the setting persists. Instead of modifying the main file directly and protecting it with a rollback journal, WAL appends changes to a separate -wal file and folds them back into the database during a checkpoint. This has two benefits. Readers and a writer can work at the same time without blocking, which removes a whole class of locking clashes, and the write path is more resilient to interruption because the main file is only updated during controlled checkpoints.

WAL is not a licence to be careless with its companion files. The -wal and -shm files are part of the database. Never delete them while the database is in use, and if you move or copy the database, keep them together with the main file. Pair WAL with a sensible PRAGMA synchronous=NORMAL; for a good balance of speed and durability on most systems.

Shut Down Cleanly and Let Transactions Finish

Most catastrophic corruption traces back to a write that never completed. Guarding against it is mostly about discipline:

Close the database properly. Call the connection's close function so SQLite can finalise its journal or checkpoint the WAL. Do not just kill the process and hope.
Let transactions commit. Wrap related changes in a transaction and let the commit return before you exit. A commit is the moment SQLite makes the change durable.
Protect against power loss. On servers, an uninterruptible power supply keeps a machine alive long enough to finish in-flight writes. On laptops, avoid force-quitting an app in the middle of a save.
Keep synchronous durability on. Setting PRAGMA synchronous=OFF makes writes faster but removes the guarantee that data reaches disk before SQLite reports success, which is exactly the guarantee that survives a power cut. Do not turn it off for data you care about.

Never Copy or Move a Live Database

This is the rule that catches the most people, because copying a file feels completely harmless. Using an ordinary file copy on a database that an application still has open captures the main file and its journal or WAL at different instants, and the mismatched result is corrupt the moment you open it. To prevent SQLite corruption during backups and file moves, do it the safe way:

Copy only when the database is closed, and include the -wal and -shm files if it used WAL mode, since the most recent committed data may still live in the WAL.
To copy while it is in use, use SQLite's own tools. The .backup command in the sqlite3 shell and the VACUUM INTO 'copy.db' statement both take a transactionally consistent snapshot that is safe even while the database is being written.

Back Up with VACUUM INTO or .backup

No amount of prevention beats having a clean copy to fall back on, so a real backup routine is the safety net under everything else. Two built-in mechanisms produce consistent backups without stopping your application:

VACUUM INTO: running VACUUM INTO '/path/backup.db'; writes a fresh, defragmented, fully consistent copy of the live database to a new file. It is the simplest one-line backup and doubles as a way to compact a bloated file.
The backup API / .backup: the sqlite3 shell's .backup main backup.db and the underlying backup API copy a live database page by page while holding proper locks, so the result is always coherent.

Schedule these regularly, keep more than one generation, and store at least one copy off the machine. A single corrupted file is a shrug when yesterday's snapshot sits ready.

Run on Reliable, Local Storage

SQLite depends on the operating system's file locking to coordinate access, and that is where storage choices bite. Two guidelines prevent a lot of grief:

Avoid network and synced filesystems. Many network shares (NFS, SMB) and cloud-sync folders like Dropbox or Google Drive implement file locking unreliably or sync partial files, allowing concurrent writes to shred pages. Keep the database on local disk and expose it through a server process if multiple machines need access.
Use healthy hardware. Failing drives, cheap USB sticks, and bad RAM silently corrupt data before or after SQLite writes it. Monitor drive health, avoid running important databases off removable media, and prefer hardware that honours flush and sync commands rather than lying about durability.

Verify Health Periodically

Catching trouble early keeps a small problem from becoming a lost database. Periodically run PRAGMA integrity_check; against a copy of important databases, or the lighter PRAGMA quick_check; on large ones. A result of ok confirms the file is structurally sound. If a check ever reports errors, act while the data is still mostly readable by recovering it immediately rather than continuing to write to a failing file.

Conclusion

To prevent SQLite corruption, work with the engine's guarantees rather than against them: enable WAL mode for safer concurrency, shut down cleanly so transactions finish, never copy or move a live database with a plain file copy, back up regularly with VACUUM INTO or the backup API, and keep your data on reliable local storage. Verify health with PRAGMA integrity_check now and then. Do these and the malformed-image error becomes a rarity. If one ever slips through, the repair SQLite tool will salvage the data, and our guides on why SQLite databases get corrupted and how to repair a corrupted SQLite database cover the cause and the cure.