The Changelog: Software Development, Open Source - Turso is rewriting SQLite in Rust (Interview)

Episode Date: January 30, 2025

Glauber Costa, co-founder and CEO of Turso, joins us to discuss libSQL, Limbo, and how they're rewriting SQLite in Rust. We discuss their efforts with libSQL, the challenge of SQLite being in the public domain but not being open for contribution, their choice to rewrite everything with Limbo, how this all plays into the future of the Turso platform, how they test Limbo with Deterministic Simulation Testing (DST), and their plan to replace SQLite.

What's up, welcome back. This is the changelog. We feature the hackers, the leaders, and those replacing SQLite. Yes, today we're joined by Glauber Costa, co-founder and CEO of Terso. Terso is an open source distributed database powered by LibSQL, which is described as the open contribution fork of SQLite. We discussed their efforts with LibSQL, the challenge of SQLite being in the public domain and not having an opportunity for contribution, their choice to rewrite everything with Limbo,

how this all plays into the future of the Terso platform, how they test Limbo with deterministic simulation testing, also known as DST, and their plan to replace SQLite. A massive thank you to our friends and our partners over at Fly.io. Fly is the public cloud built for developers who ship. That's you, that's me, that's us. Over 3 million apps have launched on Fly, and you can too. Deploy your app in five minutes.

Learn more at fly.io. Okay, let's see what it takes to replace SQLite. Well, friends, before the show, I'm here with my good friend, David Shue, over at Retool. Now, David, I've known about Retool for a very long time. You've been working with us for many, many years. And speaking of many, many years, Brex is one of your oldest customers. You've been in business almost seven years. I think they've been a customer of yours for almost all those seven years, to my knowledge.

But share the story. What do you do for Brex? How does Brex leverage Retool? And why have they stayed with you all these years? So what's really interesting about Brex is that they are an extremely operational heavy company. And so for them, the quality of the internal tools is so important because you can imagine they have to deal with fraud. They have to deal with underwriting. They have to deal with so many problems. Basically, they have a giant with fraud, they have to deal with underwriting, they have to deal with so many problems, basically. They have a giant team internally, basically just using internal tools day in and day out. And so they have a very high bar for internal tools.

And when they first started, we were in the same YC batch, actually. We were both at Winter 17, and they were, yeah, I think maybe customer number five or something like that for us. I think DoorDash was a little bit before them, but they were pretty early. And the problem they had was they had so many internal tools they needed to go and build, but not enough time or engineers to go build all of them. And even if they did have the time or engineers, they wanted their engineers focused on building external facing software, because that is what would drive the business forward. Brex mobile app, for example, is awesome.

The Brex website, for example, is awesome. The Brex expense flow, all really, you know, really great external software. So they wanted their engineers focused on that as opposed to building internal CRUD UIs. And so that's why they came to us. And it was honestly a wonderful partnership. It has been for seven, eight years now. Today, I think Brex has probably around a thousand Retool apps they use in production. I want to say every week, which is awesome.

And their whole business effectively runs now on Retool. And we are so, so privileged to be a part of their journey. And to me, I think what's really cool about all this is that we've managed to allow them to move so fast. So whether it's launching new product lines, whether it's responding to customers faster, whatever it is, if they need an app for that, they can get an app for it in a day, which is a lot better than, you know, in six months or a year, for example, having to schlep through spreadsheets, et cetera. So I'm really, really proud of our partnership with Brex.

Okay, Retool is the best way to build, maintain, and deploy internal software, seamlessly connect to databases, build with elegant components, and customize with code, accelerate mundane tasks, and free up time for the work that really matters for you and your team. Learn more at retool.com. Start for free, book a demo. Again, retool.com. Thank you. So what would happen if you took SQLite, the most widely deployed database in the entire world, and you rewrote it in Rust with some new twists and new ideas? We are all going to find out because Globber, Costa, and his team at Terso are working on it. It's called Limbo. Globber, welcome to the Change Log.

Thank you. It's great to be here. It's great to have Adam here despite flu season hitting hard in this DeKoviak house. Oh, man. It sounds great, though, Adam. You sound great. Thank you. You mentioned you're on the tail end of the flu, but you don't sound like it. I've been trying so hard to sound better. So thank you.

Where should we start? I think this story goes back quite a ways. I remember LibSQL or LibSQL, which was a couple of years ago now, your guys' effort to create a different open source SQLite. I thought SQLite was open source and public domain. Can you tell that story? Oh, happy, happy to do that. And the story, in a sense, it's still the same story. So I think you hit the nail on the head there. It's just really how it started. I don't feel this is a completely different thing, what we're doing now. The story there is that we were using SQLite

in our company. So Pekka and I, Pekka is my co-founder, we founded a company for, if you happen to stumble upon it, just mentioning here by name called Chisel Strike. And it was in the API space. We were doing a bunch of things and we were using SQLite very heavily in that company. And the reasons we were using SQLite were reasons I think that a lot of your audience will understand and relate to. Look, you would just do npm install, the name of the package, and then everything's there. Your database is there. Everything is there. Everything works. You don't have to install anything. So SQLite for us always had this appeal of a database that is just always working, and then it can build stuff around it, and it's just always there. So there was always something that was very appealing to us.

However, we also stumbled upon this thing a little bit about SQLite not being open source. So let me address that. SQLite is a public domain software, which is technically a difference that doesn't matter, right? So I think only a lawyer would be concerned with like what is the difference between public domain and open source for all intents and purposes. It's the same difference between like the BSD license and the MIT license.

It's minor, nobody cares. I don't care. And I think nobody else does either. But SQLite is, according to their own website, by the way, this is something that they put in big bold letters in their website, open source. And again, I'm not claiming that they're wrong to say that. It's all good. Open source, but not open contribution.

So when people think of an open source project, there are two things that comes to your mind. And the first one is like the code is open and SQLite is that. But you also think about, you know, instinctively, well, you know, the code is open and SQLite is that. But you also think about, you know, instinctively, well, you know, the code is going to be on GitHub somehow. And then if I find an issue, I can go contribute to this project. And I have some source of ownership to the code, right? It's not just that I can see the code, I can also modify the code. So that's usually classically one of the tenets of open source. Now, SQLite is not like that.

The maintainers of SQLite, the creators of SQLite do not take contributions. This is not something that we are saying. This is something that they're saying. And yes, I mean, I think it happened in the past that people managed to contribute to SQLite in very special occasions. But it's not a project that is designed to take contributions from other people. So that is how SQLite is. We started running into a couple of hurdles with SQLite. Part of that is that we wanted to deploy our SQLite databases to the edge.

We wanted to deploy it in a way that was replicated. We wanted to do things like read replicas, and we wanted to put it to run on Cloudflare Workers and all things like that. And we considered this a good thing for our project. So, you know, and technically we knew we could do it. And for context here, like Pekka and I, we've been working together.

Pekka's my co-founder. We've been working together for 15 years now. We met each other when we were both working on the Linux kernel. Pekka was one of the maintainers. Each one of us worked in Linux for almost 10 years, the first five without knowing each other. I think we knew off each other, but we never met. And in the last five years, very closely to each other, where we developed a good friendship. After that, we actually joined a startup that also became a database company. We spent eight years doing that. So we felt like technically SQLite is all things considered pretty simple

