{"enrichment":{"faq":[{"a":"Turso's transaction-correctness system uses Write-Ahead Logging (WAL) where all changes are written to a log before modifying the main database file. When you begin a transaction, Turso allocates frames in the WAL, writes your changes there, and only after fsync confirms durability does the transaction commit. This ensures that even if the database crashes, the WAL can replay committed transactions during recovery, maintaining ACID properties and preventing lost updates.","q":"How does Turso handle WAL transactions?"},{"a":"Turso's transaction-correctness guide defines four checkpoint modes. Passive checkpoints merge WAL frames into the main database without blocking writers. Full checkpoints wait for all writers to finish before merging. Restart checkpoints truncate the WAL after merging, freeing space. Truncate checkpoints are like restart but used in specific scenarios. Each mode balances durability, concurrency, and storage efficiency differently, allowing you to choose based on your workload's needs.","q":"What are Turso's checkpoint types and how do they work?"},{"a":"Turso's concurrency model allows exactly one writer and multiple readers simultaneously. The writer appends frames to the WAL while readers access either the main database file or WAL frames depending on which version they need. Readers take snapshots at specific WAL frame numbers, ensuring consistent views. The in-memory WAL index tracks which frames are committed, preventing readers from seeing uncommitted data and coordinating safe concurrent access.","q":"How does Turso manage concurrent readers and writers?"},{"a":"Turso's transaction-correctness implementation uses an in-memory WAL index that maps page numbers to their frame locations in the WAL, replacing SQLite's shared-memory file (.shm). The frame cache stores recently accessed WAL frames in memory for fast retrieval. This design reduces system calls and improves performance compared to traditional SQLite, while the index helps readers quickly locate the correct version of each page for their snapshot.","q":"What is Turso's in-memory WAL index and frame cache?"},{"a":"After a crash, Turso's transaction-correctness recovery process scans the WAL to identify committed transactions (those with valid checksums and complete frame data). Uncommitted frames are discarded. Committed frames are replayed into the main database file in order, restoring the database to its last consistent state. The pager validates frame integrity and uses the WAL index to determine which frames apply, ensuring no partial or corrupted transactions are applied.","q":"How does Turso ensure crash recovery and database consistency?"},{"a":"Turso's transaction-correctness design separates per-connection state (like read snapshots and transaction context) from shared structures (the WAL file, in-memory index, and frame cache). Each connection maintains its own snapshot version, preventing interference between transactions. Shared structures are protected by coordination logic so that one writer's changes become visible to new readers only after commit, while existing readers continue using their snapshot until they refresh.","q":"What distinguishes connection-private state from shared WAL structures in Turso?"}],"shadow_tags":["write-ahead-logging","crash-recovery","concurrency-control","snapshot-isolation","checkpoint-management","durability-guarantees","lock-coordination","frame-indexing","transaction-semantics","buffer-pool"],"summary_rewrite":"This guide explains Turso's Write-Ahead Logging system, covering how transactions are written, read, and checkpointed back to the main database file. It details the concurrency model where one writer coexists with multiple readers, checkpoint strategies from passive to truncate modes, and the recovery process after crashes. The guide also maps Turso's implementation to its core storage layer, distinguishing per-connection state from shared WAL structures."},"files":[{"bytes":3066,"path":".claude/skills/transaction-correctness/SKILL.md","sha256":"89d7e0b9da918d20f223b3790e55ff6b363b18eb1ec52b194e28366f31606660","url":"https://skillfed.io/files/tursodatabase/turso/transaction-correctness/e7b21267/SKILL.md"}],"id":"tursodatabase/turso/transaction-correctness","links":{"html":"https://skillfed.io/tursodatabase/turso/transaction-correctness","md":"https://skillfed.io/tursodatabase/turso/transaction-correctness.md","repo":"https://github.com/tursodatabase/turso"},"meta":{"agents_supported":["claude-code"],"first_seen":"2026-07-28","forks":1211,"language":"Rust","last_updated":"2026-07-28","license":"MIT","name":"transaction-correctness","publisher":"tursodatabase","stars":23479},"relations":{"similar":[{"id":"tursodatabase/turso/mvcc"},{"id":"tursodatabase/turso/storage-format"},{"id":"tursodatabase/turso/debugging"},{"id":"tursodatabase/turso/yield-injections"},{"id":"tursodatabase/turso/memory-benchmark"},{"id":"tursodatabase/agent-skills/turso-db"},{"id":"itechmeat/llm-code/turso"},{"id":"tursodatabase/turso/pr-workflow"},{"id":"tursodatabase/turso/code-quality"},{"id":"tursodatabase/turso/differential-fuzzer"}]},"slug":{"owner":"tursodatabase","repo":"turso","skill":"transaction-correctness"},"version":"e7b21267"}