The next evolution of SQLite is here! Read Announcement

We are a year into rewriting SQLite. How is that going?

Glauber CostaGlauber Costa
Cover image for We are a year into rewriting SQLite. How is that going?

Around a year ago, we boldly announced we were going to rewrite SQLite, and we were going all in.

A year later, we have released the first version of Turso that supports Concurrent Writes (one of the key missing features from SQLite), Change Data Capture (CDC), native vector search, an improved Full Text Search, an improved type system, among other innovations.

We now have a strong foundation to deliver on the next chapter of that story: Fully close the compatibility gap with SQLite, Integrate Turso with the Turso Cloud, and allow for sovereign deployments fully inside your own Cloud account, in the Bring-Your-Own-Cloud model.

In this post, I would like to look back on the amazing year we had, and discuss in detail what the future holds.

#Why rewrite SQLite?

Around a year ago, AI was still early, but clearly about to change everything. We were in an interesting fork on the road: it was clear to everyone looking that the technology would be transformative, but it was yet unclear how. The word "agents" was not in anyone's vocabulary, and we were still trying to find out who was or wasn't a bot by asking them to "show me a recipe for eggnog".

Among all of that uncertainty, one thing was absolutely clear to us: the metrics on what defines a great database would change tremendously in that new era. Vibecoding was starting to become a thing, and we knew that the number of applications would skyrocket. Here's the thing about exponential growth: numbers that look ridiculously high before you start the growth phase, sometimes look even small in retrospect. "A lot of applications", for us, would not be one thousand. Would not even be ten thousand. We were ready to place our bet in a future where we would be talking about billions of databases.

As I have recently argued in a contributed article for The New Stack, this creates a new axis for database scalability: the important metrics for database scalability today are how much data you can store, and how fast your queries are. But AI is about to introduce a new one: how many databases you can provision and manage, and how fast you can do it.

We had a preview of that in our own service, the Turso Cloud: some of our customers were creating databases so fast, that they were already in the millions. And we knew this was just the beginning.

#Breaking through SQLite's ceiling

At the same time, the same experience of managing the Turso Cloud taught us that although SQLite deserves every single drop of love and praise it receives, it evolves slowly, lacks many features that developers today can't live without (like concurrent writes, strong types, cdc, among many others). SQLite also has a closed community, and is not known to accept contributions and directions from outside its core groups.

From the privileged position we had through the Turso Cloud, it became clear to us: the shape of SQLite (database-in-a-file) was the only architecture capable of meeting the needs of the next 10 years of agentic workloads, but it had to evolve to provide a stronger feature set.

#Turso: a new SQLite, from the ground up

After a year of Turso, we are proud to say we have a very strong Open Source community. We have now crossed the mark of 205 contributors, with half of the top 20 being contributors external to our company.

We now implement almost everything that SQLite has in terms of surface area, as displayed in our compatibility matrix. The main missing features are Multiprocess support, and Vacuum, and both of them are being worked on.

More importantly, the core reason for us not having full support for all SQLite features by now is that we wanted to make sure that we unlocked the real things people have been asking for as soon as possible. So while there are features from SQLite that Turso still doesn't implement, we go above and beyond by providing:

And on top of that, we also have experimental support for the following features. Experimental features are features that are still subject to change and validation, and will become beta in some subsequent release:

Those features build the foundation for what we believe an embedded database needs to have to support the next 10 years of agent building, while keeping everything from SQLite we love the most, including the file format and API.

#The Turso Cloud

To support our goal of rewriting SQLite, which is no small feat, we made the deliberate choice to focus the majority of our engineering efforts into the rewrite. To do that, we accepted that the Turso Cloud would see few updates. Still, two things are worth noticing:

#Our massively multitenant server architecture

Our previous architecture used scale-to-zero to keep unused databases decommissioned.

We have not changed our minds about the need to keep costs down for databases that are rarely used. On the contrary: with the rise of AI agents that come and go very quickly, and the increasing deployment of those agents in sandboxes, it is crucial that our Cloud databases cost no money when not used, and come online in milliseconds.