given the scope of things that we used to do. So technically we can make the changes that we believe we can. And so let's just come up with our own version. And we saw at the time a lot of people dancing around the subject. That's what we can. And so let's just come up with our own version. And we saw at the time, a lot of people dancing around the subject. That's what we saw. So there were some projects like LighterFast, there were super interesting projects, Dequalite. We saw like lots of people trying to get SQLite to work as a distributed system. The problem that we saw with all of those projects is that they were all, again, dancing around the subject that SQLite cannot be changed.

So we're going to create layers and layers and layers around SQLite to help with that. And for us, technically, this is actually a pretty simple problem. You just have to change SQLite here, here, and here, and you're good to go. And I think the last piece of the puzzle, or maybe the two last pieces of the puzzle, number one is that we were very concerned with who's going to want to run our SQLite plus patches because SQLite is a very trusted project. So you make random modifications to SQLite. Everybody starts distrusting what you're doing. So we knew that, look, the solution to this problem is that we should just create an open contribution version of SQLite. Because now it's not like SQLite plus Fink.

It's its own project. And then people come to trust that there's one project. And with that, like the diagnosis that we had at the time is like, hey, SQLite is great code wise. The thing that is holding it back in our reading is exactly the fact that it cannot take advantage of the dynamism of, you know, the creativity of a truly open source community. So let's create that. And the last piece of the puzzle is that at the time, we were actually discussing how do we do this? And one of the puzzle is that at the time, we were actually discussing how do we do this? And one of the options was like, maybe we should just rewrite SQLite. And we had a lot of experience in our previous company, Scylla. Scylla was a reimplementation

of Apache Cassandra and C++, fully compatible. And maybe we over-indexed in the fears that we had going that route. We say, hey, the problem with Scylla is that it took a long time for us to put in the market. Now, SQLite is much smaller, so maybe we can do it. But, you know, maybe because we had just come from an experience where we wrote a database, we figured that forking was a better strategy. So at the time, our decision after much deliberation was we're not going to rewrite SQLite. We are going to fork it instead because, you know, the main advantage is that you have something tomorrow because you start from a code base that is already working. And then we're going to start making changes to that. So that was LibSQL.

Like LibSQL was essentially at the time, I mean, and the story of Limbo, if I had to tell the sanitized version in which the fork never existed, it would be the same up until this point. Because all of those things, like we were, you know, all of that is still valid. It's just that at the time, a year and a half ago, we decided the forking was the best alternative. And now, and I'm happy to go into the why, but now we decided to try, okay, what if we had done that, one of those options that we consider, what if we just rewrote it? And then when we put it out there, the results were, you know, I've never seen anything like that before. So just, that's the story. I think the public domain-ness of SQLite is unique. I think the not open to contribution is also quite unique. Very valid in the, in quotes, open source world. And even they say on this public domain page they have, where they say warranty of title. So if you are a company that needed something where you needed to be identified against the copyright infringement or anything happening inside this code base, it gets to be a little bit hairy

trying to use SQLite in unique ways beyond. So it kind of makes sense, some of the challenges you had, and maybe the fork made the most sense, but ultimately the rewrite seems to make the most sense because what you want is the attributes of what SQLite offers the world, to make the the most sense because what you want is the attributes of what sql offers the world but not the and i don't want to say like a negative thing because it's great

but it's it's dominated very well in the marketplace i mean it's used on mars i believe right this is not a market it has trillions of databases deployed right so yeah i mean like it's it's not and dr richard hip is a one of. We love him. We think he's an amazing person. But I think you are right, though, that the public domain-ness and the not open to contribution makes it challenging because that, and Dr. Richard Hipp even said on this podcast in the past that the test suite is proprietary and the fact that it's not in the open. You can't see it. So making these large scale changes. So to build on top of what is SQLite, if that's your desire, becomes just problematic. This was one of the big contributors for us to revisit that decision was exactly the test suite. And again, it's not that we didn't know about it. It's just that we thought things would go one way. But look, I always love to, if I may,

to use opportunities like this to clarify something. Because when you're telling a story, when you're saying something, it's easy for people to misunderstand you. So I always want to make this 100% clear. There's nothing wrong with SQLite and the way they manage their community. So sometimes people assume that because we went this direction, we believe that what they're doing is wrong. And I want to clarify that that's not the case. I think the beauty of having different people with different points of view coming from, you know, different backgrounds and doing things differently is exactly that you can experiment with a lot of models. and those models have advantages and disadvantages, and it's fine.

So that's not the way we believe. We truly believe. And the goal we have with Limbo now is really to replace SQLite. So we believe that we can build something much better if we're able to tap into the creativity and the dynamism of a modern open source community. We believe that, which does not mean that what they're doing is wrong. And it's just the choice that they made and we make a different choice. It's a, it's okay. Right. Well, I'm glad you make that explicit because as an observer,

I remember your initial announcement and maybe it's because of maybe the social baggage of what a fork implies, but exactly. My initial impression was, and I don't remember the words that you use anymore. It was two years ago, but I was like, they see you and your team seemed a little bit upset or, you know, you're kind of disappointed with this. And so we're going to fork and do it a different way. And it's hard to do that without ruffling feathers or without getting, even if you don't mean to people think that you're angry or mad or whatever, you know?

Exactly. And, and we spent a lot of, it was, we did spend a't mean to, people think that you're angry or mad or whatever, you know? Exactly. And we spent a lot, we did spend a lot of time, by the way, crafting that message. But regardless, like regardless of how much, there's always like some room for misunderstanding, which is all, which is why I always appreciate. Now, I also don't want to run from it. I want to make something clear. We disagree technically with that decision, right? It doesn't mean we think it's wrong.

You know, there's nothing like, we don't think badly of them. They clearly created something very successful. But the way Pekka and I always run open source communities and the way we always participated in open source communities, for us, this component of like being able to tap into the creativity of the community

was always something very important. And you have to put it in context as well that Pekka and I grew up in the Linux kernel community, right? And a lot of people say this about SQLite. And with that, I disagree. SQLite being what it is, has to be kept as this very small thing because that's the whole beauty of SQLite. And again, I disagree with that because if you look at Linux, Linux started as this project that would only run on x86 computers and et cetera. And today it is an operating system that runs everywhere. It runs very well on the server.

Pekka and I worked together in memory management for very big box machines, like how to make sure that when you have two terabytes of memory in 2010, which was a lot of memory back then, it's still a lot of memory today. But like those algorithms to manage memory don't take three minutes and hang up the system. It's a problem that doesn't happen in embedded devices. And Linux still runs on embedded devices. So through this big community, you actually can create something that runs well everywhere and don't necessarily have to make those compromises, right? So we don't agree that C. coli has to be protected and has to be maintained by just a single

individual to be the success it is. But look, you know, who knows? Maybe I'm wrong. Maybe I'm right. But, you know, we act based on what we believe, right? But there is nothing, we don't believe there is anything wrong with what they're doing. We just think that, you know, it could benefit from a different, with a different direction. But you do believe that you can replace, you said, we believe we can replace SQLite. 100% and we will. And I want to clarify that now, because with LeapSQL, it became very clear

