tursodatabase/turso: SQLite rewritten in Rust (formerly Limbo)

A from-scratch rewrite of SQLite, in Rust

Turso Database is an in-process SQL database written in Rust that aims to be wire-compatible with SQLite: same SQL dialect, same on-disk file format, same C API. The difference is underneath. Where SQLite is a synchronous, single-writer C library tuned for a world of local disks, Turso rebuilds the engine around asynchronous I/O and multi-version concurrency control, the things serverless and edge runtimes have been asking SQLite for and not getting. If you have used SQLite, the surface is meant to feel identical; the engine you are talking to is new code.

If you bookmarked “Limbo,” this is it

This project was called Limbo until recently. The name changed to Turso Database, and the reason is worth knowing, because it tells you how seriously to take it. Turso the company has long evolved SQLite through libSQL, a fork. The Rust rewrite started as “an unassuming experiment,” in the team’s own words, and worked well enough that it replaced libSQL as the company’s intended direction. So Turso Database is not a side project that lost its name. It is the bet the company moved its future onto. The old tursodatabase/limbo URL now points here.

What the rewrite actually buys you

The compatibility is the table stakes. The reasons to care are the parts SQLite does not have:

• BEGIN CONCURRENT with MVCC. SQLite serializes writers. Turso uses multi-version concurrency control so multiple writers can make progress, which is the single biggest pain point for SQLite under concurrent load.
• Asynchronous I/O on Linux via io_uring. This is the original thesis of the project: a database that does not block a thread on every disk call, which is what makes it a fit for serverless runtimes where a blocked thread is wasted budget.
• Change data capture (CDC) for tracking database changes in real time, built in rather than bolted on with triggers.
• A built-in MCP server. tursodb your.db --mcp exposes the database to AI assistants over the Model Context Protocol, with tools for querying, inserting, and schema changes. Most databases need a separate adapter for this; Turso ships it in the CLI.
• Vector support for exact search, plus a cluster of features the project still marks experimental: encryption at rest, full-text search via tantivy, and incremental view maintenance via DBSP.

Install

The CLI ships as a one-line installer, and the database is available as a native library across most ecosystems.

Command line:

curl --proto '=https' --tlsv1.2 -LsSf \
  https://github.com/tursodatabase/turso/releases/latest/download/turso_cli-installer.sh | sh

Rust:

cargo add turso

JavaScript:

npm i @tursodatabase/database

Python:

uv pip install pyturso

Go bindings (turso.tech/database/tursogo), Java via JDBC, and .NET are also published. Note the package names do not all match the repository name, a direct consequence of the rename.

First run

The CLI opens an interactive shell, tursodb, that behaves like the sqlite3 shell:

$ tursodb
Turso
Enter ".help" for usage hints.
Connected to a transient in-memory database.
turso> CREATE TABLE users (id INT, username TEXT);
turso> INSERT INTO users VALUES (1, 'alice');
turso> SELECT * FROM users;
1|alice

From Rust, the API is async by design, which is the whole point:

let db = Builder::new_local("sqlite.db").build().await?;
let conn = db.connect()?;
let res = conn.query("SELECT * FROM users", ()).await?;

The caveat that matters: it is still BETA

This is where reading past the feature list pays off. Turso Database is explicitly in BETA, and the maintainers say so plainly: their bar is “SQLite-level reliability,” and until they are confident it clears that bar, they recommend caution for anything mission-critical. That is an unusually honest position for a project with 19,000 stars (as of 2026-06). It does run in production today, including Turso Cloud and a few named products, and it is hammered by a native deterministic simulation testing suite plus Antithesis. But “powers some production apps” and “ready to replace SQLite under your production app” are different claims, and the team is careful not to conflate them.

There is also a fork in the road that confuses newcomers. Turso ships two SQLite-evolution projects. libSQL is the fork, and it is production ready now. Turso Database is the rewrite, more ambitious and not there yet. If you need something dependable this quarter, that distinction decides which one you pick.

Turso versus the alternatives

A stats table is misleading across these projects because they answer different questions, so compare on positioning instead:

Project	Approach	Language	Maturity	Best at
Turso Database	rewrite of SQLite	Rust	BETA	async, concurrent writes, edge
SQLite	the original	C	rock solid	embedded everything
libSQL	fork of SQLite	C	production ready	SQLite plus server features today
DuckDB	new engine	C++	production ready	analytical (OLAP) queries

SQLite remains the safe default for embedded storage and has decades of hardening Turso cannot match yet. libSQL is the pragmatic choice if you want SQLite-plus today from the same team. DuckDB is not really a competitor: it is columnar and built for analytics, where Turso, like SQLite, is row-oriented and transactional. Turso’s distinct claim is async, concurrent-write SQLite for runtimes that SQLite was never shaped for.

Where it fits, and where it does not

Reach for Turso when you want SQLite semantics with async, non-blocking I/O, better write concurrency, or a browser build through WebAssembly, and when you can absorb the risk of a young engine. Hold off when you need SQLite’s proven durability under your most important data this year; there, SQLite or libSQL is the responsible call, and you can revisit Turso as it converges on its reliability bar. For the broader momentum behind Rust systems projects like this one, see what is trending in Rust.

FAQ

Is this the same project as Limbo? Yes. Limbo was renamed to Turso Database. The tursodatabase/limbo URL redirects here, and the published packages now use the turso naming.

Is Turso ready for production? It runs in production for some apps, including Turso Cloud, but the maintainers keep it in BETA and recommend caution for mission-critical use until it reaches SQLite-level reliability.

How is Turso different from libSQL? libSQL evolves SQLite through a fork and is production ready. Turso Database is a from-scratch Rust rewrite and is the team’s intended long-term direction, but it is not production ready yet.

Can I use my existing SQLite database? That is the design goal: Turso keeps SQLite’s file format, SQL dialect, and C API, so the data and queries you already have are meant to carry over.