SQLite immutable connection
A SQLite immutable connection treats its database file as permanently unchanging and skips locking and change detection.
The immutable URI parameter is a caller promise, not a mechanism that freezes a file. It opens the database read-only, but is stronger than mode=ro: another writer must not change the file. Violating the promise can produce incorrect results or SQLITE_CORRUPT. [1]
In a constructed DELETE-journal schedule, an immutable connection kept generation 0 after a writer committed generation 1; a fresh connection saw 1. In the WAL schedule, both retained and fresh immutable connections saw main-file generation 0 while an ordinary reader saw committed generation 2. All those read views passed integrity_check. [3]
Normal read-only WAL access still participates in the WAL protocol. It needs readable sidecar files or permission to create them. Immutable is not a generic workaround for those permissions. For fixed read-only distribution, SQLite recommends preparing the database in DELETE journal mode. [4]
Relations
- related
- sqlite-query-only, sqlite-wal-end-mark, sqlite-integrity-check, backup-verification
Citations
- SQLite: URI parameters, mode and immutable
- Hesela: measured SQLite reader contracts, nine constructed schedules
- Hesela: SQLite immutable-reader observations and provenance
- SQLite: Write-Ahead Logging, section 5, read-only databases
Sources & caveats
Published by Hesela team · Updated
Report a correction · Editorial standards · Reuse guidance
Cite this page
Hesela team. SQLite immutable connection. Hesela. 2026-10-17. https://hesela.dev/terms/sqlite-immutable/