to us in maybe a month that that was not going to happen. Right? So with LibSQL, I joked about it today. We had this goal of replacing SQLite for 10 minutes because it's a dream, et cetera. It's obviously a big prize. It's obviously this big prize and et cetera. As I wrote in my blog post, were we bummed about it?

No, because we built a pretty successful business on top of the code, on top of Leap SQL, which is today our company, Turso. So for us, it was this exercise of like, if you heard the expression, shoot for the stars, because even if you miss, you're going to hit the moon. For us, it was like, yeah, you know, it turns out I don't think it's going to be possible for us to replace SQLite with the fork. But that's us hitting for the stars. We didn't hit the stars. We hit the moon. The moon's great. Again, we built a super great project.

We're having fun. Leap SQL brought something to SQLite that wasn't there, which was like the serverless, running this on serverless environments on the cloud platform, syncing databases. One of the things that we do with Torso is that you can sync your databases between different devices and backups and all of that. And this is going great. I mean, this is going fantastically for us. And so we were never sad or disappointed that this thing that crossed our mind, imagine how amazing it will be if people just start using our fork instead of SQLite. We're never disappointed at that. But when we put the rewrite out, it became very clear. And I've been using this analogy from chemistry that the reaction was right.

Like LibSQL was something that the market was clamoring for. Like, I think what it became very clear, seeing the reaction of Limbo now, is just that the activation energy is not enough to make the reaction happen. And after talking to a lot of people, after talking to a lot of people, and I want to tell, you know, there's a whole story of what happened after we announced this. I talked to a lot of the people who came, started contributing to the project. And what it became clear is that they all wanted, like, they all agree with us that, like, we need a better version of SQLite. I mean, it will be fantastic if you have something like SQLite, but there's this, all our original vision, but the fork just wasn't differentiated enough.

It just wasn't ambitious enough. It just wasn't bold enough to get people to come and contribute. Furthermore, it is actually very hard to do because one of the things you did mention, like the SQLite's test suit is fully proprietary. So once you start making changes that are very deep into the core, you start hitting a bunch of issues. And some of them is just like yourself saying, I know that the best way to solve this problem is this, but I'm going to solve it in this other way, which is almost as good, but not great.

But it's less risky. So you start having this on your mind. So the fork never really unshackles you fully to go pursue this, which is why when we announced the rewrite, what we saw, like, again, was something I've never seen before. We got 8,000 GitHub stars in a week, essentially. We had for the first, what I consider to be for the first time in the history of computer science, a Hacker News comment section that was mostly positive with, you know, just a couple, I think maybe one or two comments only that were trying to denigrate us, but the rest very supportive. We had this fantastic, inspiring story of this individual who is in prison at the moment.

And he was one of the first people in the United States to be granted access to the internet in prison. He can access Discord, but not X, by the way. Maybe say something about it. But he is now the fourth top contributor to the Limbo project. Amazing. And many, many other things. I mean, the level of contributions that we started to get,

we started getting people running this on the browser. A week after we announced, it was running on the browser already, just like this, compiled to WebAssembly. All from contributions from third party people. Again, Leap SQL, we did get a lot of contributors, but they were all contributing to the drivers, to the server, you know, things at the margin, which they're important as well for an open source project. But with Limbo, we actually managed to see our dream, like the 10-minute dream come true. Like we're going to build a community of people coming here and writing this database with us, right?

So we revisit it. Now it's no longer a 10-minute dream that went away. Like we truly believe now that once we get the momentum going, we can replace SQLite. And that's the goal. Well, I think you had a great chord as you've given evidence to. I know my guttural response to Limbo was quite a bit more positive than mine was to LibSQL, just by reading the announcement post. I'm like, okay, this makes a lot of sense. And then I realized later, oh, it's the same people that tried LibSQL a couple of years

back. And it seems like with a rewrite, there's just so much more to do. It has its own identity. There's fresh and new ideas. And whereas a fork almost comes from a different place. And so I think you're absolutely describing it. On the testing front, though, I would imagine it's got to be just as hard. Or maybe I would expect it to be harder with a rewrite. What makes it easier with a rewrite than with a fork if you still don't have a test suite? Your intuition is correct, by the way, which is one of the things

that all things consider. We went with the fork because at least there is some level of guard rails that come with the fact that at least you know that this code that you're importing was tested by this proprietary test suite. It started off right. Right. So I don't think your intuition is incorrect, but something amazing happened. And by the way, the way I look into the situation, another thing that I want to make it clear, I don't actually think that we made a mistake with the fork because if we were rewriting back then, there were many decisions that we made today that we would not have made. But now we did because we had the experience. We've been running the Thurso platform and we learned a lot of things. So I almost see it as a prototype and it actually allows us to

make tremendously good decisions with the Limbo project. And one of them is exactly the testing. What happened is that Becca and I got hooked into something called deterministic simulation testing. And deterministic simulation testing is a very niche thing that most people have never heard about. I had heard about it a couple of times, but I didn't truly quite understand what it was until I met Yoran. So Yoran is the founder of, and I can say this, even though I am the founder of a database company, Yoran is the founder of, and I can say this, I mean, even though I am the founder of a database company, Yoran is the founder of the most amazing database company I've ever seen. Although now I think with Limbo, we have a chance to reclaim that title. Yoran and I are going to fight about it.

But, you know, ask me a month ago, I would say, man, I have to give it to him. This is the most impressive database company of all, Tiger Beetle. Tiger Beetle is a database, just to keep it very brief, that is designed for financial transactions. So it's completely written in Zig. And their goal is to replace entire systems, the bespoke systems that most financial institutions have to process transactions. So if you're selling to banks and financial institutions,

if your goal is to replace the backbone of world's commerce, it's pretty hard to do. And one of the challenges that you have is just this, how do we trust this thing? And you're unfound a solution for that. The solution that you're unfound was to write Tiger Beetle entirely with a technique called deterministic simulation testing. Deterministic simulation testing is essentially a fuzzer. So it will generate a bunch of inputs. It randomly generates as many inputs as it can on the space of possible inputs. And this is the disadvantage.

You kind of have to write software in a special way to lend itself to deterministic simulation testing. It's very hard to boat it to an existing code base, right? But you write it in a way that every single operation that you do on I.O., on thread scheduling, everything that happens goes through a special interface that abstracts all I.O. And then you plug a simulator. When you're testing this, you plug this into a simulator. And the simulator is included in the code base. So what the simulator does is that it's going to explore the space of possibilities, create the most arcane, impossible situations ever. And then when something breaks,

it gives you the exact steps deterministically that everything in the system had up until that point. So debugging those problems become very easy. So in record time, in record time, Tiger Beetle managed to create a system based on deterministic simulation testing, which is their database, right? And the stories that Yoran would tell is like, look, we found this bug that would only happen if you would call F-S on a disk and then Fsync would return an incorrect result. And at the same time, a packet will come from the network. I mean, he would describe like the most complicated scenarios. Oh, and the end result of that, the simulator gives you a seed and you type that seed into the simulator.

