SQLite Write-Ahead Log (.wal) & Shared Memory (.shm) Files

Bottom Line: It is safe to delete .wal and .shm files ONLY when the parent SQLite database application is completely closed. Never delete .wal files while the database is active, as uncommitted write transactions will be corrupted.

Why Do SQLite .wal and .shm Files Exist?

SQLite uses Write-Ahead Logging (WAL) mode to improve concurrency. Instead of locking the main .sqlite or .db file during write operations, SQLite appends changes to a auxiliary .wal file.

• .wal (Write-Ahead Log): Stores uncommitted write transactions.
• .shm (Shared Memory): Acts as an index for the .wal file so reading processes can locate uncommitted data.
• Storage Impact: High-frequency write applications (messaging apps, web browsers, IDEs) can inflate .wal files to 100 MB to 10 GB+.

What Happens If You Delete .wal and .shm Files?

• App Open (Active DB): ⚠️ Use Caution. Deleting .wal while an app is writing causes database corruption and disk I/O error.
• App Closed (Clean Shutdown): When the application closes cleanly, SQLite automatically checkpoints transactions into the main .db file and deletes .wal and .shm.
• Orphaned Files: If an app crashes, orphaned .wal files left behind can be deleted safely after closing the app.

How to Checkpoint & Delete SQLite WAL Files

Method 1: Force SQLite Checkpoint via CLI

sqlite3 mydata.db "PRAGMA wal_checkpoint(TRUNCATE);"

Method 2: Manual Deletion (App Closed)

1. Close the application using the database (e.g. Chrome, Discord, VS Code).
2. Delete the .wal and .shm files accompanying mydata.db.

Frequently Asked Questions (FAQ)

Why is my SQLite .wal file larger than the main database file?

If a read lock is held by a background process, SQLite cannot run its automatic checkpoint, causing the .wal file to grow continuously.

Will deleting an orphaned .wal file lose data?

If the app crashed before checkpointing, uncommitted data inside .wal will be lost, but the main database file will remain uncorrupted.