Turso: The SQLite-Compatible Database Rewritten in Rust — MVCC, Async I/O, Vector Search, and an MCP Server
Turso is an in-process SQL database written from scratch in Rust, compatible with SQLite's SQL dialect, file format, and C API. It adds MVCC for concurrent writes, native async I/O with io_uring, built-in vector search, and an MCP server mode. Here is what it is, how it differs from SQLite and libSQL, and how to get started.
SQLite is one of the most deployed pieces of software in human history. It runs in every iPhone, every Android phone, in Firefox, in Python's standard library, in hundreds of millions of applications. It is reliable, fast, self-contained, and runs entirely in-process — no server required.
It also has a constraint baked into its architecture: one writer at a time. Every write acquires an exclusive lock. Readers can run concurrently with each other but not with writers. For most applications this is fine. For modern workloads — agentic apps, serverless functions, high-throughput APIs — it is a ceiling.
Turso is a ground-up rewrite of SQLite in Rust, designed to lift that ceiling without abandoning what made SQLite great. Same SQL dialect. Same file format. Same C API. But with MVCC concurrent writes, native async I/O, built-in vector search, change data capture, and an MCP server mode for AI agents.
It has 20,000+ GitHub stars, 253 contributors, and is currently in beta.
What Turso Is — and What It Is Not
Turso is not a fork. This is the first thing to understand, because Turso also makes libSQL (which is a fork of SQLite, in C), and the naming can be confusing.
libSQL — Turso's open-source fork of SQLite in C. Powers Turso Cloud today. Production-ready. If you need SQLite compatibility in production now, this is the path.
Turso Database — A complete rewrite of SQLite from scratch in Rust. Beta. The long-term direction the company is building toward. Cannot easily add certain features in a fork (the WAL layer, the VDBE, the concurrency model) without a rewrite, so they rewrote it.
The motivation for the rewrite is architectural. SQLite's single-writer model, its synchronous I/O, and its C codebase are all structural constraints that a fork can paper over but not fundamentally change. Turso starts from first principles in Rust, which allows:
An async-first I/O layer (io_uring on Linux)
MVCC for true concurrent writes
Vector search as a first-class primitive, not an extension
A cleaner architecture for features like CDC and incremental computation
The Feature Set
SQLite Compatibility
Turso targets compatibility with SQLite's SQL dialect, file format, and C API. A database file created with SQLite opens in Turso. SQL that runs in SQLite runs in Turso. The C API that SQLite exposes — used by virtually every language binding — is replicated.
This compatibility is the core value proposition. You do not have to rewrite your application to adopt Turso. You change the library.
The detailed compatibility matrix is tracked in COMPAT.md in the repository. Not every SQLite feature is implemented yet — this is beta software — but the gap is narrowing quickly.
The single most important structural addition. SQLite allows only one concurrent writer. Turso implements BEGIN CONCURRENT with multi-version concurrency control (MVCC), allowing multiple transactions to write simultaneously without blocking each other or blocking readers.
How MVCC works in Turso: each transaction sees a snapshot of the database at the moment it starts. Writers operate on their own version of the data. At commit time, Turso checks for conflicts — if two transactions modified the same rows, one will retry. If they touched different data, both commit successfully.
For workloads with many concurrent writes — REST APIs, serverless functions, agentic systems with multiple parallel agents — this is the difference between "SQLite is a bottleneck" and "SQLite scales for this use case."
Native Async I/O (io_uring)
Traditional database I/O blocks the thread waiting for disk operations. Turso's I/O layer is async-first, with io_uring support on Linux — the kernel interface that allows batching I/O operations and receiving completions asynchronously, dramatically reducing syscall overhead for I/O-heavy workloads.
This makes Turso particularly suited to serverless and edge environments where blocking I/O is expensive, and to high-throughput applications where disk I/O is a bottleneck.
Built-in Vector Search
Turso includes vector similarity search as a first-class database feature — no extension required. Store embeddings as vector columns, query by cosine or L2 distance, build retrieval pipelines that live entirely inside the database.
This is directly useful for AI applications: RAG pipelines, semantic search, embedding-based recommendations, and any workload that stores model outputs alongside structured data. Having the vector index inside the same database that holds the rest of your application data eliminates a class of integration complexity that arises when vector storage and relational storage are separate services.
Vector indexing (for fast approximate search, similar to libSQL's vector search) is on the roadmap as a near-term addition to the current exact search implementation.
Change Data Capture (CDC)
CDC streams database changes in real time — every insert, update, and delete — to downstream consumers. This enables event-driven architectures, real-time sync to secondary systems, audit logging, and reactive UIs without polling.
For agentic applications where multiple agents need to react to changes made by other agents, CDC is a foundational primitive.
Full-Text Search
Powered by tantivy — a fast, Rust-native full-text search library comparable to Lucene. Full-text search inside the database, no Elasticsearch or external search service required.
Experimental Features
Encryption at rest — protects data on disk without an external key management layer
Incremental computation via DBSP — incremental view maintenance and query subscriptions; instead of re-running a query every time you want results, Turso maintains the result set incrementally as data changes
Multi-process WAL coordination — via a .tshm sidecar file for cross-process WAL readers and writers, enabling patterns that SQLite's WAL mode doesn't support across process boundaries
Language Support
Turso ships bindings for:
Language
Status
Rust
Native (Turso is Rust)
JavaScript / TypeScript
npm package
Python
PyPI package
Go
Available
Java
Maven Central
.NET
NuGet package
WebAssembly
Supported — runs in the browser
The WebAssembly target is significant: it means Turso can run as an in-process database directly in a browser environment, following the same pattern as SQLite-in-WASM but with the Turso feature set.
MCP Server Mode
Turso can run as a Model Context Protocol server, exposing SQL query capabilities as agent tools. This means Claude, Cursor, Codex, or any MCP-aware agent can query a Turso database directly from an agent session — reading schema, running queries, and interpreting results without a separate API layer.
For AI applications where the agent needs database access — query logs, user data, application state, retrieved chunks for RAG — MCP server mode eliminates the need to build a custom tool wrapper. The database exposes itself as a tool.
One of the interesting engineering choices in Turso is its testing architecture. The team uses:
Deterministic Simulation Testing (DST) — a test suite that can replay any sequence of operations deterministically, including simulated failures, clock skew, and I/O errors. This is the same approach used by FoundationDB and TigerBeetle. DST finds bugs that only appear under specific timing conditions — conditions that are nearly impossible to reproduce with conventional tests.
Antithesis — an external testing platform that runs the database under extreme fault injection to find correctness issues. Turso is one of the first open source databases to use Antithesis for ongoing correctness validation.
DIRT (Database-Integrated Random Testing) — a published research technique (DBTest '26 paper) for randomly generating and validating SQL operations against the database.
The testing rigor is notable for a beta-stage project. The team's stated goal is SQLite-level reliability — a high bar — and the investment in formal and property-based testing reflects that.
How It Compares
Feature
SQLite
libSQL
Turso
Language
C
C (fork)
Rust (rewrite)
Concurrent writes
No (single writer)
Limited
Yes (MVCC)
Async I/O
No
No
Yes (io_uring)
Vector search
Extension only
Yes (extension)
Built-in
CDC
No
No
Yes
Full-text search
FTS5 extension
FTS5 extension
tantivy (built-in)
MCP server mode
No
No
Yes
Production status
Stable (decades)
Stable
Beta
File format compat
—
SQLite
SQLite
The production-readiness column matters. SQLite is the most tested database in existence. Turso is beta. For most applications today, the right answer is still SQLite or libSQL for production, with Turso as the forward path to watch. For new projects that specifically need MVCC, async I/O, or vector search in-process, Turso is worth evaluating now.
Getting Started
Rust:
toml
[dependencies]turso = "0.7"
JavaScript:
bash
npm install @tursodatabase/turso
typescript
import { createClient } from"@tursodatabase/turso";
const client = createClient({ url: "file:./app.db" });
await client.execute("CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT)");
await client.execute("INSERT INTO users VALUES (1, 'Alice')");
const result = await client.execute("SELECT * FROM users");
Python:
bash
pip install turso
python
import turso
conn = turso.connect("app.db")
conn.execute("CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT)")
conn.execute("INSERT INTO users VALUES (1, 'Alice')")
rows = conn.execute("SELECT * FROM users").fetchall()
The team notes that Turso powers production deployments at Turso Cloud (their own managed database product), Kin (an AI assistant), and Spice.ai (a data and AI platform). These are real production workloads, not just internal demos — though the team continues to recommend caution for mission-critical applications and independent backups until they are confident the SQLite-level reliability bar is met.
