Ep. #123, SQLite on the Edge with Glauber Costa of ChiselStrike

Brian Douglas: Welcome to another installment of Jamstack Radio. On the line we've got Glauber Costa. Glauber, how are you doing?

Glauber Costa: I'm doing great, Brian. Thank you so much for having me.

Brian: Yeah, pleasure to finally connect on the podcast. We had met at Jamstack Conf last year, and yeah, congratulations on all the progress on ChiselStrike, which we'll talk about in a moment. But I wanted to touch base on your background and how you got here.

Glauber: Absolutely. I've been doing open source for essentially my whole life, which is a lot of years. I started with the Linux kernel, so this was in the late 90s, early 2000s. Linux was this thing that was becoming huge, nobody really believed in open source. It was a very different world back then, we had to prove that this was a model that could work. I was just in college and I took an interest, I always liked performance and low level systems, I was never much of a web person. I tried a bit, but it was never my thing.

I loved the fact that Linux was open source, the whole operating system, I can just go and change it. Then I started contributing to it and spent a decade doing it. I eventually started working for RedHat, and then I worked in virtualization and the Zen Hypervisor and the Cave Hypervisor for folks who are familiar with it. Made obviously most of my, if not most, a very large part of my connections today, including my co-founder, Becker.

Becker, at the time, he was the maintainer of the memory management subsystem for Linux. I was trying to get some of my work through him. Then we developed this love-hate relationship. But Becker, he was a tough guy, tough on accepting my contributions. Of course for a reason, Linux is a very high standard project. So I've done this for, as I've said, around a decade. In that timeframe I wasn't very interested in startups. My thing was really just like, "Hey, open source and hacking Linux. That's it, that's the life."

When I was becoming a bit interested in startups, when I was growing up and figure it's good to be innovating and doing new stuff. One great friend that I had in the community, the Linux community, was starting a startup and that was the creator of the Cave Hypervisor, with whom I worked for a long time. I joined his startup in and around 2013, if I'm not mistaken. '12 or '13, something like that.

The startup was doing something called a UNI kernel, which is essentially a specialist kernel. So we wrote our own kernel in C++ at the time, that can only run a single application. With that, hopefully you get better performance, you don't have transitions between user space and kernel space. The product didn't work very well. Technically it did, but we found no market for it. I think it was just the wrong time.

Things like FireCracker, for example, didn't exist. Everything was a lot heavier, so you would put this thing on EC2 , EC2 would take like five minutes to boot a machine and then your kernel takes 300 milliseconds to boot. It was incredible compared to Linux, but it just reduced your boot time from six minutes to five minutes, and 300 milliseconds. Not that impressive, so it didn't work for a variety of reasons, and we pivoted.

The company pivoted into a database company, and it's funny because people who've met me in the past 10 years know me as a database person. But back then, had you invited me to join a database company, my reaction would've been, "No. Please, no. That's the last thing I want to do."

Brian: Why is that?

Glauber: It just didn't feel to me like-- Databases were so well established, my thinking was, and it felt so arcane to me. Everybody has this idea of like, "Oh, what a stupid idea," and it's a stupid idea that everybody has, writing a database. Now I'm writing my third database, so I guess I grew stupider. But yeah, I'd landed in that so it wasn't my intention. I was really interested in operating systems, but also part of that is I started realizing that it was becoming harder and harder to build the business with operating systems because talk about databases being this platform, very ossified thing.

Operating systems were becoming even more. I had a job at Linux, but if you think about business, it was becoming a harder and harder thing to do. RedHat was very dominant, et cetera. So I said, "You know what? I'm here, why not? Might as well try." And the database was Zilla for those in the audience that might have heard of it. It was a reimplementation of Apache Cassandra in C++, focused on very high performance and delivering 10 times the throughput with low latency.

The database is still there, still rocking, doing tremendously well, last I heard. But he kept this ethos that I always liked about performance, speed, latency, high throughput, and I ended up staying at the company for eight years and it was a great opportunity. We wrote the whole thing from scratch. I got involved in the business side of things. I left around the time COVID started, then I spent a year at DataDog.

At the time, I mean, it's something that affected all of us so for a variety of reasons I think it was better. My intention was to spend at least four years at DataDog. I said, "Hey, let me take a break from startups and et cetera, and see how the world is in the other side of the fence." I want to say that DataDog is a fantastic company. Every time I have a friend who comes to ask me, "Hey, I'm getting an offer from DataDog. What do you think?"

