Turso is rewriting SQLite in Rust (Interview)

26:07Deterministic 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 bolt 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.

26:48And 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. And the stories that Yaron would tell is like, look, we found this bug that would only happen if you would call F-Sync on a disk.

27:26And then F-Sync would return an incorrect result. And at the same time, a packet would come from the network. I mean, he would describe the most complicated scenarios. It was, 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 tried the rewrite because we knew that we could now try the rewrite using deterministic simulation testing. And then we also partner with a company called Antithesis 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.

28:13So 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, that was the missing part of the puzzle. And then with that, we would be able to actually create something that probably even surpasses the level of testing that 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 rust crates that will give you this functionality?

28:48You have to write all this DST stuff yourself? All of the, yeah. So 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, it's not 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.

29:28And 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 we even like, 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 Beato for a database like Limbo, it's worth it.

30:09And the scope is quite limited, right? And you don't want to be importing crates all the time anyway. You know, Tiger Beato 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. 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 but for 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 the simulator well friends you can now build invincible application thanks to temporal today's sponsor.

31:04You 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. So 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.

31:41And 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.

32:20to 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. 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 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 that like magic it does yes man if it's like writing unit tests what exactly and you said that the rewrite is better because you write, assuming this DST is in place, what actually is the writing and the creating of this deterministic simulation testing?

33:17Like, 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, right? So the simulator just writes the, 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 we will, instead of like generate 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.

34:00If 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. 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.

34:44as my friend uh that runs well he used to be on screen rent uh wow wow wow i'll just leave it there i'm sure is that the guy that uh is that the guy that's barely inconvenient very easy barely inconvenience that's right super easy i love that guy man yeah wow wow wow wow wow that's what i'll say right now that's how he respond so how how do you rewrite sequel light with uh with the confidence that it will actually have the level of trust that SQLite acquire. It's super easy, barely an inconvenience, right? All you have to do is to determine this. I love it. Just throw a DST at it. So when you talk about SQLite compatible, that's Limbo's goal.

35:23There'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 like rewriting Apache Cassandra. Compatibility has to be like a one way street, right? 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.

35:57So 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 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.

36:36The 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.

37:22So I mentioned at the top that it also has some ambitious goals. One of those, fully asynchronous I.O., 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.

38:03So if you look at the Limbo code, it's just really sync Rust. It's not async Rust. So all the 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.

38:45Let'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 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 but uh well it isn't well it isn't that fast.

39:36And I run a query yesterday, for example, that took 10 minutes to run. There is a query with five joints looking at all the user data about users who are signed up to the Teresau 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, like queries that are much more complex that you can run in dashboards and things like that. And also like for the serverless environments, Thurso being one example, and for clarification, I'm going to start with, our product will be renamed to Thurso Cloud.

40:19And we have all the intention in the world to rename Limbo to just Thurso. Limbo is just not a great name, just a parenthesis here. And it just, 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 Thurso Cloud, allows you to do 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, right?

40:56So 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. Like 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. uh there is you know 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 there is 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 be you know 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, you know, to async, to all the things, but why were you so surprised it was so well received?

41:57Technically, technically we put a lot of thought on the product and the full story there is that first of all, like we, we consider as 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 LibSQL. So one of the things, if you download LibSQL today in the fork, LibSQL 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. It was very, very hard to do. It was a ordeal to actually get vector search working.

42:34And 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 you don't. 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.

43:20So 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 Packus personal GitHub. He spent 10 seconds thinking about the name and then just wrote on, I 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. Like the whole, the whole story of the name Limbo was essentially, what, what are we going to make with this? I have no idea, right? I just want to experiment with, with this concept.

43:53The 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 there was a lot of thought about the technical side because we thought that maybe in two years, maybe in three years, you know, there was a play for us once we are a much more established company to tackle rewriting C-collide. What we did not expect is that as we were, what we decided to do is just make it a official TURSO experiment. But if you read the posts in which we were announcing this, we were very clear. We don't have a roadmap for this.

44:33We don't have any, 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. And 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 Packers GitHub. So we knew there was something there and we decided let's just now publish it as a official torso experiment.

45:12We wrote in the blog post, maybe if that goes well, in six months, we can start pouring some of our resources and then we're going to see what happens. So we had some idea that this will 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.

45:58Then 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. You know, 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 doing to the company, we had a lot of reorganizations internally.

46:31And this is really something that we decided in a couple of weeks in January. Because we're just like, how can we ignore this? I mean, it seems very clear to us now that the world at large really wants an evolution of SQLite. The signals are very strong. So I think we just need to get behind it. What do you think made those two contributors that were so pivotal contribute? If this was an experiment on PECA's personal GitHub, it wasn't 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, you know, they're great.

47:12And 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 Pere and Yusei, those two contributors are obviously the first ones that we talked to. And the story is always the same.

47:52The story is always the same. And it's exactly the thing I said. They were very excited about the prospect of like a better SQLite. They knew about LeapSQL, but LeapSQL never enticed them because it just wasn't, in Yusuf's 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 know, you still shackle by the fork. So when they saw this thing that, and I think you add a 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.

48:31But 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 Sequel. But this thing here is just the right amount of ambitious that I want to start devoting my time to that. 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 LeapSycle 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.

49:05So 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 considered, things that would 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 in distributing the CLI. show.

49:42It'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 it It wouldn't happen. So we had something that was very valuable. We knew it was valuable, but we had to struggle a little bit more with what do we do with that. So the LeapSQL project today is, again, it's two things. It's a fork of SQLite with some of those changes like vector search.

50:23But 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 LeapSQL is. Okay. 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. We intend to eventually get all of those things we've done, like vector search, all of that. LipSQL 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 TourSoft.

