What is the DB-JOURNAL file format?
Files with the extension .db-journal contain the page images necessary for the recovery of a SQLite database in case of a transaction failure. These are temporary files created by SQLite in the same directory where the database is stored. They should not be visible after the transaction has concluded, as SQLite deletes them automatically on COMMIT or ROLLBACK.
Thanks to the transaction rollback journal files with the extension .db-journal, it is possible to ensure the atomicity of transactions in the database. An application operating on database data that crashes mid-transaction will not leave operations incomplete - they will be reverted to the state before the transaction began. A .db-journal file is present on disk:
- during the execution of a write transaction (DELETE journal mode, SQLite's default),
- when a transaction was interrupted by a crash - until the next connection opens the database,
- when the database is in exclusive locking mode (
PRAGMA locking_mode=EXCLUSIVE) - until it is turned off.
SQLite may use several different temporary sidecar files to ensure the coherence and security of database operations. .db-journal is the classic rollback journal; .db-wal and .db-shm serve the equivalent role in the newer WAL (Write-Ahead Log) mode.
.db-journal file naming
The journal file is named by appending -journal to the full database filename. For instance, if the database is saved as baza.db, the temporary file will be named baza.db-journal and stored in the same directory. Temporary files are not normally visible to users. In case of a crash or power failure, the journal remains in the directory until the next time the database is opened - SQLite then detects the "hot journal," replays the saved page images to restore the pre-transaction state, and deletes the journal automatically.
You should never delete a .db-journal file while a write transaction is in progress, as doing so will corrupt the database. A persistent .db-journal after a clean shutdown almost always indicates a prior crash; SQLite handles the recovery safely on the next open. In WAL mode (PRAGMA journal_mode=WAL), introduced in SQLite 3.7.0 (July 2010), the .db-journal file is not used at all - a .db-wal file takes its role. Most modern application databases have switched to WAL mode for improved read concurrency.
Security & safety
RISK: LOWNot executable; binary crash-recovery data. Deleting a -journal while the database is being written to will corrupt the database - the main operational risk. Leftover journals from crashes are safe to leave until SQLite auto-recovers them. A -journal may contain sensitive un-committed data from the interrupted transaction (partial writes of messages, credentials, etc.); treat with same confidentiality as the main database. Do not open or distribute a -journal in isolation without the parent database.
Format details
in a nutshellPrograms that open DB-JOURNAL files
Windows3 apps
DB Browser for SQLite
Open-source Open the MAIN database (the .db/.sqlite file) - SQLite handles the -journal automatically. Do not open the -journal directly.
SQLite (sqlite3 CLI)
Open-source Run 'sqlite3 mydata.db'; if a hot journal exists SQLite rolls it back automatically on connection, then removes the journal.
Notepad++ (text editor - inspection only)
Open-source Can display the binary journal content for forensic inspection; the 8-byte magic header is visible at offset 0. Do not edit. 
macOS2 apps
DB Browser for SQLite
Open-source Open the main database; the -journal is consumed automatically during the first open after a crash.
SQLite (sqlite3 CLI)
Open-source Pre-installed on macOS; 'sqlite3 file.db' triggers automatic journal rollback if a hot journal is found. 
Linux2 apps
SQLite (sqlite3 CLI)
Open-source 'sqlite3 file.db' - rollback journal is automatically replayed and deleted on first open. Usually pre-installed.
DB Browser for SQLite
Open-source Install the sqlitebrowser package; open the main database, keep the -journal in the same directory. Technical details
deep spec| Format type | Binary temporary transaction rollback journal (SQLite sidecar file) |
| Magic bytes | 8-byte header: 0xD9 0xD5 0x05 0xF9 0x20 0xA1 0x63 0xD7 (hot/persistent journal) |
| Byte order | Big-endian (journal header fields stored in network byte order) |
| Journal header size | 28 bytes (page count, random nonce, sector size, page size fields) |
| Encoding | Binary - stores verbatim SQLite 3 database page images copied before modification |
| Per-page checksum | Two 32-bit integers computed from the nonce and page data; mismatch signals a stale or incomplete journal |
| Typical file size | 0 bytes to hundreds of MB depending on how many pages the aborted transaction touched |
| Journal mode | Used only in DELETE journal mode (SQLite's default); not created in WAL mode |
| Naming convention | Main database path with -journal appended (e.g., mydata.db → mydata.db-journal) |
| Recovery mechanism | SQLite detects a hot journal on connection open, replays page images to restore pre-transaction state, then deletes the journal |
| WAL supersession | WAL mode (.db-wal + .db-shm), introduced in SQLite 3.7.0 (July 2010), is preferred for concurrent workloads and does not use the .db-journal file |
| Released | SQLite 1.0, 2000 (rollback journal is the original journaling mechanism) |
| Latest version | SQLite 3.x current - format unchanged since early SQLite 3; superseded in practice by WAL (-wal) |
| Open standard | Yes · royalty-free |
| Specification | www.sqlite.org |
DB-JOURNAL conversions
Community Q&A
asked by usersNo questions yet - be the first to ask about DB-JOURNAL files.