I say just go for it, it's a fantastic company. But I also realized that I'm a builder, I like to be building stuff and working for a large company is very, very challenging in many aspects. At the time we had the opportunity to start ChiselStrike and then we did. So I ended up spending just a year at DataDog and now we're here with ChiselStrike.

Brian: Yeah, fascinating. I didn't realize all your background until you dropped your bio in our shownotes, but I feel like I just took a tour through your historical record. But I'm curious what got you to leave DataDog and start ChiselStrike?

Glauber: Yeah. It was a variety of things. First of all, as I just mentioned, as far as big companies go, DataDog was an incredibly pleasant place. But my idea was after some four years at DataDog, maybe it would be the time for me to start my own company. I always wanted to be a founder, I mean, not always. As I mentioned in the beginning, in the very beginning of my career I was just, "open source, open source, open source."

But since I got interested, I like to do all sorts of things. At Zilla I was doing engineering, I was doing marketing, I was doing sales. Not as a salesperson, but helping those folks. So I like those environments in which you're doing everything. Founder is pretty much the definition of that. Then we had the opportunity.

We had a VC firm with whom we were talking to, just out of friendly relationships. As you well know, VCs love to get in touch and get to know you, et cetera, every time you do something interesting, just to expand your network.

We clicked with one VC in particular and we've been chatting with him for months, and then one day Beck and I had this idea, "Well, why don't we try this?" We talked to him, essentially out of curiosity, "Lets see what comes out of it." And he was very excited, ready to write the check. So essentially we had a check and, as I said, DataDog was great but I love being a builder. It was tough, it was really tough because for people who have done both startups and big companies, you know the big advantage of big companies. Just liquid.

Brian: Yeah. I just left a big company and was very comfortable for the four years and eight months I was there.

Glauber: Yeah. That's what I was shooting for. Hey, four or five years. I'll use this liquidity to build my future. Maybe I'm just crazy, that's the story. But we had the opportunity, we had an idea that we believed in, we felt that the time was right and then we just jumped ship.

Brian: Cool. Then we can go right into what is ChiselStrike. What are you solving?

Glauber: So I'm going to talk about, just for the benefit of your audience, I guess, of what we were solving and what we're solving now, because we also had a little bit of a detour in the way. We don't call it necessarily a pivot, especially in comparison with what I had before. I started with an operating system and land with a SQL petabyte scale database. But idea initially with ChiselStrike was that the main thesis that we had is that you have people, like yourself, they're frontend developers that are more and more in charge of the database decisions for your companies and for your projects, et cetera.

Versus in the old world, where databases are domain auth anointed, right? So we started trying to understand it, and we did not know that fully at the time what we learned as we started in our research. But many other companies were picking up on that, which in the beginning was a bit scary because it's competition, but you also feel validated that I'm hitting on an idea that's true. So things that we started as we've done our research, the research noticed that it would be important for databases to do in this new era, it was play very well with the edge and serve frontend developers very well.

So what we've done with ChiselStrike is that we've got SQLite, and why SQLite? Because SQLite is a database that, to us, felt perfect for the edge, and it provides you with unmatched developer experience because you can just do everything locally on your laptop, et cetera. Then we decided to add a Dino runtime to that and allow to execute TypeScript functions in the database itself. So the idea was pretty simple, and at some point we said, "We're going to figure out a way to put SQLite at the edge." What do you need to put SQLite at the edge?

You need to essentially make sure that the data comes from somewhere to that instance, but once it does then you're behaving like you would do it locally. So now you have a super fast database that doesn't feel like you, as a frontend developer, is writing code to a database. You can just write TypeScript code and then we have a compiler that compiles to queries and so on, and so forth.

The idea there was reduce friction and if you're a frontend developer, you don't have to learn SQL and things like that. But then the mantra of startups is, "Talk to your audience." And we've done a bunch of things around SQLite at the time but it wasn't our main focus. Our main focus was, "Let's figure out the APIs first, let's figure out this part about the data and code merging," however you want to call it. We had prototypes, but then later with prototypes, the thing that makes SQLite able to operate in a distributed environment.

So talking a lot to our users we realized a bunch of things. The first of them is that as it turns out, and again you tell me, you're a frontend developer--

Frontend developers are not as scared of SQL as we thought. They may be scared of databases, and we have this tendency of thinking of databases in SQL are interchangeable. But they're not, and so what we realized is that people were not only okay with SQL, they kept asking us, "Great abstraction, but can I do SQL? Can I go one layer below and do SQL?"