Now you have every single step that happened to make that happen, right? So this is one of the things that led us to believe, what if we try the rewrite? Because we knew that we could now try the rewrite using deterministic simulation testing. And then we also partnered with a company called Lentitis that offers almost like the integration test analogy for deterministic simulation testing, which is a full system version of that, that will simulate things between machines. It will simulate the network. It will simulate hardware failures and stuff like that. So whatever bugs our simulator does not catch, usually you give it to Antithesis the next day.

Antithesis catches the bug. So we knew that with that with that was the missing part of the puzzle and then with that uh we would be able to actually create something that probably even surpasses the level of testing the sqlite has but here's the catch it is easier to do this on the rewrite because you have to write the system with this in mind from the get-go it's not something that is easy to bolt upon is that popular enough that you can go out and there's, you know, rust crates that will give you this functionality? You have to write all this DST stuff yourself? All of it. Yeah. So for for people who are interested in DST, but don't want to go through the pains of just rewriting all sorts of things like that.

I truly recommend taking a look at antithesis because, I mean, antithesis is amazing. It's the second, you know, it's not just the second next best thing. We use it in conjunction. It's not an either or. The analogy that I have is that our own DST is like unit tests. Like we can run centuries of possibilities

in two days. And it's very fast, all things considered. And antithesis is like integration tests. So you want to have both. And it's very fast, all things considered. And Antithesis is like integration tests. So you want to have both, and we do have both. And Antithesis has been a great partner for us. But the problem with deterministic simulation testing is that once you start importing other crates in Rust, for example, you have no idea what those crates are doing. Those crates are calling IO. So you kind of have to write everything. So it's not even that you have a crate for deterministic simulation testing is that like you might not even want to import like something super simple, 100%. But you don't want to import anything that does IO that has a timer, you know, you want to write those things. So it's something very hard to do for a general purpose testing. For a database like Tiger Beedle, for a database like Limbo, it's worth it.

And the scope is quite limited, right? And you don't want to be importing crates all the time anyway. Tiger Beedle is way more insane than we are. I mean, they have a policy that they just don't have dependencies. That's it. They write every single piece of code. We try to be a little bit more flexible, but we will not import a crate that,

and again, it also depends because SQLite comes with a CLI. Right. If you want to import a crate that does whatever crazy stuff to implement callers in the CLI, you know, that's fine. But for the core of the database,

like we try not to import anything that could potentially do IO because we want to make sure that everything goes through the simulator. Well, friends, you can now build invincible application thanks to Temporal, today's's sponsor you can manage failures network outages flaky endpoints long-running processes and so much more ensuring your workflows and your applications never fail temporal allows you to build business logic not plumbing they deliver durable execution and abstracts away the complexity of building scalable distributed systems and lets you focus on what matters delivering reliable systems that are faster.

An example of this is Masari. They are the Bloomberg for crypto. They provide market intelligence products to help investors navigate digital assets, and they recently turned to Temporal to help them improve the reliability of their data ingestion pipeline. This pipeline collects massive amounts of data from various sources, and then they enrich it with AI. This process previously relied heavily on cron jobs and background jobs and queues, and the design worked well. However, these jobs were difficult to debug at scale because they needed more controls and more observability. And as they looked to rethink this ingestion flow, they wanted to avoid cron jobs,

background jobs, queues. They didn't want to create a custom orchestration system to oversee and to ensure these jobs and work was being done reliably. Here's a quote. Before Temporal, we had to code for dead letter queues, circuit breakers, etc. to ensure we were resilient to potential system failures. Now we eliminate these complexities. The headache of maintaining custom retry logic has vanished by using Temporal. End quote. So if you're ready to build invincible applications and you're ready to learn why companies like Netflix, DoorDash, and Stripe trust Temporal

as their secure and scalable way to build and innovate, go to Temporal.io. Once again, Tem to temporal.io. Once again, temporal.io. You can try their cloud for free or get started with open source. Once again, temporal.io. This DST sounds like magic. Like absolute magic.

It does. Yes, man. If it's like writing unit tests, what exactly, and you said that the rewrite is better because you have to write, assuming this DST is in place, what actually is the writing and the creating of this deterministic simulation testing? Like, what is that? How do you do it? Yeah.

So again, the simulator itself, like you just write like a couple of scenarios and again, it's not truly magic because you do have to write the simulator. So the simulator just writes, imagine, for example, a workload, and the workload is like generate a couple of queries and then write, et cetera. But the simulator will include a fuzzing element to that. So instead of generating this query that I wrote in the unit test, you give it almost like a query generator, and then it starts like generating random queries. And then you start like in the simulator itself, what happens, imagine this, like if you want to

write to a file in any software, like you would call a operating system API, like write, if you, you know, we're talking about Rust, it's like a FS write, and then you write to the operating system. When you're writing software for DST, you don't do this. Like you have your own IO interface abstraction, and then all of your IO goes through this. So when you're running this in production mode, your abstraction for write just called the operating system write. But when you're running deterministic simulation testing mode, your abstraction for write runs the simulator code that will start injecting failures into this. And again, injecting failures in a deterministic way, because then if the query fails, because you injected a IO failure at that moment, you will be able to replay that session piece by piece. As my friend that runs, well, he used to be on Screen Rant.

Wow, wow, wow. I'll just leave it there. I'm sure. Is that the guy that, is that the guy that. Barely inconvenienced. Very easy, barely inconvenienced. That's right. Super easy.

I love that guy, man. Wow, wow, wow. Super easy, barely inconvenienced. Wow, wow, wow. That's what I'll say right now. That's how he respond so how how do you rewrite sqlite with uh with the confidence that it will actually have the level of trust the sqlite acquired it's super easy barely an inconvenience right all you have to do is i love it just throw

a dst at it so when you talk about sqlite compatible that's limbo's goal there's a lot of different fronts that that has to be on. Are you talking file structure? Are you talking syntax language? Are there performance compatibility? There's all kinds of things that SQLite is. What's Limbo's goals with regard to these different areas of compatibility? First of all, compatibility in a project like this,

and this is the experience that we gained at Scylla when we were rewriting Apache Cassandra. Compatibility has to be like this, and this is the experience that we gained at Scylla when we were rewriting Apache Cassandra. Compatibility has to be like a one-way street. You don't want to shackle yourself and say, I will always... Because sometimes, for example, to implement a new feature, you have to do it in a different way. So it's usually something, hey, we're going to offer you the same feature set as SQLite. We're going to read your SQLite files. We're going to read your SQLite files. We're going to execute your SQLite code.

And if you're not using any of the specific features that we have, we can generate SQLite files as well. But the moment you start using new features that are only present in your implementation, it's impossible to be a competitor. It's just not possible. So that's Limbo so far, and this is something that we want to keep. The language is the same.

Again, we want to keep the language. We want to keep the ABI. We want to be able to load SQLite extensions. The file format, obviously, it's the thing that defines SQLite. So obviously, again, we might add to it in the future, but we'll be reading SQLite files normally. And we are bytecode compatible as well.

So one of the other ways in which we test Limbo is by now out of the simulator, just generating random SQL statements. And then seeing that the bytecode that is generated by Limbo is the same bytecode set of instructions that is generated by SQLite. So that doesn't catch bugs in the implementation of the bytecode, but at least you know that the query plan is the same and et cetera. So this is yet another way in which we've been testing to make sure that it's up to standards. So I mentioned at the top that it also has some ambitious goals. One of those, fully asynchronous IO, which is quite a bit different than SQLite, right?

