The next evolution of SQLite is here! Read Announcement

Turso v0.4.0 is now released with the following changes:
You can find the full changelog here.
To install Turso, see the getting started instructions.
MVCC, which lifts SQLite's single writer limitation allowing users to perform concurrent writes from multiple threads without locking the database, has had a major overhaul, now supporting indexes, checkpointing and recovery. MVCC is, however, still tagged as experimental so it is not recommended for production use and should be used with caution.
The main application visible change is that the --experimental-mvcc flag is now removed. MVCC support is always present, and you configure a database to use MVCC mode instead of the regular WAL with the journal_mode pragma as follows:
PRAGMA journal_mode = 'experimental_mvcc'
Please note that the MVCC mode is now stored in the SQLite database file header so that once you enable MVCC, Turso will always use the database in that mode.
Also note that the header change makes the database file incompatible with SQLite. If you try to open a MVCC-enabled SQLite database file, you will get the following error:
$ sqlite3 mvcc.db
SQLite version 3.49.1 2025-02-18 13:38:58
Enter ".help" for usage hints.
sqlite> .schema
Error: file is not a database
To switch from MVCC back to WAL mode, you can use the same pragma as follows:
PRAGMA journal_mode = 'wal'
And now the SQLite database file is again fully accessible with SQLite.
Sync has also been improved to support partial sync. It allows applications to start using a database without waiting for the entire database to download first. Partial sync is helpful for applications that require immediate responsiveness. Under the hood, the partial sync feature fetches database pages from the server on demand as the application uses them.
The application can also provide a bootstrap strategy to define a subset of the data that is synced to the client immediately before the application can access the database. The bootstrap strategy works through an arbitrary query that lets you flexibly select which pages the server should send to a fresh client. This approach helps warm up the partial database file from the start, avoiding the slow queries that would otherwise occur when the client first accesses unsynced data. The downside is the longer initial bootstrap sync time the application has to wait.
Partial sync also includes a prefetch strategy that speculatively downloads pages likely to be accessed soon, further reducing latency for typical access patterns. For persistence, partial sync currently requires Linux due to its reliance on sparse file support. However, in-memory mode is supported everywhere, including browsers, making partial sync accessible across a wide range of environments.
Sync is now also available in the Python and Go SDKs where it was before only available in the JavaScript SDK.
For more details, see the documentation.
The Python SDK now offers an aiosqlite-compatible asynchronous API, in addition to the standard SQLite-compatible API that ships with Python itself.
Large queries that exceed the default page cache size are now supported by properly spilling dirty pages to disk. You can also configure the page cache size via PRAGMA cache_size = n. This improvement is needed to run large queries well out of the box.
Support for the ANALYZE and ANALYZE [table] commands has been added. These commands scan tables and populate the sqlite_stat1 table with metadata used by the query optimizer to choose better join orders and generate more efficient query plans. Early results from TPC-H benchmarks are promising as performance work continues.
Join performance on non-indexed keys has been improved with a new join algorithm and data structure. Instead of falling back to building ephemeral B-tree indexes or performing full nested scans as SQLite does, Turso now uses a disk-spilling hash table for large queries—significantly boosting join efficiency on non-indexed columns.