Also, the thing about code, complicated in a lot of people's mind because it felt like code. So the question we got asked all the time, "How do we deploy this on Netlify?" I said, "Well, you don't because this is database code, so you deploy this on us and then your code is on a Rest API." But it's code, right? The boundaries were not that clear, and every time that we talked to anybody, people would ask us a lot more questions, it would fuel a lot more interest in the SQLite form. Then we figured, hey, then maybe that's where the things are and then we reoriented the company a little bit towards that.

Brian: Okay. Then just from hitting in the landing page, it says, "SQLite on the edge."

Glauber: That's what it is now, yeah.

Brian: And I automatically already got it. I think I saw your previous landing page quite a few months ago, and I totally understand my use case for the stuff and you pigeonholed me correctly, yeah, frontend developer. I can be dangerous in SQL, but I don't want to go host my own databases and create droplets and do all that stuff. I just want to interact with the database, and I think that's what we got from all these no SQL solutions that were hosted. But I felt like a lot of those, we ended up hitting a ceiling because you don't have as much control when you have to go dig in and get deeper. So all the stuff you mentioned like Dino and SQLite, SQLite being... No, I'm thinking of MySQL. But SQLite is also similar, it's like a low friction.

Glauber: SQLite is The no friction thing, because your configuration is zero. It's essentially a B Tree in a file, right? That's what it is.

Brian: Yeah. I think it might still ship with Rails out of the box, when you do Rails New, and a couple of other frameworks.

Glauber: Our product is a little bit more complex than that, of course. So what we offer is the ability for you to develop in the environments that support it, for example, CloudFlare, for those who know CloudFlare for obvious reasons. Local developments, you can develop everything locally with SQLite. But then you're not going to be using the database as you normally use in production, like inside your application, because when you're doing a serverless function, when you're doing an edge function, first of all the function takes a couple milliseconds.

It's short lived, usually those pieces of infrastructure, they don't have local storage. You cannot even open TCP connections so it's very hard to connect traditional databases. So what our product allows and our product, by the way, is called ChiselStrike Turso, or just Turso, and we'll talk about the name later. Just notch it towards the explanation. The idea is that you now, because SQLite is so light, we can very easily and cost effectively replicate this to up to 26 regions. The CLI, you have a CLI. By the way, Turso just opened public beta a couple of days ago so you can go to the website and check it out.

You're essentially going to have a CLI, the CLI allows you to create a database and then create as many replicas as you want. During the public beta the number of replicas is limited, but that's the idea.

Very cheaply, very easily you create those replicas all over the world and then you connect over HTTP to the closest replica. So locally, you develop everything in SQLite, and now you have a database that is based on SQLite, that runs the same code so you don't have to do... You could do this with PostgreSQL. You can do something like, "Yeah, I'm going to PostgreSQL for production and SQLite for development."

But people who have tried to do this, they always have the abstraction layers, that always breaks so the code that you run in production is not exactly the same that you're running in testing. What this allows you to do is essentially this production database, you access through HTTP from your edge functions, from your serverless functions. Again, it's super lean, extremely replicated. You can replicate anywhere and be close to your users, which is what a lot of people in the edge want to do.

Brian: That's excellent. This is exciting too, as well. I remember I used to work at Netlify early days, and we did a lot of creative stuff with some of these SQLite databases to go store our logs, just the circ log data, one off, put it in a place. Actually, at one time it was all GitHub, back in the day. But I love that abstraction which is just GitHub, startup a prototype. But this is now one step above that.

I think one thing I want to point out to you as well, is that it's a simple abstraction and I know there's more complication behind that and there's more where you can go. But I think that onboard ramp is what's really exciting about what you're doing. I can get this started pretty quickly, and then if I need to dig deeper or expand the operation of what I'm doing, I want to have that at my fingertips.

Glauber: Yeah. Again, we need to have our own clients because, again, SQLite is this local thing and we wouldn't have the need for the clients if there wasn't a serverless environment. But serverless environments is all HTTP so you have to translate that. So the clients essentially allow you to write SQLite, SQL code, that is either proxy to the local file or to HTTP. So if your environment variable says, "Database URL." Says, "File Something." There you go, you're writing to a file. If your environment variable says, "HTTPS."

Whatever, and the address you got from the database, you're deploying to production. Simple as that. That's the gist, so you start very simple. We're not going for a product, by the way, that is shooting for, "Those are the 100 features that you want from a database." There are databases that serve that use case very well. We're going for this thing that, hey, this is extremely simple, works in your development, works in your CI, by the way.

Imagine how fast your CI is if you're just passing local files, instead of setting Docker images with databases and all that. Then when you go to production, it's just the same experience and now you can replicate this to all over the world, if you want, with a couple of API calls. That's what we're shooting for.