So how do you accomplish that but maintain this compatibility? Yeah, so async is something that a lot of people misunderstand. Async doesn't mean, for the rust-minded people in the audience, to be clear, async does not mean that we're going to use an async runtime like Tokyo or like others. I actually personally wrote an async runtime when I was a data dog that's still around called Glomio.

We don't use any of that. And again, part of the reason we don't use any of that is that we want all of that to go through our simulator. So if you look at the limbo code, it's just really sync rust. It's not async rust, right? So all that async means is that when you call an operation, if that operation is not ready, it will return to you instead of blocking. And the main, now I'm getting a little bit too technical, but let me just give you the full context. The SQLite C API has a bunch of functions, but the most important of them is called SQLite Step. And SQLite Step is essentially like take another step, take another step in processing this query for me.

And this is a blocking function. So what that means is that if you call SQLite step, it will block until it resolves. Let's say in that step, you want to do like four, you want to execute four, five, ten, however many bytecode instructions. Until it does that, it will block. In limbo, if you detect that you're not ready to execute those bytecode instructions at that time, you just return something saying, no, call me back later. So that is essentially what async means. And then with that, it becomes very easy to plug something like Tokyo on top and rust or run it on the browser or whatever, because you can call those async functions, right? And if it's not ready, it will not block. That's all that means. But it doesn't mean that we have to use the async

runtime internally. In fact, quite the opposite way. So what does that unlock for you? Because SQLite historically is sync, but super fast because it's right there in process and stuff. Well, it isn't that fast. And I run a query yesterday, for example, that took 10 minutes to run. There was a query with five joints looking at all the user data about users who are signed up to the Turso platform. It takes a long time just

because the query is complicated. SQLite is very fast for CRUD style, right? Just like, hey, here's the key, give me the value. But it's not super fast for analytical stuff. So the first thing that it unlocks is just this. Queries that are much more complex that you can run in dashboards and things like that.

And also like for the serverless environments, Durso being one example, and for clarification, I'm going to say our product will be renamed to Durso Cloud. And we have all the intention in the world to rename Limbo to just Durso. Limbo is just not a great name, just a parenthesis here. And it just, you know, the story, it's all in the blog post,

but we never expected this level of support. So we just came up with a made-up name for it. That means nothing, right? But now we'll address that. But our product, the Durso Cloud, allows you to do like serverless SQLite on the cloud. You have a bunch of HTTP requests there in the middle. It allows you, for example, to host your data on S3 because if you have your data

hosted on S3, your query now is not necessarily super fast because you may be hitting a page that is not local. So it allows you, for example, to run SQLite with partial storage, like with most of your data on S3 and some of the data locally. It allows us to run on the browser because the browser, as you know, is a very sync unfriendly environment. If you block everything, the page just doesn't load. So in the browser, you have to be async. So there is a lot of things that it unlocks in terms. In fact, the one thing that Limbo doesn't even support transactions. It's very, very early, which for a lot of people who came to contribute,

they actually saw as an advantage, you know, just because you come with this energy and there's so much to do. But we're not even yet at the point that we support transaction. And the one thing that is already different and is resonating a lot is the fact that it is async. Well, you put a lot of thought behind this, not expecting it to be so well received. You put so much, it seems like just so much thought in the design of it from the DST to async to all the things.

But why were you so surprised it was so well received? Technically, we put a lot of thought on the product. And the full story there is that, first of all, we consider, just revisiting, especially if people are joining now, we consider rewriting SQLite from the get-go anyway. So this was always on our mind. This was always on our mind. And we added to LeapSQL. So one of the things, if you download LeapSQL today in the fork, LeapSQL comes with vector search out of the box. You don't have to install any extension.

You can do your RAG pipelines of SQLite out of the box with vector search out of the box. You don't have to install any extension. You can do your rag pipelines of SQLite out of the box with vector search. It was very, very hard to do. It was a ordeal to actually get vector search working. And there are lots of things in the syntax. Earlier when I was saying you might do it one way, but then you end up doing this other way, which is more conservative because vector search was the thing that I had in mind. Like many things in the syntax, they're okay, but they're not great because we had to be a little bit more conservative. And then Pekka started thinking, and this is all on Pekka. He started thinking, okay, how would that look like? How would that look like if we were to rewrite it. And our goal was something like, hey, look, if this project

keeps going, and it goes well, and it's an experimental thing, like maybe, you know, maybe in two years, in three years, we can make something out of it. So we were very thoughtful about the technical decisions that we were making. But everything around the presentation was just like, yeah, whatever, man, whatever. So again, this was not on our company's GitHub. This was on Pekka's personal GitHub. He spent 10 seconds thinking about the name and then just wrote on and said, it's going to be Limbo because it's a state of confusion. Like, we don't know what we're going to make of this.

The whole story of the name Limbo was essentially, Pekka, what are we going to be limbo because it's a state of confusion. Like we don't know what we're going to make of this. Like the whole, the whole story of the name limbo was essentially back. What, what are we going to make with this? I have no idea. Right. I just want to experiment with, with this concept, the logo.

He just asked chat TPT to generate. We took another five seconds, you know, just so, so there was not a lot of thought on the presentation and, and publishing, but that was a lot of thought about the technical side because we thought that maybe in two years,

maybe in three years, there is a play for us once we are a much more established company to tackle rewriting C. coli. What we do not expect is that as we were, what we decided to do is just make it a official torso experiment. But if you read the. But if you read the posts in which we were announcing this, we were very clear. We don't have a roadmap for this. Don't ask us what our intentions are. There is nothing that we want to do with this one on the short term. This was an

experiment on Packers GitHub that actually did pretty well. And it did pretty well based on two metrics. We got a thousand GitHub stars and we never talked about it. We never talked about it. And we got two incredibly good engineers that started, one from Red Hat, who is now with us. I mean, so we hired those two engineers. We got two incredibly good engineers that started contributing to the project. Again, it was just a project on Pekka's GitHub. So we knew there was something there, and we decided, let's just now publish it as an official torso experiment. We wrote in the blog post, maybe if that goes well, in six months we can start pouring some of our resources and interest,

and then we're going to see what happens. So we had some idea that this would be useful at some point. We just did not know it would be so well received to the point that it was, to the point that we changed our entire company strategy now to be able to pour our whole weight of our resources behind the project. And that's what we're going to do. So you're all in now. We're all in.

In fact, we wrote a blog post last week telling the story, a lot of what we're discussing here. Hey, I mean, this is, look, in my wildest dreams, in my wildest dreams, I would expect maybe this to gain like 2,000 more stars in a month or so than from 1,000 goes to 3,000. Maybe a couple of other engineers that would come and contribute as well and start slowly, but we would see some potential on it. That was my definition of success. And every single metric that we thought Limbo could be successful at, we saw three times more, four times more than what we anticipated.

