SQLite is, by most measures, the most deployed database engine on the planet. It ships inside every phone, browser, operating system and countless embedded devices. It is rock-solid, exhaustively tested, and written in portable C. So why would anyone rewrite it in Rust?
That is exactly what the team at Turso set out to do with Limbo (now developed as Turso Database): a complete, from-scratch reimplementation of SQLite in Rust, aiming for full on-disk and SQL compatibility while modernizing the parts of SQLite that show their age.
Why Rewrite Something That Works?
SQLite is open source, but it is famously not open contribution. The core team accepts no outside pull requests, and the test suite that gives SQLite its legendary reliability is partly proprietary. A clean-room rewrite under a permissive MIT license opens the door for the wider community to build on, extend and reshape the engine.
Beyond licensing, the rewrite is a chance to rethink decades-old design decisions:
Asynchronous I/O:
SQLite’s storage layer is fundamentally synchronous. Limbo is built around async I/O from the ground up, taking advantage of modern interfaces like io_uring on Linux to avoid blocking threads on disk access.
Memory safety: A database engine is exactly the kind of long-running, security-sensitive software where Rust’s ownership model pays for itself. Whole classes of memory bugs that require constant vigilance in C simply do not compile in Rust.
Embeddable everywhere: The project targets the same niche SQLite owns (running in-process, with no server) while also compiling to WebAssembly so the same engine can run in the browser.
Deterministic Simulation Testing
The most interesting part of the project, for me, is not the language at all. It is the testing strategy. SQLite’s reliability comes from an enormous, hand-built test corpus accumulated over twenty years. Catching up on that is a non-starter.
Instead, Limbo leans on Deterministic Simulation Testing (DST), the same approach popularized by FoundationDB and TigerBeetle. The entire engine runs against a simulated, fully deterministic environment where I/O, scheduling and faults are controlled by the test harness. Because every run is reproducible from a seed, the simulator can inject crashes, partial writes and disk failures, then replay the exact sequence that triggered a bug. It is a way to buy a lot of the confidence SQLite earned the slow way.
Should You Use It Today?
Probably not in production, and the team is upfront about that. Reaching genuine compatibility with SQLite, in both behavior and on-disk format, across every edge case the original handles is a multi-year undertaking. SQLite’s reputation was not built overnight, and matching it is a high bar.
But that is rather the point. This is less about replacing SQLite tomorrow and more about exploring what an embedded database designed for today’s hardware and today’s safety expectations could look like.
How We Use SQLite at Birdhouse
This topic is close to home. At Birdhouse we rely on SQLite primarily for mobile development, where its zero-config, in-process design is a natural fit. It gives our apps a fast, reliable local store that works offline and syncs when a connection is available, without the overhead of running a separate database server on-device. That is exactly the niche a Rust rewrite is aiming to modernize, which is why a faster, safer, async-first engine in the same shape is so appealing to us.
Conclusion
Rewriting SQLite in Rust sounds, at first, like a textbook case of “rewrite-it-in-Rust” enthusiasm. Look closer and it is a thoughtful project: async-first I/O, a permissive license that invites contribution, and a testing philosophy borrowed from the most paranoid corners of the database world. Whether or not it ever dethrones the original, it is one of the more exciting things happening in the Rust ecosystem, and a project I will be keeping a close eye on.