SQLite WAL Growth and Writer Locks: A Small Experiment

A growing WAL file and slow requests do not prove that a child inherited a lock and caused a deadlock. A long-lived reader can limit checkpoint progress, while an active writer can make another writer wait. Separating these effects helps identify which transaction lifetime needs attention.

The reader kept its snapshot while writes continued

A temporary database used WAL mode with automatic checkpointing disabled. A second connection held a read transaction using BEGIN and SELECT. After the first connection committed five additional INSERTs, PASSIVE checkpoint returned (0, 5, 0). The reader still saw one row. After its ROLLBACK, TRUNCATE checkpoint returned (0, 0, 0).

The three numbers represent the busy indication, WAL frames and checkpointed frames. A first value of 0 does not mean every frame was checkpointed. The reader snapshot and checkpoint boundary agree with the WAL behavior documentation. Five frames is the observation for this small file, not a production-size prediction.

The second writer failed at another boundary

BEGIN IMMEDIATE;
-- On the second connection: BEGIN IMMEDIATE;
-- Observed with a 0.05-second timeout: SQLITE_BUSY (5)
ROLLBACK;

With the first connection holding a write transaction, BEGIN IMMEDIATE on the second ended with SQLITE_BUSY (5). Closing a reader alone is insufficient here: the first writer must finish its transaction. Inspect application code for external HTTP calls or long computations performed while a write transaction remains open.

Linking this to 504 requires a request timeline

In production, correlate request start, database wait, commit or rollback, and proxy timeout using one time base. Shorten transaction scope after verifying that database waits explain the delay. Increasing busy timeout only increases the wait; it does not remove the lock holder. Do not repair this by deleting WAL/SHM files or sharing an open database connection across a fork.

The experiment used two connections to a temporary local file. Production investigation must also check distribution fixes and the SQLite library actually in use. These results are not evidence of a defect in a particular Dashboard or MCP product.