Turso v0.7.0Register now for early access to concurrent writes in the Turso Cloud. Join the waitlist

Jul 13, 2026

Turso v0.7.0<br>Pekka Enberg

Today we are announcing the release of Turso 0.7. Where 0.6 was the release that brought Turso to parity with the major features of SQLite, 0.7 is about making the engine faster and more robust under real-life workloads. Turso now runs in production at multiple organizations, and while we are not yet at 1.0, we feel comfortable enough to officially drop the beta warning. Of course, Turso is still under active development, and some features are explicitly marked experimental. Our bar is SQLite-level reliability, one of the most rigorously tested pieces of software in the world. Until we get there, we recommend keeping regular independent backups, which is good practice for any database.

In this release, concurrent writes through the MVCC engine are significantly faster, recovery is leaner, and the memory cost of keeping multiple row versions around is much lower. A lot of work also went into ensuring Turso behaves well as a library embedded in someone else's process, as part of our integration with Turso Cloud. The core engine no longer blocks the calling thread on I/O, no longer aborts when it runs out of memory, and yields the CPU during long operations so a busy statement cannot starve other connections sharing the same runtime. Beyond the engine, 0.7 improves the SQL interface with sequences, ICU collations, ordered-set aggregates, and the groundwork for window functions, and it brings a SQLite-compatible .NET provider and full-text search to the Python SDK.

#Core

A lot of 0.7 went into making the engine behave well as a library embedded in someone else's process: never blocking the calling thread, never aborting on allocation failure, and staying responsive during long operations.

#CPU yielding

Long-running operations no longer monopolize the thread. Several MVCC code paths that previously ran a loop to completion now yield cooperatively after a bounded amount of work, including serializing a large transaction (#7033, Pere Diaz Bou), collecting rows during a checkpoint (#7248, Pere Diaz Bou), and garbage collection (#7318, Pere Diaz Bou). Those early yields reused the existing I/O suspension path, so the caller could not tell a deliberate CPU yield apart from waiting on I/O. A dedicated StepResult::Yield now makes yielding first-class, surfacing an explicit suspension to every step loop in the workspace (#7458, Nikita Sivukhin). Together this lets a busy statement give the CPU back so it cannot starve other connections sharing the same runtime.

#No more blocking I/O

We removed the internal io.block and wait_for_completion calls from the core engine. These were problematic in two settings: on platforms like WASM where I/O is driven externally by the runtime, and for embedders running Turso in a multi-tenant async context, where a blocking call stalls unrelated work. The engine now yields on a pending completion instead of parking the thread, including the cache-spilling path inside Pager::read_page that previously had no choice but to block (#7277, #7446, Preston Thorpe). A last blocking spill in the page cache, which could hang the WASM build running on OPFS, was eliminated late in the cycle (#7821, Nikita Sivukhin).

#Memory limits

Turso is moving to fallible allocation throughout the core so that running out of memory surfaces as an error rather than a panic. This is what lets one tenant hit a memory limit without taking down a server shared with others. The work starts with a SQLite-style global allocator and a set of extension traits for allocation-aware, fallible APIs (#6853, Pedro Muniz), and a proc-macro out-of-memory fault injector that annotates allocation sites so the failure paths are actually exercised under test (#7517, Pedro Muniz). Hot data structures including the sorter, hash table, bitset, and skiplist were migrated to propagate allocation errors instead of aborting, and the effort has since spread through the translator, the VDBE, and the schema layer, making statement translation, schema cloning, and schema bootstrap allocation-fallible (#7715, #7734, #7746, #7790, Pedro Muniz). The MVCC version store can also run on a custom allocator (#7632, Pedro Muniz).

#Page cache as a soft limit

The page cache now treats its configured capacity as a soft limit, matching SQLite. Previously, reading or allocating a page while every cache-resident page was pinned, held by a cursor, or dirty and unspillable failed the statement with a busy or cache-full error. The pager now spills dirty pages to the WAL first to make room, and when nothing can be evicted it admits the page over capacity and drains the excess back under the limit as pages become evictable again (#7804, Jussi Saurio).

#One write statement at a time

Because Turso's I/O is asynchronous, a write statement can be suspended mid-flight — and if the application abandons it, the...