So we decided to go all in. And there is a blog post that we wrote recently with all the changes that we're going to make to the platform to allow us to do this, with all the changes that we're going to make to the platform to allow us to do this. With all the changes that we're doing to the company, we had a lot of reorganizations internally. And this is really something that we decided in a couple of weeks in January. Because we just like, how can we ignore this? I mean, it seems very clear to us now that the world at large really wants a evolution of SQLite. Like the signals are very strong.

So I think we just need to get behind it, right? What do you think made those two contributors that were so pivotal contribute? If this was an experiment on Pekka's personal GitHub, it wasn't like from a technical level well thought out, but just an experiment. What was compelling to them? Yes. And again, those two individuals in particular, they are now working for us and we hired them already last year because they're great. And it's back and I was like, man, if Limbo has no other value, it's a great hiring tool for a company, right? Because

it's attracting this kind of people. But those are people, of course, that we have direct access to. So we talked to them extensively and all the others that came as well after. We had 32 contributors to Limbo the day we announced it as a torso experiment. Days later, we had already 60 and we're reaching 70 now. And again, a lot of that very core contributors doing a lot of great work. So Perry and Yusei, those two contributors, are the first ones that we talked to. And the story is always the same. The story is always the same. And it's exactly the thing I said.

They were very excited about the prospect of a better SQLite. They knew about LibSQL, but LibSQL never enticed them because it just wasn't in use his word. It just wasn't crazy enough. Right. Which I translate to bold. But it just wasn't like it just it kind of caps where you can go because of all you still shackle by the fork. So when they saw this thing that and I think you add this sprinkle to that as well, too. Man, this is a new project, so there's so many things to do, which engineers get attracted to, to some extent as well. But if you talk to them, again, it's always the same story. I love the vision, and I already loved the vision when I heard of Leap Seekle. But this thing here is just the right amount of ambitious that I want to start devoting my time to that and I want to be a part of that as well. So that's exactly, and we wanted to,

one of the things that we said a lot in the early LeapCircle days is that, we said that a lot because we heard from a couple of people, a couple of companies even, we love the idea of what you're doing because it gives us a seat at the table. And then my interpretation of that is that, it turns out it's actually pretty hard

to give people a seat at the table if you don't own the table. So Limbo gave us this, I mean, it's actually pretty hard to give people a seat at the table if you don't own the table. So Limbo gave us this. I mean, it's our table now. Now, it's a table that is modeled after another table, but we own the table. And now we can really, truly give those people a seat at the table. I mean, they're coming, they're writing code, they're contributing, they're reviewing code, they're helping with the direction, they come out with ideas. Things that we never consider, things that will not be a priority.

Like the thing, SQL already limbo runs on the browser. Somebody showed up today, today. Oh, I got libSQL to run the limbo CLI in WebAssembly and now I'm distributing the CLI. It's not even something we would have done, but the person took an interest because it doesn't have a ceiling. You essentially can take this anywhere. So does LibSQL just go away then or be replaced outright? LibSQL came to be a little bit, and a part of that because, again, as I said, after we had this dream of replacing sqlite for 10 minutes and then it became clear that that it wouldn't happen so we had this something that was very valuable

we know we knew it was valuable but we had to struggle a little bit more with what do we do with that so the leap sql project today is again it's two things it's a fork of sqlite with some of those changes like vector search but but it is also, and it's all in the same repository, it's all part of the same project. It is also a server implementation to do serverless SQLite over the wire. So that is what LibSQL is. It's an open source project, so we're still going to be maintaining that. But the client side part is going to be full limbo.

Like we're not going to, we don't intend, we intend to eventually get all of those things we've done, like vector search, all of that. Leap SQL is still maintained for the time being, because again, we have a business around it. We have features that we depend on, but our goal is to eventually port all of those features to limbo, which again, we plan to rename to Turso.

And then the client is that, and Leap SQL can become just the server implementation as an open source alternative to do that. What's up, friends? I'm going to give you a peek behind the scenes here. We love Notion here at ChangeLog. We use it so extensively. We do a lot of stuff externally from our internal core team,

and we have to organize a lot of stuff, a lot of workflows, a lot of statuses, a lot of writing, a lot of informing. And Notion is just so infinitely flexible for us. I'm creating workflows, standard operating procedures, basically. And it's just such a cool thing to build a workflow, a way of doing things inside of Notion. And now they have Notion AI, and it's saving us so much time. I'm writing with it. I'm finding things with it. I'm summarizing things with it. I don't have to kind of think, where is this in my massive Notion workspace or many team spaces that we have?

I just Notion AI it and it comes up. It's so cool. And if you're uninitiated, you may know Notion. I'm pretty sure you know Notion, but they combine docs, notes, projects, all into a single space that you can design yourself. And it's beautifully designed, mobile, desktop, the web, shareable on the web. It's just so powerful. It is your one place for your team to connect with your tools, your knowledge, and you're empowered to do your most meaningful work. And unlike other tools out there

that make you bounce from one thing to the next, to the next, Notion is seamlessly integrated, infinitely flexible, and it's beautiful and easy to use. So Notion AI helps us work faster. We're writing better, thinking bigger. We're doing tasks that normally take hours and we're doing those things in minutes, sometimes even seconds. And yes, we're not a Fortune 500 company, but Notion is used by over half of Fortune 500 companies and teams that use Notion, like us, send less emails, they cancel more meetings, they save time searching for their work, and they reduce their spending on tools, which helps everyone

stay on the same page. So try Notion for free today when you go to notion.com slash changelog, that's all lowercase letters, notion.com slash changelog, and try the powerful, easy to use Notion AI today. And when you use our link, of course, you are supporting this podcast, which you love. And we love that too. So notion.com slash changelog. Is there trailblazing left to do? Or have you done the trailblazing and now it's just a matter of work? There's there's so, there's so much, like there's so much because one, one of the things, one of the things that we heard as we launched Leap Sequel never for some

reason, I'll never forget that individual. So we, we create this discord community. We announced Leap Sequel. People came and one person in particular, but others said the same thing as well. Give me better schema changes and I'm switching to this tomorrow. So one of the areas, for example, the SQLite is really bad at is schema changes. You can make schema changes, but you cannot alter the type of a column. There's all sorts of limitations like that, which is something, by the way, that we made better in LibSQL. So LibSQL does better schema changes than SQLite, but it's not better

enough. Same story, because we were limited in what we can do. So we want to run replication, like native replication to the browser, which is something that people have been asking us for a long time. Imagine you have this SQLite database running on your browser that can then sync with an external server or S3 or whatever whatever and just get pages on demand. That's one of the things we want to do. We want to tackle the problem of schema changes. We want to tackle the problem of write throughput because SQLite is a very bad database for write operations.

We want to make SQLite much better for analytical workloads. So there's just so much that we believe we can do, right? But together with all of that, there is also the boring work of, you know, we don't even support transactions yet. And again, some of that you can do in parallel, like async, like browser, but some of them is just time in the saddle. How much time do you think? Are we talking months, years? Nine months to a year. Nine months to a year, okay.

For two reasons. First of all, because of the deterministic simulation testing. Because it allows you to move with a lot more confidence. Imagine trying to get into the thought process of a database writer. It's always like, I want to make this change, but I don't fully understand the impact that this change will have in all of those environments that I don't control, like running on an embedded device here, running this or so making changes to systems like that. Again, and those are the kind of systems that we dealt with at Linux. Sometimes Linux has a lot of weird stuff in the process of development around the idea of like, we know that this thing can break on a processor that only three people have in the world and it's not supported anymore. And we don't want to break those things. So we

