Turso: The SQLite-Compatible Database Rewritten in Rust — MVCC, Async I/O, Vector Search, and an MCP Server

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.

BEGIN CONCURRENT + MVCC

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:

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.

See the Turso documentation for MCP server setup.

How Testing Works

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

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:

[dependencies]
turso = "0.7"

JavaScript:

npm install @tursodatabase/turso

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:

pip install turso

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()

CLI:

turso shell app.db

Full documentation is in the Turso Database Manual.

Who Is Using It

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.

Quick-Start Summary

1. Star and clone: github.com/tursodatabase/turso
2. Install the package for your language (Rust crate, npm, PyPI, Maven, NuGet)
3. Use it like SQLite — the SQL and API are compatible
4. Use BEGIN CONCURRENT for workloads that need concurrent writes
5. Enable vector search for AI/embedding workloads without a separate vector database
6. Try MCP server mode to give AI agents direct SQL access

Related Reading

• What Is MCP (Model Context Protocol)
• AI and Climate Change: AI's Energy Footprint vs. Climate Solutions
• AI Agents: The Complete Guide to Goal-Mode Workflows
• What Is Transformer Architecture