From v0.7 to v0.8: How group commit changed Turso's tail latency

Turso v0.8 improves concurrent-write performance by adding group commit to its MVCC implementation, addressing a v0.7 bottleneck in which every transaction separately wrote to the logical log and waited for an expensive fsync operation while holding the commit lock. Turso’s MVCC keeps row versions in memory, validates write conflicts at commit time, records only changed rows in a logical log, and later checkpoints data into a standard SQLite-format database file. Under group commit, transactions enqueue their log records and receive tickets, while one leader writes a batch of queued records and performs a single fsync that makes the entire group durable without changing visibility or durability guarantees. Benchmarks at 1,000 transactions per second showed that v0.7 could develop multi-second or worse tail latencies because flushes accumulated, whereas v0.8 reduced median latency to roughly 1 ms and achieved substantially lower p99.9 latency than SQLite across tested connection counts. The improvement is strongest when concurrent transactions update mostly distinct rows, while workloads that repeatedly modify the same rows can still suffer from row-level contention and write-write conflicts, making SQLite’s single-writer approach potentially comparable for those cases.

No tracked trend matches for this post yet.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.