always move very, very, very, very carefully. And the deterministic simulation testing just allows it to make a lot faster, like paired with antithesis, which is our integration testing in this analogy. It just allows you to move so much faster. The second reason for why we believe like a year is the reasonable timeframe here is a SQLite, as it turns out, and that's why one of the reasons we believe in forking and rewriting is not the biggest code base in the world. SQLite is not that complex. If we were rewriting Postgres, it's a completely different story. We're writing SQLite, it's actually doable in a year. And also, as I said, we're not going to do this in Q1 because we're treating our first quarter of the year as a transition quarter to allow us to finish other work so that we can be free to do this.

But we're going to have at least seven, eight engineers just working on it full time. So imagine that you have seven people working on a code base that is less than 200,000 lines big for nine months with a deterministic simulator that catches all possible bugs that you can muster. We believe it's a very reasonable timeline, like nine months to a year. So next January, we'll be talking about production grade production grade what 1.0 what does it look like next yeah we want to we want to release a 1.0 much earlier than that much earlier than that because we want to you know we'll see like we still be believing in in like release release often just just put it out there get it out there yeah a lot of people are going to be early adopters a lot of people i think like our thesis thesis is that it doesn't even support, even without transactions, there's a lot of people that with a little bit more support on the read side, they can already use it because a lot of

workloads for SQLite, you get the file. You don't write to the file. You get the SQLite file from somewhere and then you just run a bunch of stuff on it. So even without writes being fully supported, we believe there's a lot of use cases that this unlocks. So we want to be very aggressive with making releases. But the moment we're going to say, hey, this is stable. And look, we can actually even give us more time because it's a great commitment to say something is stable. I mean, people trust you that this is going to work. So we can take even more time than that to say,

hey, this now has our seal of approval. We're going to support all of that. But much earlier than that, it can already be production ready. Interesting. How does this all affect Terso, the business, and how does it fit in? I assume it's going to be an MIT licensed thing, open source. Yeah, so our business is going to change. We are announcing, we announced recently a lot of what we need to do is that we need to

simplify our product a lot. So we had very hard decisions to make. So again, it was a tough time for us to go through those decisions. But we kept the mission in front of us. We kept this idea like we need to make those changes because I think the community now trusts us to rewrite SQLite, which is like the biggest prize, we believe.

So we have to make those changes. A couple of features that we have, some of them that I love. A lot of users, unfortunately, got quite upset with that, obviously. I mean, the features that they use and came to trust, we will discontinue. So the way we're doing this is that if you're a paid user after a certain cutout date, you're going to be allowed to keep using those features. But new users, new signups, anybody else who is not a paid user at that point will no longer have access to those features. With that, we believe our platform will become a lot simpler. We're still going to maintain our platform.

But again, we think that having a single person just running the platform will be enough. And we're not going to be investing in having new features into the platform. So the platform will essentially go, which is the Turso Cloud, will essentially be a place where you can still run. Like if what we do today is good for you, great. And what we do today is two things very well, especially after those features will be discontinued. You can access SQLite over the wire

from serverless environments. So you have a serverless managed SQLite database. And we have our features, point-in-time restore for backups, branching. We have all of that that a serverless database needs. And you have syncing of databases between devices, servers, et cetera. So you can start with your SQLite file

and you can upload that file to Torso and then replicate that to other SQLite files that you own. That's the platform. We're not going to be investing too much in new features, in front-end features, in quality of life features. The platform will essentially go into a freeze for a year. And the platform is pretty good. It's at a position that we can afford to do this.

And then for one year, we're going to go all in in getting Limbo to replace SQLite. And that's it. And then at that point, Limbo then becomes the thing that we run on the platform. And we have the money. We have the running to do this. It's all accounted for. So if we manage to, which I believe it's very doable, to get Limbo in a production-ready state in 15 months, our plan still works. But 9 to 12 is what we're thinking here.

When you get to that place, whenever Limbo becomes Terso and Terso Cloud cloud goes away how will you differentiate this new launch like how will you so cloud doesn't go away what is torso today becomes it's called torso cloud uh and then torso the embedded database just becomes torso and and again this is a lesson that we learn uh not that we haven't heard this before, but I think we were just stubborn. People kept telling us, it's very hard to create two brands. It's very hard to create one brand. Two brands is even harder. But the reason we kept those things separate and the reason Leapsicle wasn't called Durso

was exactly because we wanted to give people the sense of, this is a welcoming community. We have our business, but your interests will be heard, right? Like Linux. We model a lot of that on the experiences we had at Linux. Very few people care about this. And that's the lesson that we learned, right? Just almost nobody, of all the reasons that we heard for people not contributing to Leap Seek, this was never something that showed up. Never, ever, ever, ever. And then when we announced our changes to the Thurso platform, we had many questions from many people about, hey, this feature, they're going to discontinue this other thing. They're not going to support. And what happens is nobody asked about the name.

Nobody said, oh, if the name Tursow, you're going to, nobody cares, right? So this idea that we had that we have to keep things very separate to create the welcoming community, we learned that nobody cares. So we're going to take the opportunity here to just fix it. Because again, it is true what we heard from many of our advisors, creating a brand is already incredibly hard. Creating two brands is very hard. And the people in the know, they know, but people who are just hearing about it,

like now you have to explain that, you know, this is this and this is that. So we're going to just consolidate the names. And Turso today, again, is the cloud offering that is going to be renamed to Turso Cloud. And then what is Limbo, which is the client offering, will just be renamed to torso and that's it and we're still welcoming we still want people to to come and and build this with us we just learned that the name doesn't matter right how do you manage that uh relationship between the open source torso the the entrance of the

interests of torso cloud you know third-party contributors who may want terso to go a different direction that maybe you don't want it to um you know success brings all kinds of challenges it does and that's why what we decided to do is never port the the server code to limbo right because then the server can be you know the server can be kept completely separate and i think again i think the reason we had the server and the client together was exactly because it was clear to us after a month or so that we would not, with LibSQL, with the fork, achieve our goal of really just replacing SQLite, this goal that we had briefly. So the best strategy then became have the server code here as well, because now there are other things you can do with this open source project.

But with the success of Limbo, again, it's back on the table and it's a very realistic goal that this will replace SQLite. So we just revisited the strategy and said, this has to be just the client-side library exactly because of this, because we don't want to be in a position.

And the name was a part of that. We just learned that it doesn't matter, right? But we don't want to ever be in a position. We want to design things in a way that we are never, ever, ever in a position to even think about. We would like to, you know, there's a contributor coming with this code and maybe we don't want to merge it because, you know, this might affect our business. You never want to be in this position. In fact, we want to make people in the community maintainers as well. We want to have people, hopefully like Preston, the person that I mentioned that is in prison, and others that are doing fantastic work. I mean, if they keep working for another six months or a year and you see that they're

committed to the project, they should be maintainers as well. And they should have the ability to just merge code without talking to us. That's what we want to see. So the way we're going to structure things to make that happen is that our business now has to be just the cloud. And then all the code for the cloud, that is a separate project, right? That's going to be its own thing. And then the client, SQLite, for example, they don't have encryption at rest.

