transaction-correctness

name	transaction-correctness
description	How WAL mechanics, checkpointing, concurrency rules, recovery work in tursodb

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

1. Writer appends frames (page data) to WAL file (sequential I/O)
2. COMMIT = frame with non-zero db_size in header (marks transaction end)
3. Original DB unchanged until checkpoint

Read Path

1. Reader acquires read mark (mxFrame = last valid commit frame)
2. For each page: check WAL up to mxFrame, fall back to main DB
3. 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

WAL-Index

SQLite uses a shared memory file (-shm) for WAL index. Turso does not - it uses in-memory data structures (frame_cache hashmap, atomic read marks) since multi-process access is not supported.

Concurrency Rules

• One writer at a time
• Readers don't block writer, writer doesn't block readers
• Checkpoint must stop at pages needed by active readers