Brian: Excellent. I wanted to take a step back because you had mentioned Turso. So the company is ChiselStrike, the product itself right now is Turso. What's the plan there? Do you plan to have multiple products?

Glauber: Well, every company at some point has multiple products, right? I don't know. As the CEO, some decisions we have to make decisively and as fast as we can, and some decisions I think we just need to wait and see. I want to see how the market feels about it. The company, again with the company, Zilla, just as an example, the company name was Claudius Systems. Then after the pivot we became both the database and the company became Zilla. So I see the value of doing this.

Some other companies don't do it. I have, for example, Confluent, that has Apache Kafka. So there is a mix out there, and I think a name change comes when there is confusion. So it's too early for me to tell. I actually like the ChiselStrike name, I love it. And we have the logo right here, you can see, right? Turso just got this new mascot on the website. So I don't know. If there is confusion then we change one of them.

Brian: Yeah, that makes sense. Can we talk about more specific use cases of where you would go and reach for Turso?

Glauber: Yeah. So the use cases are very similar to the use cases where people are going to the edge for. And, by the way, if you have any suggestions to that least we're always looking for people deploying on the edge, et cetera. But those are the things, eCommerce is a big one especially if you have a global presence. You want your data to live as close to your users. A/B testing, personalization, user profiles, anything really that is global.

It's funny, because database people and as I eventually became, we think a lot more in terms of characteristics than in terms of use cases. So the characteristics of this thing are lots of reads, not a lot of writes, because SQLite is very limited in the amount of writes you can do. So a lot of reads, low latency from global locations, essentially, so everything that serves that.

Of course when you communicate that, you do need the use cases and those are some very common use cases that people are moving to the edge. For other reasons, like say you want to compute to the edge, for those use cases. But then what you end up doing today is that your data stays behind, and what Turso wants to enable is that your data can now come with you at an affordable price.

Brian: Yeah. So Glauber, I wanted to actually ask about the name Turso. So what's the story behind that? Because I don't think it's actually a real word.

Glauber: It is a real word.

Brian: Oh, it is? Okay.

Glauber: Just not in English. But that's the thing, my co founder, Becker, he's Finnish. It's super funny because usually products have a code name, and then after that you figure out a good name for the product. In the Finnish mythology there is a monster called Iku-Turso, and Iku as far as I understand is just a Finnish word that means eternal, so it's the Eternal Turso.

It's like a monster, I've even heard that Ctulhu was inspired by it, that may be true or false, I don't know. Becker told me that there are parallels between that and the Leviathan, so it's just a mythological creature.

But even funnier, is that he codenamed the internal development version this, but it wasn't even because of the monster. It was because of a Finnish beer that is called Iku-Turso, an API as far as I can tell. So we needed a codename, we needed a Git repository, so he said, "All right." So he created Iku-Turso.

Then we were thinking about names in the meantime, so the name that we were going for was Chisel Edge. Essentially ChiselStrike on the edge. But the more we talked to people, Turso sounded like a great name. Iku-Turso and I'm trying my best on the Finnish pronunciation.

Brian: You got me.

Glauber: Yeah, Iku-Turso is a big word and so Iku sounds Japanese and it's hard to get a domain, so we just went for Turso. Then Iku became the name of our mascot, Iku-Turso, that you can see on the website now. Yeah, that's the story. At the end of the day, it sounded great, people loved it, it had a great backstory, and all the names that we could come up with, they all felt very lazy. It was just like Edge-something, blah, blah, blah. Then we went for Turso.

Brian: Excellent. Yeah, I love a good origin story, also I love Finnish too, as well, apparently. Excellent. So now that Turso is live, what's next? What are the plans?

Glauber: Yeah, Turso is live in public beta now, as I mentioned. You can go, you can play with the product. Now we're very focused on making this GA, that's our next iteration, and essentially productizing. We already got some interesting things deployed in the platform, so allow people to essentially swipe their credit cards and become users. So it's a lot of work on reliability, stability, and then see where it goes.

Brian: Excellent. Well, I look forward to trying it out. Funny enough, of course Netlify is listed on the homepage, they're a great user. They would be a great user for this, and it seems like they already are. But yeah, you're part of the Jamstack fun as well. We've had a few of the companies in the Jamstack fun come chat with us, so congratulations on that. Yeah, onwards and upwards.

Glauber: Awesome, thank you. Thank you so much, Brian.

