async-io-model
Explanations of common asynchronous patterns used in tursodb. Involves IOResult, state machines, re-entrancy pitfalls, CompletionGroup. Always use these…
How WAL mechanics, checkpointing, concurrency rules, recovery work in tursodb
$ npx -y skills add tursodatabase/turso --skill transaction-correctness --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/transaction-correctnessContext preview
The summary Claude sees to decide when to auto-load this skill.
How WAL mechanics, checkpointing, concurrency rules, recovery work in tursodb
name: transaction-correctness description: How WAL mechanics, checkpointing, concurrency rules, recovery work in tursodb
Turso uses WAL (Write-Ahead Logging) mode exclusively.
Files: `.db`, `.db-wal` (no `.db-shm` - Turso uses in-memory WAL index)
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
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
Transfers WAL content back to main DB.
WAL grows → checkpoint triggered (default: 1000 pages) → pages copied to DB → WAL reused
Checkpoint types:
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.
On crash: 1. First connection acquires exclusive lock 2. Replays valid commits from WAL 3. Releases lock, normal operation resumes
Key files:
**Per-Connection (private):**
**Shared across connections:**
1. **Durability**: COMMIT record must be fsynced before returning success 2. **Atomicity**: Partial transactions never visible to readers 3. **Isolation**: Each reader sees consistent snapshot 4. **No lost updates**: Checkpoint can't overwrite uncommitted changes
A SQL database in Rust: SQLite-compatible, now also speaking Postgres (experimental). The LLVM of databases.
Repo: tursodatabase/turso
Explanations of common asynchronous patterns used in tursodb. Involves IOResult, state machines, re-entrancy pitfalls, CompletionGroup. Always use these…
Change Data Capture - architecture, entrypoints, bytecode emission, sync engine integration, tests
General Correctness rules, Rust patterns, comments, avoiding over-engineering. When writing code always take these into account
How to debug tursodb using Bytecode comparison, logging, ThreadSanitizer, deterministic simulation, and corruption analysis tools
Information about the differential fuzzer tool, how to run it and use it catch bugs in Turso. Always load this skill when running this tool
Generate hierarchical AGENTS.md knowledge base for a codebase. Creates root + complexity-scored subdirectory documentation.