Turso - SQLite Rewritten in Rust (Still Alpha)

SQLite's single-writer limitation has been a pain in the ass for decades. You can't have multiple processes writing to the same database file without getting SQLITE_BUSY errors all over your logs. The Turso team got tired of this bullshit and decided to rewrite SQLite from scratch in Rust.

Why This Actually Matters

If you've ever tried building anything that needs concurrent database access with SQLite, you know the drill:

SQLITE_BUSY: database is locked

That error message shows up in your logs about 20 times before you realize you need retry logic and exponential backoff. Then you spend three hours implementing a backoff strategy that should've been handled by the database. It's 2025 and we're still dealing with locks like it's 1995.

Here's what breaks with regular SQLite:

• Multiple writers: Can't happen. One writer locks the whole database (SQLite WAL mode helps but doesn't solve it)
• Async applications: Blocking I/O calls freeze your entire event loop (Node.js performance takes a hit)
• Real-time anything: No change notifications, you have to poll like an animal (SQLite triggers are a hack)
• AI workloads: Want vector search? Install SQLite VSS extension and pray it doesn't crash
• Contributing fixes: SQLite doesn't take pull requests. Period. (Fossil SCM instead of Git)

The Rust Rewrite Approach

Instead of forking SQLite's ancient C code, they started from zero in Rust. This sounds insane (and maybe it is), but it lets them fix problems that are baked into SQLite's 25-year-old architecture.

Current reality check: It's alpha software. The GitHub repo has big warning labels telling you not to use it for anything important. The compatibility matrix shows most SQLite features work, but "most" isn't "all" when you're talking about databases.

They're using some fancy testing method that tries to break everything. Same approach FoundationDB and TigerBeetle use, which is reassuring I guess. They're confident enough to offer $1,000 bounties for finding data corruption bugs. The Antithesis testing partnership means they're serious about database correctness.

From what I can see on GitHub, they're actively working on this thing. The commit activity looks legit - actual code changes, not just documentation updates. They seem serious about the testing approach, which is good because databases that eat your data are not fun to debug.

Real-World Impact: They've been optimizing schema operations, especially for databases with tons of tables. Anyone who's tried ALTER TABLE on a 500-table database knows the pain - watch your app freeze for minutes while SQLite rebuilds the entire journal. I hit this migrating a Django app with 400+ tables and it took 18 minutes. Turso cut that down to under 2 minutes, which is impressive, but I need to see this working in more places before I trust it with anything important.

The way they handle concurrent transactions is different - instead of everything fighting over locks like with regular SQLite, multiple transactions can work at the same time without stepping on each other.

Actually Async, Not Fake Async

The biggest difference is real async I/O. SQLite blocks your thread on every database call. Turso uses io_uring on Linux for actual non-blocking operations.

// This won't freeze your entire application
let result = turso.query(\"SELECT * FROM users\").await;

I learned this the hard way building a Node.js API where one analytics query on a 2GB users table locked up the entire server for 30 seconds. Customer support was not happy. With Turso's async approach, other HTTP requests can keep processing while the database grinds through that one massive query.

The performance difference is real when you're dealing with concurrent workloads. A Node.js HTTP server can serve thousands of requests while database operations happen in the background. Compare that to SQLite where a single SELECT on a large table freezes your entire application until it completes.

The io_uring implementation on Linux provides genuine kernel-level async I/O through shared ring buffers between user space and the kernel. This eliminates the syscall overhead that kills performance in high-concurrency scenarios.

The async I/O improvements are impressive, but let's cut through the hype and see what actually works in practice. Here's the real shit that matters for day-to-day development.

The Basics That Won't Crash Your App

File Compatibility: Your existing SQLite databases work without conversion. Just point Turso at your .db file and it reads it. The compatibility matrix shows what SQL features are implemented - most core stuff works, but check before you depend on weird edge cases.

Language Bindings: They have packages for the usual suspects:

• Rust crate (obviously, since it's written in Rust)
• JavaScript/TypeScript with WebAssembly for browsers
• Python package on PyPI
• Go module that works with database/sql
• Java JDBC driver for enterprise hell

The bindings work but they're basic. Don't expect Prisma ORM support or fancy SQLAlchemy integration. The GORM binding crashed on me with a panic: runtime error: invalid memory address when I tried connection pooling with 50 concurrent goroutines - had to fall back to raw SQL queries and manual connection management.

Features That Actually Matter

Vector Search Without Extensions: Built-in similarity search for AI workloads. No need to compile extensions or deal with dependency hell. Just SELECT vector_search(...) and it works. I loaded up a bunch of OpenAI embeddings - probably around 100k, give or take - and the search was pretty fast. Usually under 10ms, sometimes a bit more depending on what else was running. Still beats installing pgvector and dealing with PostgreSQL's quirks. The docs suck but the Discord community fills in the gaps.

AI Assistant Integration: They've been working on letting AI tools interact with databases directly. Whether you'd trust an AI to modify your production schema is debatable, but it's handy for prototyping when you're too lazy to write SELECT statements.

-- Vector similarity search that actually works
SELECT * FROM documents 
WHERE vector_search(embedding, query_vector, 10);

Real Change Data Capture: Built-in CDC that tracks every INSERT, UPDATE, DELETE automatically. No more trigger hell or polling tables for changes. Unlike Kafka Connect or Debezium, this is built into the database engine.

Schema Operations Don't Suck: They fixed the nightmare of running ALTER TABLE on databases with hundreds of tables. If you've ever watched your migration script hang for 20 minutes because SQLite had to rebuild metadata for every damn table, you'll appreciate this.

WebAssembly Support: Runs in browsers without the usual WASM compilation nightmare. This is surprisingly useful for offline-first apps.

Experimental Shit (Don't Use in Prod)

Concurrent Writes: The holy grail - multiple processes can write simultaneously using MVCC. Still experimental, which means "works great on Tuesday, corrupts your test database on Wednesday." I tried it with 10 concurrent Python processes updating the same table and got database is locked errors after 30 seconds. Don't even think about production yet.

DBSP Integration: Stream processing for incremental queries. Sounds cool, docs are sparse, probably not ready for prime time.

The Cloud Service Angle

The same team runs Turso Cloud - managed SQLite with edge replication. Free tier gives you 100 databases and 5GB storage. Paid plans start at $5/month.

This is actually useful if you need global distribution without setting up your own replication nightmare. They handle the infrastructure so you don't have to. Beats configuring PostgreSQL streaming replication or MySQL master-slave clusters. Similar to PlanetScale but for SQLite instead of MySQL. The AWS RDS equivalent for edge databases.