51:04And then the client is that and LeapSquels can become just the server implementation as an open source alternative to do that.

51:20What's up, friends? I'm going to give you a peep behind the scenes here. We love Notion here at ChangeLaw. 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.

51:56I'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.

52:34And 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.

53:11So 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.

53:37Is there trailblazing left to do or have you done the trailblazing and now it's just a matter of work? There's so much. Like there's so much because one of the things that we heard as we launched lib sql never for some reason i'll never forget that individual so we create this discord community we announced lib sql 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 uh the type of a column there's there you know there's all sorts of limitations like that Which is something, by the way, that we made better in LibSQL.

54:21So 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 like 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 SG or 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.

54:54We want to make SQLite much better for analytical workloads. So there's just so much that we believe we can do. But together with all of that, there is also the boring work. We don't even support transactions yet. 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. 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.

55:36It'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. 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.

56:11and 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 time frame here is a SQLite, as it turns out, 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 going to put the whole, 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.

57:00But we're going to have like 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, is it production grade? 1.0? What does it look like? Yeah. 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 believe in like release often, just put it out there.

57:39Get it out there, yeah. A lot of people are going to be early adopters. A lot of people, I think, like our thesis that, you know, 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, like you get the file. Like 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.

58:09But 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. How does this all affect Terso, the business, and how does it fit in? This is going to, 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.

58:51So we had very hard decisions to make. So, again, it was a tough time for us to go through those decisions. But we knew 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, a couple of features that we have, some of them, you know, 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.

59:37But new users, new signups, anybody else who is not a paid user at that point, we 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 Thursault 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.

1:00:13You 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.

1:00:49And 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, right? 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 Limba becomes Terso and Terso Cloud goes away, how will you differentiate this new launch?

1:01:28Like how will you? Terso Cloud doesn't go away. What is Terso today becomes, it's called Terso Cloud. And then Terso, the embedded database just becomes Terso. And again, this is a lesson that we learn. Not that we haven't heard this before, but I think we're 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 LeapSQL wasn't called Durso was exactly because we wanted to give people the sense of, you know, this is a welcoming community. We have our business, but your interests will be heard, right?

1:02:08Like Linux. We model a lot of that on the experiences we had at Linux. very few people care about this and that and that's the lesson that that we learned right just almost nobody of all the reasons that we heard for people not contributing to leap sequel this was never something that that showed up never ever ever ever uh and then when we announced uh our changes to the thursault platform we had many questions from many people about hey this feature they're going to discontinue this other thing that you're not going to support and what happens is nobody asked about the name nobody said well if the name through so you're gonna nobody cares right so 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 so we're gonna we're gonna take the opportunity here to just to fix it uh because again it is true what what we heard from many of our advisors creating a brand is already incredibly hard creating two brands is very hard and 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.

1:03:15So we're going to just consolidate the names. And Torso today, again, is the cloud offering that is going to be renamed to Torso 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 come and build this with us. We just learned that the name doesn't matter, right? How do you manage that relationship between the open source Terso, the interests of Terso Cloud, third-party contributors who may want Terso to go a different direction that maybe you don't want it to? Success brings all kinds of challenges.

1:03:52It does. And that's why what we decided to do is never port the server code to Limbo. Because then 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, have achieved our goal of really just replacing SQLite, which, you know, this goal that we had briefly. So the best strategy then became, like, 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.

1:04:36So 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.

1:05:09We want to, 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 become, that is a separate project, right? That's going to be its own thing.

1:05:41And 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 should be 100 % open source. Very cool. So how will you know when Limbo slash Terso has made it, has arrived, has replaced SQLite? Will it be on Mars? Will it be on trillions of devices?

1:06:16Like when will you think it's here to arrive? 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. I don't think my mom's going to use Limbo or Teresor 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, you know, 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.

1:06:53Like this is clearly working. Just let you do this for another two years. It's 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, OK, 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, you know, this was entirely Pekka's idea, that he did very well.

1:07:26And 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. I mean, 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 into ReadMe, and there is a full compatibility matrix with everything. So what you're going to see there is the read stuff from SQLite already works pretty well.

1:08:01So 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 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.

1:08:39Server-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 like 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 is the changing 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.

1:09:18I 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 LeapSQL is open source. The protocols are all the same. So you would be able to run your Thursault Cloud databases on LeapSQL. 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.

1:09:56So 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 seeing the success of Limbo we decided not to release that as open source to keep things clear and then the embedded database is 100 % 200 % if we can open source.

1:10:38200%, gotcha. So in the future, when somebody runs Limbo, which will be renamed Terso, 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 write their own implementation. Or use LibSQL 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 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 get in danger zone. No, we have runway for more than that.

1:11:13Like 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 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 now. Okay, good. So 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.

1:11:51How about that? Yeah, exactly. Let's do it. Thanks, Clover. Hey, we're rooting for you. This is really exciting stuff. Thank you. Yeah.

1:12:00well the future of sqlite or sqlite is not necessarily in jeopardy but it is being primed for disruption if glober 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 terso.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.

1:12:47Okay, big thank you to our friends and our partners over at Fly. We love them. Fly, you're awesome. Fly.io. Launch your app in five minutes like we do. It is the cloud for developers who ship. That's us. 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, brake master cylinder. Those beats are banging, banging. Okay friends, it's on Friday Stay tuned, it's awesome This show's done, we'll see you on Friday

1:13:59Thank you.

1:14:29Can you tell us more about this? Is it Preston Thorpe? Do you have more information on this fellow contributing from prison that you can tell a little bit more of the story? Yeah, 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 in prison for nonviolent drug offenses.

1:15:08So 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 etc Preston's vacation is just like I sit here in prison for 12 hours