We will rewrite SQLite. And we are going all-in
Glauber Costa
If you're a Turso user concerned about how these changes affect you, see our detailed platform announcement.
Two years ago, we made a bet: SQLite, the most successful database in history, could be even better. Not just marginally better – fundamentally better. We believed that the missing piece wasn't technical, but human: SQLite needed an open contribution model that would give developers everywhere a seat at the table.
This vision led us to fork SQLite, creating libSQL. After carefully weighing our options – including a complete rewrite – we chose to fork because it seemed like the fastest path to impact. We then built Turso, our cloud service, to fund that development.
By any conventional measure, libSQL has been a remarkable success. After an initial burst of excitement that brought us 2,000 GitHub stars in a week, we've grown steadily to over 13,000 stars and more than 80 contributors. The project gave us the technical foundation to build the Turso platform that developers love.
#But something was missing.
Independent usage of libSQL as a SQLite replacement remained low. Most users came for SQLite-over-the-wire, not core database improvements. While we saw plenty of contributions to the remote execution code, deep contributions to the core database were rare. In hindsight, while we succeeded in building a great open source project around SQLite, we hadn't achieved our original goal: evolving the core of the database through community contribution.
Were we disappointed? Not at all. We'd built a product that developers genuinely loved, backed by a warm and high-quality community. As they say, shoot for the stars, you might hit the moon – and we were content with our lunar landing.
#Then something unexpected happened.
My cofounder Pekka started a quiet experiment: What if we had taken the road not traveled? What if, instead of forking SQLite, we rewrote it from scratch in Rust with a modern, async architecture? He worked on this almost silently, with only occasional mentions on his personal X account.
For those just learning about this, we detailed the technical foundations in our announcement blog, but here's what makes this rewrite special:
- Reliability at its core: SQLite's sterling reputation for reliability isn't negotiable. Our rewrite employs Deterministic Simulation Testing at the core level and ships with a simulator, ensuring we catch even the most obscure edge cases.
- Next-level testing: Through our partnership with Antithesis, we're using their Deterministic hypervisor to catch bugs that even our simulator might miss – including bugs in the simulator itself.
- Modern architecture: The rewrite is async-first, offering an asynchronous interface ready for modern systems like Linux's
io_uring. - True compatibility: We maintain full compatibility with SQLite at both file and language levels, with tests that compare bytecode generation between SQLite and our implementation for random inputs.
Even without fanfare, this experiment attracted interest. The project organically grew to 1,000 GitHub stars and 30 contributors. More importantly, we started seeing the kind of deep, foundational contributions we'd dreamed of – work so impressive that we hired two contributors to work on our server infrastructure.
Seeing this momentum, we decided to make it official. We moved the project to our organization and wrote a blog post about it. No polish, no marketing push – we didn't even change its temporary codename, "Limbo." We just wanted to give it a more official home.
#Then something extraordinary happened:
- In just one week, we crossed 8,000 GitHub stars
- Our contributor count exploded, doubling from 32 to over 64
- At least three new contributors showed the kind of deep technical mastery that can reshape a project
- The community took initiative, with one contributor even getting it running in the browser
- ThePrimeagen's video on the project hit 188,000 views, with an overwhelmingly positive response
- For perhaps the first time in computer science history, even the Hackernews comment section was mostly supportive
- We even started receiving (many and good!) contributions from a person who is currently incarcerated
We spent a lot of time trying to understand why this resonated so powerfully. After talking with excited contributors, the answer became clear: libSQL proved our core thesis – SQLite could indeed be more, and an open community is key to making that happen.
But a fork, still tethered to its origin and moving cautiously, wasn't bold enough to generate the activation energy the community craved. A fresh, modern rewrite – unconstrained by legacy architecture – was what developers had been waiting for.
And something else became clear: our two years of work on libSQL hadn't been wasted. It proved to the community that we were the right stewards for this vision. We'd earned the trust needed to take this leap.
We must answer this call. After seeing this response, it would be almost negligent to stick to our original, conservative plan.
As a company, we are making changes and reworking our roadmap and offering to allow us to significantly ramp up resources to this rewrite. We'll do this with all the reverence and respect SQLite deserves, but with a clear mission: we will build the modern, open contribution evolution of SQLite, offering everyone in the industry a seat at the table.
