Choose WAL mode only after testing the local workload
Also published in our Blogger archive.
Direct answer
WAL is selected with PRAGMA journal_mode=WAL; SQLite returns the journal mode it actually chose. That returned value is the first thing to inspect, because configuration text alone does not prove that a database accepted the requested mode. The example uses a temporary file, commits through one connection, then opens a second connection to make the reader/writer shape visible without claiming a benchmark.
This is a configuration experiment, not a universal recommendation. WAL changes how a database stores its journal and can alter the way a particular filesystem, backup process, or connection pattern behaves. The meaningful next measurement is your own workload: concurrent readers, write duration, lock failures, checkpoint behavior, and recovery expectations.
The code tests a normal committed read. It does not create simultaneous threads, force a lock, measure throughput, or prove that WAL is suitable for network storage. A reader seeing visible only establishes the synthetic committed case. If a worker needs a busy timeout or retry policy, test that policy separately rather than inferring it from the pragma result.
Complete example
import sqlite3
from pathlib import Path
from tempfile import TemporaryDirectory
with TemporaryDirectory() as directory:
database = Path(directory) / "workload.sqlite3"
writer = sqlite3.connect(database)
selected = writer.execute("PRAGMA journal_mode=WAL").fetchone()[0]
assert selected.lower() == "wal"
writer.execute("CREATE TABLE notes (value TEXT)")
writer.execute("INSERT INTO notes VALUES ('visible')")
writer.commit()
reader = sqlite3.connect(database)
assert reader.execute("SELECT value FROM notes").fetchone()[0] == "visible"
print(f"journal_mode={selected.lower()} reader=visible")
reader.close()
writer.close()Expected stdout:
journal_mode=wal reader=visibleSources
Prepared with AI assistance. The example uses synthetic data; its stated limits apply.