Brian: Yeah. So I do want to transition us to picks. These are jam picks, things that we're jamming on, things that are keeping us up at night, or maybe things that are keeping us excited about what we're working on because it could be music, food, et cetera. If you don't mind, I'll go first. I actually have a tech pick, and it's more of a broader pick. Every year I try and do a long series of go learn something.

Actually a couple of years ago I was learning about databases, back in 2020 because it seemed like that influx of a ton of new database tools to make it easier for me to write code and ship production stuff. But right now for the month of March, so by the time you hear this, I'll be completing the 30 days of AI. Specifically I've been seeing all these AI products and all these projects built on OpenAI, et cetera, and I've had the itch, "Oh, I want to try it out. Let me see if I can embed this in my product."

We'll get there. But I just wanted to learn more about the concept of AI because I was at GitHub when they launched Copilot, I got to see that get launched. I have good understanding of how that works, because I got to see the how the sausage is made. So I'm just going through all open source AI projects, so what I can find in free and public available on GitHub, and just going through the code. I'm writing a blog post, just give a quick description, try to keep it like 500 words around what the product does and then walk through the code of how it actually connects to the models.

Glauber: There's no better way to learn, right? Just do it and write about it. Writing is great, I think lots of people are very good at learning by doing. But the writing about it, I love it because it crystallizes the ideas in your head.

Brian: 100%. OpenAI, ChatGPT, those models that OpenAI has, the documentation is kind of dense and there's no search in it. So it's really hard to find the thing I'm looking for in there, so what's been nice is looking at someone else who's built a thing and then go to the docs to support understanding what they built. So it's been a great mental model for me to understand, "Okay, this is how you choose the models, this is how you update the frequency." I forgot the term, the deterministic level. And it's all stuff I understand, but trying to implement that and build it myself. I love reading other people's code to do that.

Glauber: It is a wild world out there with AI.

Brian: Yeah, it really is. I don't know if we're going to catch up to ourselves, when everyone figures out it turns out it's just a one person, one puppet master, which I guess may be Microsoft, is driving all this.

Glauber: It could be, yeah, it could be.

Brian: But I do want to point that all these posts will up on my Devtwo, so Dev.two/BDougieYo, and you can catch up when you hear this.

Glauber: Awesome. So my pick, Brian, I don't have a pick and I'll make my lack of pick the pick because the reason for that is I just had my daughter now. I now am a father of three, so I have my boy that is four years old, I have my other girl who is one and a half, and then my younger now who is four months almost. So between that, I have time for nothing. Between the startup and the kids. I feel like being a father was probably the best thing that's ever happened to me, ever.

It obliterates anything that my job could ever give me, so I try to spend all my times with them. But then again, the funny thing about kids is that you learn about a bunch of stuff by being... I learn all of the kid's songs and et cetera. One thing that's funny is that I wasn't raised in North America and I wasn't raised in an English speaking country, so I did not know a lot of cultural things that are in the cultural discourse and are used as an expression or references, et cetera.

I had no idea about them at all, and then watching my kids, I now understand. So the other day I was watching Shrek, and watching Shrek now that I understand all the references is very different than watching Shrek when I watched it back then. I spoke English, I was already even living in North America at the time, but I did not get most of the references.

Some I got, because I mean if you've seen Shrek, a lot of those general fairy tale that people would relate from anywhere. But some are very specific, like this guy torturing the Gingerbread Man and singing the song of the Muffin Man. You might not remember the movie, what does it say? "Do you know the Muffin Man?" And then the guy says, "The Muffin Man? Who lives on Drury Lane?"Right? Just all of those references were something I completely missed. So I'm essentially living a new childhood.

Brian: Amazing.

Glauber: That's what I'm doing, that's my pick.

Brian: I love talking to folks who didn't grow up here and I've definitely had a lot of colleagues and coworkers who either still work remote or came to the States, and it's always good to see things through their lens of them understanding.

Glauber: I'm not in the States though, because you guys haven't invaded yet. I'm in Canada.

Brian: Okay. So you did mention North America. But yeah, even talking to Canadians too, as well, there are some nuances and some differences in the culture. So it's always nice. I love that the world, we have global reach and my teammates are in multiple countries. I'm only just getting started, we're still a small team. But the fact that we can do that as a brand new company.

Glauber: And that's fine, and that's why we have a global database. Sorry, I just couldn't resist.

Brian: Yes, exactly. Iku-Turso. Everyone try it out.

Glauber: Yeah, there you go.

Brian: Cool. Well, thanks for the conversation.

Glauber: Brian, thank you so much for having me.

Brian: And folks, if you haven't tried out ChiselStrike or the new Turso product, definitely check it out and keep spreading the jam.