
Transaction Correctness
This walks through how Turso handles SQLite transactions without the standard shared memory file. It covers WAL mechanics (how writes append frames, reads grab snapshots), the four checkpoint types, and why Turso ditches the `.db-shm` file for in-memory structures like `frame_cache` and atomic read marks. You get the actual concurrency rules (one writer, readers don't block), recovery flow, and where to find the relevant Rust code in `wal.rs` and `pager.rs`. Useful if you're debugging transaction behavior in Turso, optimizing checkpoint strategy, or just want to understand why your embedded SQLite knowledge doesn't fully translate. The correctness invariants section is a good sanity check for what guarantees actually hold.
- skills.sh installs
- 1.2K
- GitHub stars
- 25.2K
- last updated
- Aug 21, 2026
Install
$ npx -y skills add tursodatabase/turso --skill transaction-correctness --agent claude-codeInstalls into .claude/skills of the current project.
Files
Transaction Correctness Guide
Turso uses WAL (Write-Ahead Logging) mode exclusively.
Files: .db, .db-wal (no .db-shm - Turso uses in-memory WAL index)
WAL Mechanics
Write Path
- Writer appends frames (page data) to WAL file (sequential I/O)
- COMMIT = frame with non-zero db_size in header (marks transaction end)
- Original DB unchanged until checkpoint
Read Path
- Reader acquires read mark (mxFrame = last valid commit frame)
- For each page: check WAL up to mxFrame, fall back to main DB
- Reader sees consistent snapshot at its read mark
Checkpointing
Transfers WAL content back to main DB.
WAL grows → checkpoint triggered (default: 1000 pages) → pages copied to DB → WAL reused
Checkpoint types:
- PASSIVE: Non-blocking, stops at pages needed by active readers
- FULL: Waits for readers, checkpoints everything
- RESTART: Like FULL, also resets WAL to beginning
- TRUNCATE: Like RESTART, also truncates WAL file to zero length
Sponsors
Details
- Repository
- github.com/tursodatabase/turso
- Category
- Databases
- First seen
- May 16, 2026