Reference

SQLite WAL Mode

SQLite WAL (Write-Ahead Logging) mode records database changes in a separate -wal file before merging them into the main database, improving concurrency and crash safety. It explains the -wal and -shm files cleaners often see.

APIs & internalsAndroidiOS

SQLite WAL Mode

Also known as: write ahead log sqlite, wal journal, sqlite wal mode, -wal file

SQLite WAL (Write-Ahead Logging) mode records database changes in a separate -wal file before merging them into the main database, improving concurrency and crash safety. It explains the -wal and -shm files cleaners often see.

  • WAL writes changes to a separate -wal file before merging them via a checkpoint.
  • WAL mode creates -wal and -shm sidecar files next to the database.
  • Deleting a live -wal file can corrupt the database, so it is not safe junk.

What WAL mode does

Write-Ahead Logging (WAL) is a journaling mode in SQLite where new changes are appended to a separate write-ahead log file instead of being written directly into the main database file. Readers continue to see the original database while a writer appends to the log, which lets reads and a write proceed concurrently.

Periodically SQLite runs a checkpoint that copies committed changes from the log back into the main database file. WAL also improves durability: if an app or device crashes mid-write, SQLite can recover a consistent state from the log on the next open.

The -wal and -shm files

When a database uses WAL mode, SQLite creates two sidecar files next to the database: a -wal file (the write-ahead log itself) and a -shm file (a shared-memory index used to coordinate access). So a database named `app.db` will sit alongside `app.db-wal` and `app.db-shm`.

These files are a normal, healthy part of an active database, not junk. The -wal file can grow between checkpoints and shrink or reset afterward, which is why its size fluctuates. On both Android and iOS, many system and app databases (including media and messaging stores) use WAL, so these files appear throughout app data.

Why cleaners should leave WAL files alone

Deleting a live -wal file out from under an open database can cause data loss or corruption, because uncommitted, checkpointed-but-not-merged changes live there. A responsible cleaner identifies these as database internals and never removes them directly.

Cleanor targets regenerable caches, duplicates, and large media rather than touching database sidecar files like -wal and -shm, so your app data stays intact while you still free up space.

Related terms

Keep reading the reference.

Act on it

Guides and tools for this topic.