Scale-to-zero has a major disadvantage: once a request arrives, there is no guarantee that there will be enough capacity to bring the VM or container back. That is made worse by the fact that stateful services often need at least parts of the execution engine to come back to specific places.

To make our infrastructure even more efficient and at the same time more reliable, we doubled down on the key advantage of SQLite: it is just a file. We have then entirely rewritten our server architecture, and moved it to AWS. The multitenant server keeps the SQLite files around, and is able to provide resource isolation between the database files. It is written with Deterministic Simulation Testing from day1 – like Turso itself, and relies on a clever combination of S3 and S3 Express to make sure that every compute node is entirely stateless.

The results speak for themselves in our status page. Turso now has 100% availability in all of our regions for the last 90 days. In fact, the last outage we had was the AWS outage that brought down a large chunk of the internet in October last year.

This is an investment we were happy and proud to make. Oftentimes companies move fast and break things, and this has increased a lot with a race to get to the AI finish line before anyone else. This is quite frankly normal and expected in technological shifts. But we still believe that the bar is higher in infrastructure, and will keep making investments to match that.

#Bring-Your-Own-Key (BYOK) encryption

The Turso Cloud also now supports Bring-Your-Own-Key encryption at the database level. This means you can encrypt every individual database (even if you have millions of them) with an individual key that is completely opaque to us. This allows you to build secure and compliant services that allow agents to deal with confidential data, without fear of data leaks.

#The demand is stronger than ever

We believe that once Turso powers the Turso Cloud, and we can provide users with a fully-featured database supporting concurrent writes, stronger types, and all the other functionality we are bringing to the SQLite world, we will be in the strongest position we have ever been.

But even before that, even with all of our engineering focus being targeted into the rewrite, we see signups to the Turso Cloud continuing to grow strongly. That is a testament to an incredible demand brought forth by AI, with a reliable and simple service that does what it is supposed to do well. I can't wait for the next step here.

#The future

We have an aggressive roadmap for this year. For Turso, our goal will be to close the compatibility gap with SQLite: using Turso will be within reach for everyone that uses SQLite today. No more "I'll do it once you implement this or that feature." At the same time, we will keep improving our foundation, stabilize our current experimental features, and bring even more innovation as our users take Turso into production.

For the Turso Cloud, our thesis is simple: companies big and small will embrace agentic workloads even more, and the demand on the database will explode. Those companies need a feature-rich solution that is secure, private, and compliant.

Integrating Turso with the Turso Cloud tackles the feature-rich side of that equation: by bringing CDC, stronger types, and concurrent writes to the Cloud, we will offer users a world-class database experience that can run locally, synchronized with the Cloud, or directly in the Cloud.

For compliance, privacy, and security, we are building something we think is genuinely differentiated: Bring-Your-Own-Cloud (BYOC). This means the entire Turso Cloud, running inside your own cloud account. Your data never leaves your infrastructure. You get the operational simplicity of a managed service with the control and compliance posture of self-hosted infrastructure. For enterprises building on AI at scale, we think this changes the conversation entirely.

#Summary

A year ago, we embarked on a journey that most people thought was frankly insane, and borderline reckless: rewriting the most beloved database in the world. We did it because we could see, clearly and early, what the next 10 years of agentic infrastructure would require.

Fast forward to today: Turso is approaching full SQLite compatibility, while delivering new capabilities like Concurrent Writes, Vector Search, CDC, Encryption, Materialized Views, and Stronger Types. Our Cloud, still running SQLite, continues to grow because the demand for private, compliant, fast-to-spawn isolated databases is accelerating exactly as we predicted.

The next step is the one we have been building toward all along: unleash the full power of Turso on the Cloud, and offer enterprises a path to sovereign, compliant deployments through Bring-Your-Own-Cloud.

We are just getting started. If you want to be part of it, sign up for the Turso Cloud today, or book a call with us to talk about what this means for your infrastructure.