They don't have a bunch of things because they do try to build a lifestyle business around it, as far as I understand, by selling those things. They're very specific. We want all of this in the open source for us. We want all of this. We want encryption at rest. We want all sorts of extensions. We want everything that runs on the client to be 100% open source. Very cool.

So how will you know when Limbo slash Terzo has made it, has arrived, has replaced SQLite? Will it be on Mars? Will it be on trillions of devices? Like when will you think it's here? I think, yeah, I think if this was a consumer business is when your mom calls you to say that she's using it without knowing that this is the software they work with. I don't think my mom's going to use Limbo or TurSource or SQLite or whatever. So I can't use that.

So the criteria for us is really when we can see somehow through some fuzzy metric that we've got. Like we have a billion databases out there. So SQLite has a trillion databases. And I think that we don't think we're going to replace SQLite in a year. That's not the goal, right? But we think that in a year, we can get to this point where, hey, we got our first billion. Like, this is clearly working. Just let you do this for another two years.

You do this for another three years, you get there. So the first milestone that we have in mind is that when we can, you know, through some proxy, because a lot of that you cannot measure. But we have a good level of confidence that we have a billion databases in the open. Then I think, okay, that's success. If people wanted to play with it today, how much is there? What could you play with, if anything? A lot of the read stuff works. A lot of the read stuff works. And one of the things that Pekka, this was entirely Pekka's idea, that he did very well. And he was very praised by a lot of the read stuff works. And one of the things that Pekka, you know, and this was entirely Pekka's idea, that he did very well. And he was very praised by a lot of people, including those contributors.

Some of them said, this is one of the reasons I contributed. Is that he wrote on day one, because technically this was very well thought. We thought about everything very well on the technical level, just on the presentation that we didn't have a lot. But there is a compatibility matrix. So if you go to the repository, there is a file there, compat.md, that is linked in the README, and there is a full compatibility matrix with everything. So what you're going to see there is like the read stuff from SQLite already works pretty well.

So you can, in a lot of ways, if your queries are not the one I run today with 10 joins and very complicated use cases, the basics of like reading from a SQLite file, they work already. Adam, any other questions for Globber before we let him go? I'm just trying to understand this future, I suppose. And I'm trying to piece it together

and I don't know how to ask this question necessarily, but I'm reading your most recent roadmap where you mentioned changes to our server implementation. And sorry for my stuttering because I'm still drastically behind on my breaths because of getting over the flu. But client-side, open source. Server-side, closed source. And so LibSQL is Terso Cloud. And if you want to self-host... More or less, because, yeah, just to add to that, it wasn't something very relevant, so I didn't bring it up. But we already had, for other reasons, we already had a proof of concept

of a new server implementation that is not based on LibSQL. And the reason we did this is that we also want our server to have deterministic simulation testing. So that new server will be closed source. LibSQL, so that's one of the changes in strategy that we're making. And again, we understand that in a perfect world, everything will be open source. I would love that. But the reason we're doing this is that we want to have this very clear separation without concerns of what goes where. And we think the best way to do this is if the server is fully proprietary and the client is fully open source.

So Leap SQL is open source. The protocols are all the same. So you would be able to run your Thurso Cloud databases on Leap SQL. That's the goal. But the new server that runs deterministic simulation testing, that has a lot of additional features, that is designed to be multi-tenant, the design goal that we had is that we will be able to run queries to a billion SQLite databases in a single box. So all of that, like that level of scalability, we're going to keep it closed source. So that's going to be the dividing line. And then LibSQL still exists as a reference implementation. If you truly want to run an open source version,

it wouldn't even be, I think it's more accurate to say, if you want to run an open source implementation of our cloud platform, LibSQL will do this for you with limitations. But our new server, we decided not to, you know, seeing the success of Limbo, we decided not to release that as open source

to keep things clear. And then Turso, the embedded database is 100%, 200% if we can, open source. 200%, gotcha. So in the future, when somebody runs Limbo,

which will be renamed Turso, they can run that on their own but if they want this massive scale multi-tenant world they've got to host with you yes or or or write their own implementation right or use lib sql again which is still going to be there but we believe our implementation is going to be better that's why we didn't so you're long you're long betting on hosting a lot of databases in the future. Yes. Yes. Okay. Yes. You said you don't need money, right?

So you have the runway for the next 15 months. You're getting dangerous. No, we have runway for more than that. Like everybody needs money. No need to raise more now though, to get to this goal. We don't need to raise more money now. Yeah, that's right. For another more than two years. I mean, I've been talking about 15 months, not as a cutoff point for that. It was more about like, when do we believe that this can become, but we have capital for a lot longer than that.

Okay, good. Let's talk in a year, I guess. I mean, that's all the questions I have for now, for the most part. Everything else is speculation, but there you go. Send me an invitation today for a year in the future january 22nd 2026 same time same time same date how about that yeah exactly let's do it thanks laber hey we're rooting for you this is really exciting stuff thank you yeah well the future of sqlite or SQLite is not necessarily in jeopardy, but it is being primed for disruption. If Globber and his co-founder has it their way, they will unseat and they will replace SQLite. And Limbo is full steam ahead with lots of inertia, lots of momentum, lots of contributions. And there's lots to do for you, for me, for others. So you can dig

in. It is open source and it's also open to contributions and it's being rewritten, which means there's new things to do, new innovation to be had. And that's exciting. Make sure you go to turso.tech, T-U-R-S-O.tech to learn more about what they're doing and to learn more about Limbo and the future of this database and this platform. Okay, big thank you to our friends and our partners over at Fly. We love them. Fly, you're awesome. Fly dot I-O. Launch your app in five minutes like we do.

It is the cloud for developers who ship. That's us. That's you. Fly dot I-O. That's you fly.io and to our friends over at retool retool.com and our friends over at temporal temporal.io and our friends over at timescale timescale.com and to the beat freak in residence break master cylinder. Those beats are banging banging. Okay friends is on Friday. Stay tuned. It's awesome.

The show's done. We'll see you on Friday. Thank you. Game on. can you tell us more about this uh press is it preston thorpe do you have more information on this fella contributing from prison that you can tell a little bit more of the story yeah he he wrote a blog about his situation i actually mentioned that on x the primogen which is this big streamer that I'm sure a lot of your audience knows, read his article on stream based on my tweet. So there's a lot. If you want to see a long account and hear from him, I do recommend you look into his blog. I'm happy to give you the link here. But long story short, as far as I understand, I mean, it's this guy that was imprisoned for nonviolent drug offenses. So he's in prison somewhere in Maine as part of a pilot program. He was allowed to have a

remote job. And for his remote job, he has access to the internet monitor and with restrictions, of course. But when Limbo was announced, he took a tremendous interest. And I actually spoke to him. I called him the other day. And the story that he told me is that it just so happened. We announced Limbo in December, right? December 2025. So he was on a break. So he was on vacation from his work.

And when you and I go on vacation, you know, maybe you go travel somewhere or I go play with my kids, et cetera. Preston's vacation is just like I sit here in prison for 12 hours. Change love plus plus.