What happens if I delete the -wal file by accident?

If you delete a WAL file that still contains uncheckpointed transactions, you will lose those changes. The database will still open but will be missing any data that was only in the WAL. There is no way to recover that data unless you have a backup.

Can I delete the -shm file while the database is open?

It is not recommended to delete the SHM file while the database is open, as SQLite may be actively using it. However, if you delete it when the database is closed, SQLite will recreate it automatically the next time it opens the database.

How do I know if my database is in WAL mode or rollback mode?

You can check by running the command PRAGMA journal_mode; in the SQLite command line. It will return 'wal' if WAL mode is active, or 'delete' (or another rollback mode) if not. The presence of a .db-wal file also indicates WAL mode.

Is it safe to delete a .db-journal file if the database was closed properly?

If the database was closed properly, the journal file should have been deleted automatically by SQLite. If you see a leftover journal file, it may be a hot journal from a crash. Do not delete it manually; instead, open the database with SQLite to let it process and remove the journal safely.

SQLite -wal, -shm and -journal Files: Can You Delete Them?

Work with SQLite and you will spot extra files next to your data: .db-wal, .db-shm, .db-journal. The question can i delete sqlite wal file comes up constantly. Do not delete them casually. They hold changes not yet written into the main store. Get the steps right, though, and you can fold their contents back in and remove them cleanly. This guide covers what each file holds and exactly how to handle them before you copy or repair a database.

What Are the -wal, -shm, and -journal Files?

WAL Mode Sidecars

SQLite runs in one of two modes: WAL mode (Write-Ahead Log) or rollback mode (the default). The extra files you see depend on which mode is active.

In WAL mode, a database named file.db gets two companions:

file.db-wal, the write-ahead log, holding recent transactions not yet copied into the main store.
file.db-shm, a shared-memory index SQLite uses to coordinate access to the WAL. It stores nothing permanent. Missing, it rebuilds itself.

Rollback Mode and the Journal

In rollback mode you may see file.db-journal. This appears during a transaction and vanishes when the transaction finishes. After a crash, it sticks around. That leftover is a hot journal sqlite file. Next time the database opens, SQLite reads it to undo the incomplete work and restore consistency.

Can You Delete the -wal File?

Deleting a .db-wal file is dangerous. It holds committed transactions not yet written into the main store. Delete it, and those changes are gone for good. The database opens. The data does not return.

Do not delete it. Instead, merge its contents safely with a sqlite wal checkpoint. SQLite checkpoints automatically when the WAL hits 1,000 pages. You can also force one manually.

How to Safely Checkpoint the WAL File

Run the Checkpoint

To copy the WAL contents into the database and clear the file, do this:

Close every application connected to the database. No new writes can be in flight.
Open a connection with the SQLite command line or any client.
Run: PRAGMA wal_checkpoint(TRUNCATE); This copies the WAL into the database and empties the log.
After the checkpoint, the .db-wal file is empty and safe to remove. Delete the .db-shm file too. It holds nothing permanent and gets recreated on next open.

Before You Copy or Repair

Copying or uploading a database for repair? Close every app first so the WAL checkpoints. If you cannot close everything, include the .db-wal file alongside the main database. The repair tool needs all the data.

What About the -shm File?

The .db-shm file is a temporary index. It stores no permanent data. Delete it freely. SQLite rebuilds it the next time the database opens in WAL mode.

When moving or repairing a database, keep all three files together, the main store, the WAL, and the SHM. It avoids confusion. The SHM is tiny and harmless.

Understanding the -journal File (Rollback Mode)

In rollback mode, a sqlite journal file appears when a transaction starts. If the app crashes or loses power, the journal stays on disk. This leftover is a hot journal sqlite file. On next open, SQLite reads it to undo the partial transaction and bring the database back to a consistent state.

Delete a hot journal manually before SQLite processes it, and you corrupt the store. Half-applied changes remain. The database looks inconsistent. Let SQLite handle it. Open the database normally. Do not delete the file yourself.

Best Practices for Copying or Repairing a Database

Before You Touch Anything

Close every application that might have the database open. This stops new writes and lets any pending WAL content checkpoint automatically.

If you cannot close all apps, copy the .db-wal and .db-shm files along with the main database. The repair tool gets the latest data.

Handling Rollback Mode

For databases in rollback mode, check for a .db-journal file. If one is present, open the database with SQLite first. Let it process the hot journal. Then copy.

After a safe checkpoint with PRAGMA wal_checkpoint(TRUNCATE);, delete the WAL and SHM files without worry.

Using an online repair service like sqlite.repair? Upload the main database together with any WAL or journal files. That gives the best shot at a complete recovery.

What Happens If You Delete These Files Without Checkpointing?

Delete the .db-wal file without checkpointing and you lose every transaction still in the log. The database shows only what had already been written to the main file. Deleting the .db-shm file does no harm. It rebuilds. Deleting a hot journal in rollback mode corrupts the database. The incomplete transaction never gets undone. The store is left inconsistent.

Never delete a WAL or journal file unless you are certain all pending changes have been merged into the main database. Run the checkpoint command. That is the safe path.