What is the DB-WAL file format?
.db-wal files are used by the SQLite database engine (since version 3.7.0, released July 2010) in WAL (Write-Ahead Logging) journaling mode.
Contents of DB-WAL files
Files with the .db-wal extension contain write-ahead log data for a paired SQLite database. Such files are created and used while a database is open and actively modified. A .db-wal file stores committed database changes - complete database pages - that have not yet been written ("checkpointed") back into the main .db file. This write-ahead approach is faster than directly modifying database pages in place, and ensures durability: in the event of a sudden power outage or system crash, SQLite can replay the WAL to recover all committed transactions.
Each .db-wal file begins with a 32-byte header containing a 4-byte magic number (0x377f0682 for little-endian checksums, 0x377f0683 for big-endian), salt values, and a cumulative checksum. The body consists of frames: a 24-byte frame header plus one full database page each. Salt values in the header invalidate stale frames after a checkpoint, preventing accidental replays.
Using DB-WAL files
.db-wal log management is fully automated by the SQLite engine. A companion .db-shm file (shared-memory index) is always present alongside the WAL while the database is open. The .db-wal file disappears automatically once all changes are checkpointed - the default wal_autocheckpoint threshold is 1000 pages. The underlying WAL mechanism is widely used on mobile devices; databases on Android and iOS apps frequently operate in WAL mode for improved concurrency and write performance.
Security & safety
RISK: LOWA .db-wal is inert data, not executable code, so it cannot run by itself. The real risks are operational, not malware: (1) deleting or losing the -wal while the database is open, or after a crash, discards the newest committed transactions - back up the -db, -wal and -shm together; (2) the WAL of an app database can hold sensitive, not-yet-checkpointed data (messages, tokens, history), so treat it as confidential. If the parent database is encrypted (SQLCipher/SEE), the -wal is encrypted too.
Format details
in a nutshellPrograms that open DB-WAL files
Technical details
deep spec| Magic bytes | 0x377f0682 at offset 0 (little-endian checksums) or 0x377f0683 (big-endian checksums) |
| Header size | 32 bytes containing magic, file-format version, page size, checkpoint sequence, salt pair, and checksum |
| Frame structure | 24-byte frame header + one full database page per frame |
| Page size | Matches the page size of the parent SQLite database (typically 4096 bytes) |
| Checksum | Cumulative 8-byte checksum (two 32-bit words) in each frame header and in the WAL header |
| Salt invalidation | Two 32-bit salt values are randomized after each checkpoint, invalidating any stale frames |
| Companion file | Always paired with a .db-shm (shared-memory index) file while the database is open |
| Naming convention | Database filename with -wal appended (e.g., mydata.db-wal) |
| Activation | Created only when the database is set to WAL mode (PRAGMA journal_mode=WAL) |
| Auto-checkpoint | Default wal_autocheckpoint at 1000 pages limits maximum WAL growth before checkpointing |
| Format version field | WAL header encodes the SQLite library version as 3007000 (SQLite 3.7.0, July 2010) |
| Encryption | None by default; encrypted when the database uses SEE or SQLCipher extension |
| Released | SQLite 3.7.0, July 2010 (WAL journaling mode) |
| Latest version | WAL file format magic 0x377f0682 (little-endian) / 0x377f0683 (big-endian) |
| Open standard | Yes · royalty-free |
| Specification | www.sqlite.org |
DB-WAL conversions
Community Q&A
asked by usersNo questions yet - be the first to ask about DB-WAL files.