Upcoming changes to the Turso Platform and Roadmap

Last month, we shared our vision for the future of SQLite with the announcement of our complete rewrite in Rust. The response has been nothing short of extraordinary — we've seen the fastest-growing open source database project in recent memory, with thousands of developers excited to help build SQLite's next chapter.

This overwhelming embrace from the community has shown us that we're onto something bigger than we initially imagined. Developers aren't just interested in using a better SQLite — they want to help build it. To fully support this vision and accelerate development, we're making strategic changes to focus more of our resources on core database development while ensuring our cloud platform remains reliable and efficient.

If you want to understand the details better, and why we believe going all-in on this rewrite is the right long term vision, check our detailed account.

#A commitment to our users

Before diving into the specifics, I want to make one thing absolutely clear: if you're a current paid customer of Turso, your existing production workloads will continue running exactly as they do today. If you are on a paid plan and using any feature we will discontinue, we will continue to support you. We understand that you depend on us to run your business, and we will honor that.

That said, we are making some changes to our platform that will affect new users and our free tier. Some of these changes will take effect immediately, while others will coincide with our previously teased pricing updates in about a month (spoiler alert: the hobby plan will have its price dropped to $4.99/month!). We want to give you advance notice so you can plan accordingly.

I have always taken pride in the high level of transparency and openness that we have with our community, and this announcement is part of that commitment.

#What's changing immediately

Some of our features will no longer be available to new users, effective immediately. Existing paid users will still be able to use them for the foreseeable.

#Simplifying our replication model

Our data shows that 70% of Turso users never create geographical replicas. While we strongly believe in bringing data close to users, we've learned that syncing the SQLite file itself to your API or device is often a better approach than edge replication.

For new users, we'll be discontinuing edge replicas. We believe we can build an even better solution for data locality in our new architecture, and we want to focus our energy there rather than maintaining the current implementation.

Also in-line with our internal data about where databases are created, and with the goal of simplifying our offering, the following Fly.io regions will be deprecated immediately: phx, den bos, atl, yyz, mia, ord, gdl, otp, gig, qro, eze, bog, hkg, jnb.

#Refocusing database capabilities

We'll be removing Multi-DB schemas and database ATTACH capabilities for new users. While both features have grown increasingly stable during their beta period and have found enthusiastic users, we believe we can make them even better with a fresh architecture. Rather than maintaining these features in their current form, we're choosing to reinvent them properly in our new implementation.

#What's changing in the near future

For some other changes, we still need to do some more preparation work. But we wanted to give everyone a heads up as soon as possible.

#Moving fully to AWS

While we originally planned to offer both Fly.io and AWS as options, maintaining infrastructure across multiple platforms would divide our attention at a crucial time. With enough advance notice, we will:

• Migrate all free tier users to AWS (which has no cold starts!)
• Existing paid users will be encouraged to migrate, but will not be required to.

Since our AWS offering is still beta, at this time, users should still make the informed choice between AWS and Fly.

#Renaming Limbo to Turso

What we initially called "Limbo" was always meant to be a temporary name. Given the incredible community response, we're making it official: this project will simply be called "Turso". We'll be working on clear communication to distinguish between Turso the core database and our cloud service.

#Other changes

Aside from feature changes, there are also other changes that we are applying that affect our company and software stack.

#Changes to our server implementation

As part of our reliability and scalability efforts, we've been developing a new massively multitenant version of our server, using Deterministic Simulation Testing. After careful consideration, we've decided to keep this new implementation closed source.

We believe this actually enables us to be more open where it matters most: everything that runs on the client will remain strictly open source. By drawing this clear boundary - client-side is open source, server-side is proprietary - we can build a sustainable business while maintaining our commitment to open source where it provides the most value to developers.

To be completely clear: this is an entirely new implementation, not a relicensing of libSQL's server components. Users who prefer an open-source path can still self-host using libSQL, as our new server uses the same protocols.

#Organizational changes to our company

Unfortunately, we also came to the conclusion that the composition of our team was not the best suited for a roadmap that involves writing a database from scratch, so we will have to let some people go. This is an extremely hard decision for us to make, because all of those people are tremendously good people who were doing a fantastic job, without whom we would not have brought Turso to where it is today. If you are hiring, I am ready to vouch for them, and I will be personally doing whatever I can to make sure they land in a good place.

#Join us for a community discussion

We know you'll have questions about these changes. We're hosting a community call on Discord 11:15 AM ET and X, 12:00PM ET tomorrow — January 22nd, where our team will be available to discuss these changes and answer your questions.

#Looking ahead

The enthusiasm we've seen from the community has shown us that developers aren't just interested in incremental improvements to SQLite — they want to help build its successor. While simplifying our platform may disappoint some users in the short term, we believe focusing our energy on this bigger vision will ultimately deliver more value to developers everywhere.

Our commitment to building a better SQLite remains unwavering, and we're incredibly grateful for the trust our community has placed in us. If you're excited about this vision, we'd love to have you join us. Check out our GitHub repository and be part of building the next generation of SQLite.