mirror of
https://github.com/open-webui/open-webui.git
synced 2026-05-06 10:58:17 -05:00
[PR #23708] [CLOSED] fix(db): default DATABASE_ENABLE_SQLITE_WAL to True so async+sync engines stop deadlocking on file lock #50375
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
📋 Pull Request Information
Original PR: https://github.com/open-webui/open-webui/pull/23708
Author: @Classic298
Created: 4/14/2026
Status: ❌ Closed
Base:
dev← Head:claude/fix/sqlite-wal-default📝 Commits (4)
d863da5fix(db): default DATABASE_ENABLE_SQLITE_WAL to True so async+sync engines stop deadlocking on file lock20b6e78fix(db): explicitly set journal_mode=DELETE in SQLCipher creator when WAL is opted out1d8744ffix(db): verify SQLite journal_mode actually applied; correct SQLCipher comment950922ffix(db): make _set_sqlite_journal_mode non-failing and tailor mismatch warnings📊 Changes
2 files changed (+109 additions, -14 deletions)
View changed files
📝
backend/open_webui/env.py(+9 -1)📝
backend/open_webui/internal/db.py(+100 -13)📄 Description
Open WebUI runs both a sync engine (sqlite3 / sqlcipher3 — used at startup, by Alembic, the peewee migration shim, healthchecks, and a couple of legacy paths) and an async engine (aiosqlite) against the same SQLite database file. SQLite's default rollback-journal mode takes an exclusive lock on the entire DB file for every writer, which means the moment one engine writes, every other reader/writer across both engines blocks on the same file lock. Under a normal request mix this surfaces as the entire FastAPI loop stalling whenever a long write (e.g. file-upload metadata + chat persistence + embedding status updates) happens to overlap.
WAL mode lets readers proceed while a writer is committing and is required for the dual-engine layout to behave; rollback-journal is only safe for single-process, single-engine use which Open WebUI is not.
Flip the default of
DATABASE_ENABLE_SQLITE_WALfromFalsetoTrue. Operators who genuinely need rollback-journal can still setDATABASE_ENABLE_SQLITE_WAL=Falseexplicitly. Also apply the same journal-mode policy in the SQLCipher connection creator so encrypted deployments get the same fix.Contributor License Agreement
🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.