Glauber Costa of Turso on Startups, Naming, and Pricing
So Prime has you convinced to try to get everyone to say squeal, it sounds like, because you're saying squeal like and my squeal.
Speaker 2:Because it's because it's right. I mean, it's the when when you think about it, it's the only possible pronunciation. Because it's not a sequel. Like like SQL, it's too weird. And sequel is like, so what's the prequel?
Speaker 2:Do we need a prequel now? Is there a sequel? So Squeal. Look, he's just right, and that's it. He's just right.
Speaker 1:There's technically no problems with Squeal besides the fact that it maybe just sounds a little ridiculous to most people.
Speaker 2:But that's only until you get used to it. Yeah, if there's any Germans listening to that, the only phrase I know in German is ich glauben ich ben glauber, which means I believe I am the believer. Glauben verb means to believe. And then I am the believer, I guess. I guess.
Speaker 2:I don't know. I mean, that's better than maybe they're all trolling me. The entirety of Germany is trolling me. That's definitely a possibility.
Speaker 1:Yeah. When I when I saw your name, I I I assumed this whole time you're European because it I could, like, recognize it was, like, a more European sound.
Speaker 2:Yeah. I met a guy in Germany as well. He said he hated me because of my name, but his name was Jan Glauber. And he said, Before you started contributing to the Linux kernel, could just look into the logs of your contribution and grab for Glauber and I would find myself. But now you've completely ruined that experience for me because now there's you.
Speaker 2:Because obviously you want to do this with Jan. Glauber was his last name, there is my first name. But Costa Costa is Portuguese, which is my last name.
Speaker 1:Oh, okay. Hey. You said you're from Brazil, but I know like in Argentina, there's a lot of
Speaker 2:I was born in Brazil.
Speaker 1:Argentina has a lot of like European ancestry there too because I know a bunch of Argentinians that have European last names. Like like, very German Yeah. Last
Speaker 2:like, I guess one of the most famous Brazilian persons there is, like Giselle, she has a very extremely German last name. I mean, that's not my case. Like, my family, I think, is mostly Portuguese. Just my name is the is the.
Speaker 1:Okay. When did they go over to Brazil? How many generations ago?
Speaker 2:How do I know? I was actually like, I'm gonna get canceled for that one, but here we are. I was I actually had my my Brazilian citizenship revoked. They don't allow me in the country. Yeah.
Speaker 2:Oh, wow. I absolutely despise soccer. I hate it. So it's like, the f out of here. Don't ever come back.
Speaker 2:And I I don't come back. I mean, I just I don't have a lot of cultural connection
Speaker 1:Yeah. So to speak.
Speaker 2:Mostly because of that. I I don't like soccer. So who are you?
Speaker 1:Yeah. I mean, I'm the same way. I'm like, at this point, I'm fully American. Like, I haven't been back to India in fifteen years maybe. I am an American citizen, but I think I have I forgot what it was.
Speaker 1:I have this thing where I'm technically, The US doesn't recognize dual citizenship, but, India is fine with it. So I think I'm technically it's like my backup. In case something really really bad happens, I do have a backup. But again, I have no real connection there at all.
Speaker 2:Always good to have a backup.
Speaker 1:What you're saying, you're talking about you used to be or you're a contributor to Linux kernel. So I guess before we get into some stuff, set a little bit of context. So, you are now a founder of a company called Tursot. Prior to that, you worked on something called Silla, which I'm actually familiar with and we can kinda talk about that a little bit. And as well as you were a Linux contributor.
Speaker 1:So tell me more about like how all that came together and kind of your career path up to trying to work on Tursot.
Speaker 2:Yeah. Yeah. Absolutely. So, like, when I when I started my career, like, I didn't much care about startups or anything like that. I again, I I think in the environment that I was, it wouldn't have made sense anyway.
Speaker 2:But, like, I really liked open source. And I think we had some exchanges. You might have been part of some of them on Twitter. But when I was doing open source back then, first of all, I didn't do open source because open source was the dirty word. I did free software.
Speaker 1:Right.
Speaker 2:Right? So was actually a member of the Free Software Foundation and Richard Stallman and all of the things like that. And I still think, by the way, that if Richard Stallman, I don't know if we can curse or not, but if he wasn't such an asshole, we will probably be in a better position because the ideas of Free Software are great. Just his personality is intractable. But anyway, this wasn't in the original question.
Speaker 2:So I like Free Software, or open source, we call it, the still version today. And I like the low level stuff. I was never too much. I mean, this thing about the web and later on mobile, it never attracted me as a developer. I always was fascinated with the Linux kernel and systems level software in general.
Speaker 2:And the moment I found, oh, I can actually read the code for this stuff, that sold me 100%. So I started there and I was just in a student school, so I was contributing. I have this story, I try to find it, just for Twitter's sake, where my first contribution to Linus Kernow, unfortunately, this happened in 02/2004, and I think the oldest thread that I could find was 02/2005, like an archive thread, so I couldn't find this message. My first contribution to the Linux kernel, this guy, I'll never forget him, Ol'Varro, he comes and says that dispatch is wrong in so many ways. It has only three lines of code but introduces seven bugs, And it should never be allowed close to a computer again.
Speaker 2:That was my first introduction. Linux is known to be this very welcoming place. I don't know if it's better or not today. But I did this for Anyhow, I got super sad about that, but it It affected me for a couple of days, but I kept doing it. And I just started contributing for fun and giggles.
Speaker 2:Obviously, liked it, so I wanted a career out of that, but I wasn't clear at that point. So I started doing it. I eventually got hired by Red Hat. So I worked in total in the Linux kernel a little bit before Red Hat. I had a small job in a company in Russia.
Speaker 2:That's when I moved to Russia, which I did to work for this company for another two years. In total, I spent like ten years doing this. And one of my major things that I did in the Linux kernel was I was a part of the KVM team, the virtualization, the hypervisor that AWS today uses. And I got to be very good friends with the creator of KVM. And when they started a startup, they would say, hey, maybe now is the time for me to stop looking into just like, code, code, code, code, code and go work in a startup environment.
Speaker 2:I don't think at the time I would have worked very well in like a general purpose startup. I mean, was a very heavy infrastructure startup, so I joined. We were trying to do something that did not work at all. So we spent a lot of time doing that. That was called OSV, which was an operating system like a library just for dimension.
Speaker 2:And then after that didn't work, that company pivoted into So that's how I ended up with Silo. At the time, I knew nothing about databases. You could argue that I still don't. You could argue. I mean, why not?
Speaker 2:Just, it would it would be fun. But, that's how I got introduced to, like, the database world and and etcetera.
Speaker 1:Yeah. So I think, I think that's maybe where it's not that their paths crossed, but I guess your work crossed crossed me at least. Yeah. So I was I was pretty early on in my career at the point. I was working at a company that was just collecting a ton of ton of analytics data, and we deployed Cassandra.
Speaker 1:That was back in the day, you know, like deploying Cassandra meant, like, running up your servers and, like, creating a cliff, like, doing everything or it's not it's not like there was a managed Cassandra. Actually, was a managed Cassandra option. I'm I'm forgetting the name of the company. Was it Datastax?
Speaker 2:The training one? No. Datastax did manage Datastax was the main company. They did manage Cassandra much later. That was just the cluster
Speaker 1:Oh, it's cluster.
Speaker 2:Bunch of other companies. Yeah.
Speaker 1:That's the one.
Speaker 2:Good guys. Super good folks.
Speaker 1:Nice. Yeah. But, at this time, we were kind of running it on our own. And I was like, I like I've I've I think I've had a weird career, maybe your career is also maybe a little bit nontraditional. Spent a lot
Speaker 2:To say the least.
Speaker 1:Terms of like databases, I think most people when they start to build stuff, they will use like a relational database and they'll spend most of their career there. And maybe every once in while, they'll like interact with like a non SQL type database. I had this weird inverse path where I mostly work with non SQL databases for a long time and only more recently I've been using SQL focused databases.
Speaker 2:So so look, my my my career, I think, is even weirder than that because before I used the non SQL database, I wrote one.
Speaker 1:Yeah. That's funny.
Speaker 2:Like, I wasn't a user of that. Like, I eventually Honestly to God, I think the founders know that. I'm very good friends with them. I love them to my hearts. I considered quitting.
Speaker 2:Because when we were pivoting, was like, what the hell do I know about this? Doesn't feel like I know about it. Like, so again, I was not the person ideating that we should build this, but we decided to build this. I was like, I feel very out of place. The first two months after we officially pivoted, it was like really a bad time for me.
Speaker 2:Because imagine that I came from this perspective, I've done this thing that I know how to do for ten years. And then I'm in the startup where the whole reason I'm in the startup is because we're doing this, the stuff that I'm really good at. Talk what you want about, oh, you have to be flexible, etcetera. After ten years, it kind of gets set in your ways, it also easier said than done. Eventually, I got to the point where, hey, look, now I'm in a good place.
Speaker 2:Cruising. But my first two months were, like, a really complicated, man. Because but then I wrote a database before I even even knew about one. I just I had no idea how NoSQL worked or anything like that worked.
Speaker 1:Yeah. I mean, once you're ten years into something, you're, like, used to being pretty good at it. And then when you have to shift, you now go back and use pretty
Speaker 2:good stuff. Is not easy.
Speaker 1:Yeah. It's tough.
Speaker 2:This feeling is not easy.
Speaker 1:Yeah. But it's also, like, the most important thing to get through.
Speaker 2:Yeah. Yeah. I feel it today because I've been a developer, a low level systems programmer for twenty years now, you sum up both. And I'm a founder. Like, the hell do I know from being a founder?
Speaker 2:Like, no nothing. Yeah.
Speaker 1:It's a it's a painful feeling, but it's also what prevents you from getting bored. Right? I'm sure, like, you do anything for long enough, it's like, you there's not as many opportunities to to feel like you're you're progressing. So those resets are good. So yeah, we were we had a Cassandra deployment and I think that's when I fir I think Silhouette had just come out or like, it came out of base.
Speaker 1:I forgot what it was but it came across and we were constantly oh, here's the other thing. So we did not know what we were doing when we were sort of first started using Cassandra. It took us a little while to understand the idea of partitions and hot partitions and how you should like data model stuff. So we definitely went through that cycle of doing it wrong, wondering why our cluster was, like, just dying. But also, at that point, we were like, man, this is this model is interesting and it's useful, but I really felt like the Java aspect of it was kinda really killing us in a lot of ways.
Speaker 1:Mhmm. Just dealing with a lot of those side effects you have when you are running such like a large scale Java stateful thing. Yeah. And it's still kinda it still wasn't C plus plus right? It was like, wired compatible with Cassandra and then, like, the under the hood, was completely from scratch.
Speaker 2:Yeah. C plus plus. And then, like, I I will never forget when we announced, still, there was this message on the Cassandra mailing list, like, people commenting on it. And a bunch of people Ben, this is the reaction the favorite reaction of the Internet. Like, those are a bunch of idiots.
Speaker 2:Like, oh, we had another people you had another group of people claiming that they're better. How can they be 10 times faster? Because, like, c plus plus is is and then it starts CPU bound and IO bound and blah blah blah. Like, nobody deeply looked into that. Yeah.
Speaker 2:And then it's just Oh, they must be running everything in memory. That's why it's faster. Yes, we wrote the whole thing in C plus plus but then the architectural differences between Cassandra and C Sila were so immense. The 10x was usually the baseline. We were much more than 10 times faster.
Speaker 2:By the way, I'm watching Bun now with that feeling of, Hey, those guys are doing what we did to Cassandra back then. I know how that story plays out. I'm wishing Jared here all the luck in the world. It's tough. It's hard.
Speaker 2:He's already starting to hear some of the things that we heard back then. Oh, your sadness is dropping replacement, but it isn't really because there is this different and and those differences will be there forever, right? So it's a tough fight, but it's a fight worth fighting because man, like, we we need more efficiency in our lives, I guess.
Speaker 1:Yeah, know. It's definitely an important thing. I think especially when something new comes out, I talk about this all the time, people will point to things that are missing as though it's like relevant. There are some things in BUN that are missing, but there's nothing architecturally that prevents those things from eventually showing up. So I think people get hung up
Speaker 2:We on we hit we hit an issue an issue with Thursault running with Bonn as well. So I get it. But what happens is from the point of view of the person, like Jared or like us at Silla, what you do is that you look at the market, you look at how people are using this, Then you notice that, okay, there's a thousand people that use this. This feature is needed by 800 people, and then I'm going to go and code that feature. This other feature is needed by 10 people or 20 people, etcetera.
Speaker 2:So maybe I'll do this later. I'm not going to do it at all. So if a thousand people try it and they say, well, I just dropped in and it worked. And then some other people try it and it doesn't work. Is it drop in replacement?
Speaker 2:I think it is because it means wasn't dropping replacement with Cassandra at times. And I guess Node has the same thing. You change something here, you change something there. So yeah, it's a different thing. But at the end of the day, you can definitely claim it is.
Speaker 1:Yeah. Yeah. I think people get hung up on like the little details, but it eventually will be and there's nothing preventing it from covering it. And that's kind of the nice things about selling into a market that's so clearly defined like when you're doing drop replacement. People will just tell you exactly what you need to do and in what order.
Speaker 1:I think when you're building things that are a little bit more like brand new or it's not really established, you're constantly like, what do I do next? I have these 100 things that I can do. Which one do I do? Which one matters? The moment you have something so established, it's like the roadmap is included.
Speaker 1:I mean, it's very challenging in a bunch of different ways. But the question of like, what do what should we be doing isn't, you know, as as prevalent. You worked at Zilla. Did you have you been there since then and you'd started or so? Or did you did you stop by anywhere else?
Speaker 2:Full story like, the full story is that, like, after in 2020, I left Cilla. So I was I I knew I was ready to make the move. I mean, I've been there for almost eight years and and etcetera. But then in 2020, everybody remembers what happened in 2020. It just wasn't the right time.
Speaker 2:Was moving home as well as moving to a different city. I recently had my first kid. So I joined Datadog. My plan, of course, no joke, my plan was to stay at Datadog for a couple of years. I said, two years, four years, maybe let me get my full vesting.
Speaker 2:Because that's the time, I I never liked doing a lot of job hopping, which is what I said, I've done almost eight years of Red Hat. And then maybe I'm doing like they do with the popes. There was this story that with popes, they have a long, reigning pope, and then the next one, they try to make it short. I've kind of did this by accident. After eight years of Red Hat, they had two years that I stayed in this company in Russia.
Speaker 2:Then I stayed eight years with Sila and one year at Datadog. Again, I wanted to do more, but I think fate wanted this way. I had a couple of investors that were reaching Capital in 2020 was very, really abundant.
Speaker 1:Oh, I remember. Good times.
Speaker 2:Oh, Good times. I had a bunch of investors reaching out to me, essentially, Hey, if you're ready to start a company, which I always wanted to do, I'm ready to sign a check. And then my co founder and I, we doodle on some ideas. The first idea that we hit was also not through so. We started doing something else, which is super funny because it was always like, when I started my own company, I had this trauma of the company that became Sila doing this extreme very little validation.
Speaker 2:If they'd done, I've seen none of that. And then we ended up pivoting because nobody wanted to use the product. In your very wise words, the words that you are very famous for on Twitter, they had zero users after two years developing. I said, know, thing of when I have my kids, I'm not going do that same thing. When I have my own startup, I'm going do tons of validation, which I did, and ended up with zero users anyway.
Speaker 2:So that taught me a lesson. That taught me a lesson, right? Just easier said than done and validation and where do you look for those signs. So it's essentially an opportunistic thing. I I saw the capital.
Speaker 2:We had an idea that we truly believed in. We thought, hey, this is a good idea. This is something that we want to do. And then I talked to Pekka, I said, my co founder, and said, hey, Pekka, like, let's let's do it, man. And just he was a little bit frightened, you know, because Europeans, they're they're not as adventurous as we are.
Speaker 2:Like but eventually we decided we decided to do it.
Speaker 1:Yeah. So I mean, the validation thing is really interesting. I I did the basically the exact same thing. And it's funny, like, you can know all this stuff, and then until you do it, you just make the exact same mistakes that you thought you were gonna avoid.
Speaker 2:I ended up I read I later on, like and and I almost dislike the guy now. I'm kidding. I love him. One of my best advisors, Pete Hunt, the creator of React, if you're hearing that, as you know, I love you. I got borderline mad at him for not mentioning this to me before.
Speaker 2:Right? But obviously he recommended me a book that I read, again, recommended to your audience here called The Mom Test. Have you heard of
Speaker 1:this Yes. I know the concept. I didn't know it was a whole book.
Speaker 2:Yeah. It's a whole book. The concept is pretty simple that I had never done before. If you ask people what do they think of your idea, they're going to lie to you. So the book is about strategies to extract the truth from a group of people that you know are going to lie to you because your mom, she's never gonna say, oh, sucks.
Speaker 2:It's a great idea. Oh, of course, a great idea. Go for it. How do you extract the truth from people that are lying to you? And reading that book, I mean, saw this story of many things that I've done wrong, many, many things that I've done wrong.
Speaker 2:You think you're validating, you think you're validating, because you're talking to a lot of people, you're asking a lot of questions, but then everybody's lying to you. And in some ways you're worse off by having tried to validate incorrectly than not validating
Speaker 1:at all. Because now now now you're like very committed to a direction that's not maybe maybe sound. Yeah. It's this stuff is so counterintuitive. Like another thing that I run into is, I think oh, I see a lot as people pick like ideas that are too small.
Speaker 1:The emotions behind it kind of makes sense. It's like you are trying to start something from zero. You gotta pick a narrow area to focus on so you can, like, start somewhere. But you still need an idea that's huge. Otherwise, like, you're just gonna get stuck in this little tiny thing that, you know, you're never really gonna break break into something.
Speaker 1:So that's another mistake I've made where you had to find you had to make sure you start small, but your entire idea can't just be just that. And we're listening. You listen to me say this, you can hear me say this, you think you understand it, but you're make gonna this mistake too. Nobody can save you time. This is impossible.
Speaker 1:It's one of the hardest things that, that you have to deal with. Maybe you wanna give a quick description of what torso is, and we can kinda talk about what was so compelling for you guys to start
Speaker 2:So again, we didn't start Terceau. So the compelling the compelling thing was a was a different idea. So the original project that we had was called Chisel Strike. Mhmm. I'm I'm getting convinced.
Speaker 2:I mean, this is super hard thing for us to admit because, like, as a founder, you kind of love your ideas. You you always tend to think, I have the right idea, but the wrong happened and this happened. It's easy to put blame outside. But I think I put the blame squarely on us. I think we ended up with Y Combinator, and I saw a great video of them, describes as a tarpid idea.
Speaker 2:Like an idea that is very seductive. And then you look at the market and there is no established players and then you think, wow, this is my opportunity. But again, the reason there's no established players is that people tried before and they they suck into the tar pit. Again, I'm not going to spend too much time on it, but essentially, we had a couple of good ideas as part of this Tarpit idea. One of them was that Sqiuolite was a great database for today's workload.
Speaker 2:Again, go back to MongoDB in 2010, the web scale kind of thing. This kind of workloads that people run on MongoDB back then didn't grow that much. So the workloads are growing, but they're growing very slowly. People talk about data growing exponentially. This is true for some subsets of data, but the machines got a lot bigger.
Speaker 2:MongoDB back then, today can have a device they rent from AWS with a terabyte of NVMe like it's nothing. And big data back then was like 100 gigabytes. So we understood for today's workload, Sqiu Lite is the thing to do. And it runs locally. The developer experience is the best possible.
Speaker 2:And it's super cheap, so you can really put it everywhere. We knew that the edge was real in a sense because there's a lot of confusion about what is the edge and is this a runtime or whatnot. I didn't come from this industry, so this whole thing about edge runtime, this was news to me. Was looking into the edge as like, hey, this thing between the cloud and you. Yes.
Speaker 2:So this is real. However you want to call it, this is how you get latency to this in place. So we knew this was a thing and then we knew how those front end developers are all trying to deploy to the edge. Let's look into that. We knew Sqiu Lite was part of the answer because MySQL and Postgres were not really up to they were just too heavy.
Speaker 2:We've done a bunch of stuff around that. We embedded Deno into we had something that was Deno plus Sqiu Lite plus a bunch of stuff together, and that was Chisel Strike.
Speaker 1:Gotcha.
Speaker 2:Over time, we kind of noticed that we weren't really getting the traction that we needed, but the database part super people really liked it. It tells you a lot, by the way, about market and about there are some ideas that potentially are a good idea, depending where and from whom they come from. And what a lot of people told us is that, look, your idea is very confusing because you're claiming to be a code platform because there's TypeScript, but you're also a database. Where do I deploy this? I mean, is this something I deploy to Vercel?
Speaker 2:No, you deploy a front end code to Vercel, but then you deploy your back end code to us. So there was some confusion in there. And being just a database allow us to get the nice parts of that idea, like the parts that were resonating more with the people. Put this in a category. I mean, the category thing matters for people who are thinking about creating your own startups, matter a lot more than you would think it matters, which is which category that you choose to play.
Speaker 2:So it's category that we understand as the founders. It's a category that developers understood. Lots of the resistance the developer had to a point URL to this service. When you say point as URL to your database, this resistance is gone. And again, we knew that Squirrel like that was the way to get this thing replicated everywhere at a low cost, which is what we specialize in doing, and go from there, and develops locally.
Speaker 2:So the good parts, we took the good parts, said, Let's try to build a company now just on top of that. That was like a billion, trillion times more successful, of course.
Speaker 1:Let's talk about this edge. So I also agree with the whole edge runtime stuff. I don't know if you remember or if you saw, I was very upset for a couple of days being like, can we stop it with this edge runtime thing? It's like the worst name thing in the world. Everyone is so confused about it whenever we talk about it.
Speaker 1:They're like, wait, like nobody understands because sometimes some people think about it as like the geography, some people think about it as a runtime. And then the thing that kills me that proves my point is edge runtime is a bad name if you now also release a project product called Regional Edge Runtime. They just added the word regional.
Speaker 2:Which I don't yeah.
Speaker 1:Yeah. It's just like, just call it something else, please. But I think it's too late. I think it's it's messed up. The naming I get I go crazy with the naming stuff because
Speaker 2:Oh, and there's more. And there's more. The the part that annoys me the most is that, like, again, application developers put it this way. And I'm saying that because it's not a mistake that I believe I've seen people like you making, like people in infrastructure. So maybe it's just because like how Vercell and CloudFare have been marketing this, but application developers tend to associate too much edge with serverless.
Speaker 2:So a of the things they say about the quote unquote the edge are really limitations because of the serverless model, not because of the edge. And then because of this specific platform. You hear stuff like on the edge. So the other databases, for example, like PlanetScale, Neon, for example, they claim we have an edge database. Why?
Speaker 2:Because it talks over HTTP. Why does that make you an edge database? Well, because the edge only supports fetch. No. Those specific places like the Vercel and Cloudflare, it is not even true anymore because you look at Cloudflare, they're changing now their workers to do TCP.
Speaker 2:So what is an edge database? And our response to that is that an edge database needs to be a database that replicates There are two things that makes the edge the edge for me. First of all, massive replication. Because the edge in any incarnation is that I'm executing my code close to my users. Boom.
Speaker 2:So if the data is far, you're either not better or at worst slower now because you have many round trips to the database before it was simpler. The difference between deploying to the edge and then I'm everywhere and deploying to AWS in five regions with five Kubernetes clusters is that when you do the latter, you're very aware of where your regions are. You're very aware of what's going where. Things are very explicit in your design. And I think when you think about the edge, those things are transparent.
Speaker 2:So you push your code out there, be it to a server full edge offering or a serverless edge offering, and shit kind of just works. And you don't have to be thinking about where is my stuff right now. It is where it needs to be. So for me, an edge database is not only a database that is replicated in a lot of locations for a reasonable price, but also a database that doesn't require you to worry about where my replicas are, how do I get there, which replica has which data. This does have to be transparent.
Speaker 2:That's So what we've done with Thursault. It happens to be over HTTP because we were sure. If everybody thinks this limitation is there, let's do it, which it is in practice for those runtimes. But that's not the most important part. The important part is how massively it replicates and how you don't have to worry about any of that.
Speaker 1:Yeah. Yeah. Exactly. I think that confusion is definitely there. I think when I was writing about this, pointed out because a lot of people were saying like, oh, you can't deploy Node.
Speaker 1:Js to the edge. And I was like, well, here, use AWS Lambda at edge. Yeah. Okay. It's not like fully replicated like everything else, but that is Node.
Speaker 1:Js. You can run Go at the edge if you want because they support Go functions. If you use fly.io, you can deploy whatever you fly.io.
Speaker 2:Yeah. Fly. Deploy whatever So, you
Speaker 1:yeah, I think the thing that kills me is the confusion because it just makes communicating super inefficient. So, like, every single day amongst millions of people in this space, there's, like, all these little misconceptions and infusions. And so that's why I'm, like, obsessed with getting naming right because you can just save a lot of back and forth of time. People get into arguments. People get into arguments because they just are misunderstanding each other too.
Speaker 1:Right? So that's what bothers me.
Speaker 2:And and and for example, this week this week is our it's the middle of our launch week. So we have we have launched two things. Well, more more than two things, but, like, two things for me are very important. One of them, if you had checked out, that was our launch on Tuesday, the twenty sixth, is embedded replicas. Embedded replicas essentially allow you to get your So Torso now becomes your primary.
Speaker 2:Your rights go to Torso, and it can still replicate at our infrastructure, but it can also have a replica in your infrastructure, whatever you want, be it on AWS, on fly.io, etcetera. So this is, for me, to some extent, the real edge because now it's like, hey, what is the closest point that I have to my user? I can put the database there. First of all, it's microsecond latency, right? Because you're running.
Speaker 2:But to do that, I need a file system. So this will not run on the Vercel Edge. This will not run on the Cloudflare Edge. But you can put anywhere you want. You can put it on Fly.
Speaker 2:You can put on Coyab. You can put really on a server that you want. And it even works with environments in which you don't have connectivity. If you have no connectivity, of course, that doesn't work. But if you have like intermittent connectivity, you come back online and then you sync to the primary.
Speaker 2:But from that point on, you have like local reads. Again, this is us taking stuff to really, let's call it the edge of the edge. But this is also edge. This is also part of the edge. This is also part of, okay, how do I get my data as close as possible to my users?
Speaker 2:People were still running some stuff on AWS. So, if, you know, for you running on AWS in a specific region, the closest place to you is there. It's not like, in in in my infrastructure. Right?
Speaker 1:Yeah. Yeah. That makes sense. Yeah. The other thing I think you mentioned briefly is, I think people heard the word edge and they started to think, okay, everything is gonna move to the edge.
Speaker 1:So they started moving their application code to the edge. But then, I think you mentioned before like, if you're doing, let's say, three round trips to your database, those three round trips are now really expensive, and your application probably is gonna be slower. So I think
Speaker 2:Unless you unless you move your database to the edge as well, which is but then again, it has to be it has to be actually moving the data and not just like, oh, database at the edge because it talks it
Speaker 1:should No. Yeah. Physic because yeah. I I think the the metaphor I use is, like, imagine a string with a bunch of beads on it. One's a user, one's your application, one's your database.
Speaker 1:You move your application closer to the user and you don't move your database, you just now have a problem. So you guys have move everything closer. But even if you move your database closer, it's now further away from all the other replication nodes. And that's something I wanted to ask you about was Mhmm. With this model, kind of what are the new things you need to start considering?
Speaker 1:Right? Because I think a lot people that are used to like a single master database, they may not be used to considering certain scenarios that can that can happen.
Speaker 2:My counterpoint to that is that lots of people think about a database of a single master, yes, but they're usually thinking about that plus a cache. There are very few deployments that don't have some form of cache. If you're thinking about replacing those two things together, which again, don't have to, you should, then things become a little bit easier. But to your point, when you have a database in a single place, every time you read the database, everything is 100% consistent for everyone at all times, in every place, in every situation. When you have something like what we're providing, then you have relaxed consistency.
Speaker 2:It's not that different than reading from a read replica from, let's say, Postgres or any other database that people are used to. That read replica can be a little bit out of sync, but depending on the model, which then is the model that we follow, you can never break a transaction. So in Sila, for example, Cassandra, which was full eventual consistency.
Speaker 1:Right.
Speaker 2:As you probably remember, you never truly know what you're reading from database. Never. Like those mutations are applied and they can happen out of order. And you write your two keys, if you hit this node, it will have one of the keys, but it won't have the other. So that is full eventual consistency.
Speaker 2:And then you have a very expensive process running on the background that is finding those differences and merging those differences. That's not what we do. So what we do is that once the write First of all, can write from any replica. Don't talk too much in those terms because you can write from any node. In fact, we only give you a single URL.
Speaker 2:You have the single URL and you're automatically routed to the closest location. You can always read, you can always write from those locations, always. But the writes always go to a proxy that we consider the primary. So if you happen to hit a quote unquote replica, the replica itself will write to the primary, wait for the write to complete and bring it back. As long as you're always, by the way, as long as you're hitting the same replica, you do have this vision.
Speaker 2:So for the application that is like for the user, imagine you have a user in India. So the user, if you have a replica in India, very likely your user is always hitting same location. So that person will have a fully consistent view of the timeline. The person who's hitting you from Australia may see data that is a little bit behind, but always transactional. This is called essentially snapshot isolation.
Speaker 2:So always transactional. A transaction is never broken. They're always applied in every replica in the same order. It's similar. If you have a long standing transaction on a database, so the transaction is going on, let's exaggerate for minutes.
Speaker 2:The clients that are coming before the transaction have committed, they haven't really seen the state update, right? So it's a similar thing. I mean, people who are in different locations, they are seen in an older state, but never out of order and always transactional. If you say, for this specific request, they absolutely need to select the latest stage and etc, then you can force this request to go to the primary, you can read from the primary, you can pay the price. But you can have So it is one thing that developers have to consider.
Speaker 2:Am I okay with this request at this point being transactional? Like in the same order that everybody's seen, not missing any data until that point, but maybe a couple of milliseconds in the past. If you're okay, then read from a replica, right? But if you're not okay, maybe again, should be using a central database, which is
Speaker 1:Yeah, that makes sense. Yeah, mean, it's like the, what they call it, read after write consistency or whatever.
Speaker 2:Read your own writes. That's what we have, like read your own writes. So if you write, let's say, if I'm on a replica and I write, this write will not be acknowledged until all the the state has come back. So you're gonna always read your own rights. Right?
Speaker 1:Got it. Got it. Yeah. Yeah. Because I I think that that's probably maybe the most common case that people would run into.
Speaker 1:But, yeah, very cool. So I am kinda curious. So what kind of other certain types of applications that are that you guys see more often, or is it kind of widespread? Do all kinds of stuff like
Speaker 2:Yeah. So I mean, there there are there is a couple of clusters forming. And again, this week, we're hoping to expand to one more cluster. But first about the ones that we already see, the applications that want to be fast from anywhere. So there are a group of people who And one example, we have the use case on our website, a super fast site like triptojapan.com.
Speaker 2:Always talking about them because their site really is like incredibly fast. Like the first time I talked to their founder, he was like, look, I'm selling trips to Japan. My customers are everywhere in the world except in Japan. And I was selling those, you know, you're going there. So I'm trying to sell these personalized bundles.
Speaker 2:I think it's a very latency sensitive thing. I mean, I want to provide you like, I don't want customers giving up. I want to provide you with always a fast experience. And where? Like pretty much everywhere.
Speaker 2:So deployment on Cloudflare Workers using Torso. The other thing that we see a lot are use cases where you essentially are a platform. So again, because of SQLite, because this thing runs locally, if you have an SDK, you have something that you wanna ship to people, put Dino is doing this. I mean, they're doing something similar than what we're doing. They just build their own infrastructure.
Speaker 2:But with us, you can have something like what Dino is building with Dino KV, except in much shorter time because we built a lot of the infrastructure as well. And one example that we have of that is Fermi on a WebAssembly platform. They're doing a similar thing. So you use their SDK, their SQLite locally, everything works, the database is always there, so you can build those advanced functionalities that depend on the database. And when you deploy it to their platform, then Torso provisions the database for you.
Speaker 2:Everything is API based. And again, the other thing that we hear a lot, and this is not, again, we don't have use cases with that yet, but people come to us and say, hey, you guys are SQLite based and it's just a file. Why is it that you're limited to three databases in the free plan and five databases in the Scalar plan or six databases in the Scalar plan? I want to write a multi tenant SaaS application. And again, I heard this word from a variety of people.
Speaker 2:I did not know that this was a use case, right? Because it was like, naming use cases is as hard as naming anything. But people would come with this specific wording. Like, I have a multi tenant SaaS and I want to give a database per each customer, which is why yesterday we upped the limit. Again, we can go into the technical details as to why we did it this way and why it wasn't possible before.
Speaker 2:But essentially, as you can see on the website, we upped the limit from three databases in the free tier to 500 databases. Oh, wow. And on the scalar tier, instead of six databases, I have 10,000 databases. Wow. And this should allow you, as long as you have users, of course, and so people who don't have users who listen to DAX, okay, maybe only need a database.
Speaker 2:But as you increase your users, hopefully, then you can still give them a database per user and keep your costs extremely low. And we did this by making our platform itself multi tenant. So the way we used to do it is that every you provision a Truso database, we provision a VM for you with Firecracker, full isolation, etc. But then we move to our server, allowing more than one namespace or more than one file per server. And now in the same server, you can have all of those files in.
Speaker 2:And again, if you're doing per user data, each one of those databases maybe have like a megabyte or a 100 kilobytes or something like that. So they're very small. So provisioning a full volume for that database doesn't work. But we essentially made everything multi tenant, and now we can give you this unreasonable amount of databases.
Speaker 1:Yeah, it's very cool. It's a use case that I think is, like I said, very common. I worked at a company and we had that exact model. We used, are you familiar with LMDB?
Speaker 2:Of course, I am. Yeah.
Speaker 1:Yeah. Yeah. So LMDB is like is very cool for what it's optimized for. It's just a key value store. Goes to a single file memory mapped, extremely fast for reads.
Speaker 1:And we basically have one of those per customer. We were in a compliance sensitive space, and it was actually very nice because we never had to we should get like a giant security questionnaire of like all these things. The moment we said you get your own database, half those questions they don't need to ask and they don't have to worry about. It's just something that makes people more comfortable. The other nice part is you don't have to handle the concept of multiple customers in your application code.
Speaker 1:So usually people need to remember, oh, with every query I I I'd write, I need to make to make sure I add like where customer equals whatever. And inevitably you forget to do that in one place, you're accidentally querying stuff across customer. When you do it, when you have a database per customer, you just configure that in one place and then all queries are guaranteed to be limited. So yeah, that is a very cool model and, I haven't used that as much lately, but it is something that it's a very clean if you're willing to set that up.
Speaker 2:Yeah. Again, we just had to build it. Because again, going back to our previous thing about validation, this is validation. This is not me talking to a customer and say, Hey, would you like 10,000 databases? Of course their answer is going to be yes.
Speaker 2:Of course. Who would say no? And then you ask them, hey, do you think it's nice? What if I offer you this feature? They say yes, but do they use it?
Speaker 2:No. But what we had with this feature in particular was a stream of users. You go to our Discord channel, this is there all the time. You go on Twitter, you don't believe me. Go on Twitter, you look for Turso.
Speaker 2:And there's a lot of people asking for this on Twitter, and they're all asking the exact same thing with the exact same words. If Ryan's here and there, but like, hey, I want to do a database per customer. Intuitively, I think it should be doable in your model because you're based on Squeele Light and people are doing this with Squeele Light. Why can't I do it with you? Yeah.
Speaker 2:Maybe I'm wrong and nobody's going use this. The week is just getting started. But in my book, this is a lot more validation than the usual, Hey, go and ask and see and talk and take notes. It was good on a personal level, that's what I mean. It just taught me the real difference between listening to your customers.
Speaker 2:There's one way to do it and there's another way to do it.
Speaker 1:Yeah. That's actually the best part of actually having users, just they'll just tell you and, like, demand things. And oftentimes, it's always like, should we do this? And then we you can just say, let's wait till people start complaining. And when they do, you know you have So to do it's it's funny, like, the hardest time is when you have no users because you're just by yourself in your head.
Speaker 1:The moment you have at least some, it just gets a 100 times easier.
Speaker 2:So this this is why I like the stuff that you talk about on Twitter so much because when you have no users Man, if I tell you the amount of stuff that we've done in the early days of Terso, because imagine that we were coming from a pivot, we were like, Oh man, we screwed this up. What's up? In our mind, the most important thing was, will people want this? We don't have another chance. If we come up with something that people don't want it We had the theory that people would want it because that's the part they liked the most about the whole story before.
Speaker 2:But so what? Just if I don't build something that people want it now, I don't have another chance. That's what crossed our minds, right? So man, things that we didn't care about in the beginning, will this service scale? Like, if I have 10,000 users?
Speaker 2:And I was like, look, I'm happy if I have 100. Are things automatic? It's another podcast just for me to tell the whole story of the kind of corners we cut back then. Yeah. And then what we saw, now it's picking up, or now users are getting, okay, now we're going to sit down and we're going to rearchitecture this thing.
Speaker 2:And the multi tenant is just one example, but you need to have users. And to have users, you don't need Kubernetes. You don't need microservices. You don't need scaling. You don't need any of that crap.
Speaker 2:Right? Just you need to put it out there.
Speaker 1:Yeah. Yeah. You to get it chipped. Yeah. And it's just like the thing that always gets me is it just gets so much easier.
Speaker 1:Like the hardest you'll ever work and think is very, very early. And like you have new challenges and and new problems, of course. But, for me, once a company is past the stage of like, is what the most miserable time is when you don't know if anything you're doing will ever be paid attention to by anyone. That's like the most miserable time. But you gotta go through that and I think for me, I think people have a lot of opinions and they talk about all these things and I I can kind of look back at younger versions of myself and see how I thought and see how I thought, like, how I expect expected things to work.
Speaker 1:Then I look through how, okay, when I was actually in the seat doing this work, completely different. Was became a completely different person, started to think the opposite of what I used to think. So with a lot these, it's tough to have these conversations a lot of times because I remember thinking a certain way and I nothing no one could have said anything to me, nothing changed my mind until I was in that position and I, like, really understood.
Speaker 2:Are we stubborn? Are we stubborn, Dex? Is that what's that?
Speaker 1:I'm definitely a stubborn person, for sure. I'm definitely a stubborn person. It's very hard to get through to me, but, I think, on some level, it's true for for everyone. You don't really understand till you're in the in the seats.
Speaker 2:You know, one of my favorite movies is The Matrix. The original one, of course, like not the let's not even talk about the last one. There's a scene that that that stuff I mean, I actually think they did it on purpose because there's a bunch of jokes in the movie about, like, a crappy sequel or sort of who knows? But I there's this scene that I love in which a guy is Neo. He's like the chosen one, like, essentially, right, this Jesus Christ figure who's gonna come and save us all in the movie.
Speaker 2:And then has to take this jump from the building. And everybody's looking like expecting, fails, right? Oh yeah, sure, but he's the one. So there's this expectation that he's going to succeed, but he fails nevertheless. Yeah.
Speaker 2:So I think there are some things that you only learn when you do it, because you don't, you think you know before you actually do it, but then it doesn't match reality exactly as you thought. So you may have a good you know, foundation, but it's not a perfect fit. It's only a perfect fit after you go
Speaker 1:through it. Yeah. Yeah. There's so many times where I'm like, this is a principle. I know it's bad to do it.
Speaker 1:Company should not do this. Six months later, somehow I find myself, oops, I did it. Like, I just you you could think you know.
Speaker 2:I did it again.
Speaker 1:Yeah. And then you just don't. So it takes a couple of times. That's why
Speaker 2:Britney Spears Britney Spears will be a better startup adviser than a lot of people. I just don't know. I did it again.
Speaker 1:Yeah. Just, I just it's why all these things is all about being able to stick around for the long term, you know, kind of been doing this for in the startup space for a very long time. I think, in the past maybe year or two, I think I finally feel like, okay, I think I kind of starting to get what this is about, but I've made the same mistake, like, a bunch of times for me to to really get there.
Speaker 2:By the way, the thing the the the thing that we've done, that I one of the things that we've
Speaker 1:done Yeah.
Speaker 2:We had this we had this thing in the beginning. Like, we we were we we knew we wanna charge people per usage, not VMs and CPU and etcetera. PlanetScale is kind of backtracking on that. They're giving VMs, but we were hearing from the community. Mean, we may in the future, who knows?
Speaker 2:But we were hearing from a lot of people that they prefer just requests. Okay, so we're going to charge per requests. And we didn't have the time to build infrastructure to track those requests.
Speaker 1:Right.
Speaker 2:Right? Yeah. And we're like, Oh, but I want to put this out on a specific date. And how long does it take to build this? I just said, this is again such a life lesson, man, because we hear about MVP, do the least amount possible, but until you're there, you always say, but we need this, this is super important, this is super important.
Speaker 2:It's only when you have the deadline and the commitment, that said, they start seeing that, yeah, you know what? This thing that I thought was super important turns out is not. And the request tracking was the first to go. We essentially didn't build any We said you have a billion reads per month for free, and we never measure it.
Speaker 1:Yeah. We are doing the exact same thing with our current product. Yeah. Like, we we have a free
Speaker 2:tier never measured.
Speaker 1:But if you go out of the free tier, we're not stopping you from accessing it. So Exactly.
Speaker 2:Because you start thinking, why the hell would anybody care? What I need now is just to validate that this thing is going to work and people are going to like it. If they use a billion and chew, are they going to complain? No, nobody's going to complain. They would complain if it was the other way around.
Speaker 2:If I promised a billion and I gave you a billion, right? I'm giving you more, whatever, just do it. And number of people who complain. Number of people who noticed,
Speaker 1:zero. Nobody noticed. Yeah, the usage based thing is big for me. I mean, for us, we model our entire business on the idea of our costs being usage based and it simplifies so many, so many, so many things.
Speaker 2:Yeah, but our cost is not usage based.
Speaker 1:Oh yeah, of course, because you're an infrastructure provider, yeah. So you have the challenge of translating from one to the other.
Speaker 2:But that's a challenge I'm having now because now I projected the growth that we have because we're seeing 30 to 40% growth every month in the platform. So from zero users to zero We're seeing good growth. In the first three months, we were like, just do it, just do it, just do it. We promised you up to nine gigabytes, which people misunderstand because it's really three gigabytes replicated in two So your database is three gigabytes, but gets replicated. So it promised you that, but we didn't have any code to auto scale you to that level.
Speaker 2:So we provisioned everybody with nine gigabytes. People use like 100 ks. So our costs started to get They are getting completely out of control. We provision UVMs, but we're charging you per user. So there is a mismatch there.
Speaker 2:Now, again, now that I have a product, now that I know that people like it, now that I have my first couple of paying users, we have around 15 to 20 users on the Scalar plan and a bunch of other free users in the thousands. Now is the time to go and let's rein in the costs and figure out the different architecture and start optimizing. Before, it wasn't the time to. Even the multi tenancy, we wanted to build the server multi tenant from the start. We knew it was a good use case.
Speaker 2:It takes a lot longer. And the VM stuff, you put a database there, provision, boom, boom, you're done. And now people are asking me. Now I know it's real.
Speaker 1:What I I would love for people to understand is you guys are paying that price, that cost, that effort of translating a VM to user based. That is, a fantastic service that you are providing for other people because now anyone building on top, they're not being charged by you guys unless they are making money or like they're like doing some kind of operation that that's useful. And I think people do not understand how magical and incredible that is. It's one of the big reasons why, like, we we build everything on AWS. We have all usage based costs there.
Speaker 1:It's it's amazing. Like AWS, company does the crazy difficult accounting work of across all their customers, what do they need to provision so that they can turn their usage base. It's like, it simplifies your business so so so so much. And whenever you see a provider offering usage based, you take advantage of it because that's like, otherwise that leaks into your it becomes your problem, right? If I'm running if you guys aren't doing that, if I'm paying for like database VMs, I now need to do that translation, which is a lot harder because I only have myself as a user.
Speaker 1:You guys have, you know, a bunch of users that you can distribute the cost of that between. So, yeah, I love user based pricing. Whenever I see that, I'm like, okay, that's the option we got to go with.
Speaker 2:And that's our Wednesday announcement, which will lots of people have been asking us that. What we have now, we had until last week, was a free tier, which costs, you know, I think it gives you certain allowances. And then a $29 a month tier, which gives you a lot more grant. So it's a 100 times, in terms of reads, it's a 100 times more for $29 But what a lot of people have been asking us is like, what if I'm in the middle? We have reasons, I think, not to go full usage based, also because some people don't like it, because of the predictability.
Speaker 2:So what we're doing is essentially allowing you to go over. And I'm going give you a discount if commit to the $29 a month. So I would charge you, for example, you have your allowances, then I'm going to charge you a dollar per an extra billion dollar queries. Now our free tier offers 1,000,000,000. Our scaler plan offers you 100,000,000,000.
Speaker 2:So if you are purely usage based until the twenty ninth, you're to be paying you $100 a month. But what I'm doing is that I'm giving you the opportunity to spend one, to spend 2,
Speaker 1:to
Speaker 2:spend And then we just say, now I'm crossing the chasm, let me just commit for $29 And on the $29 instead of this extra billion, instead of costing you $1 it costs you 75ยข. So again, I want people to upgrade, I want people to become paying customers, but we're giving you this initial ramp as well.
Speaker 1:Yeah. The ramp is what's key because otherwise you have these jumps, like, with other providers, like, it'll be whatever they're charging you, maybe supports a thousand users. The moment you have a thousand and one, your your costs have now, like, tripled. You might go from making money to losing money. Yeah.
Speaker 1:So the the ramp of it like, the act the absolute price is fine. Whatever they're charging me for that tier is fine. But I wanna ramp up there. I don't wanna just go there because I have one extra user, right? Mhmm.
Speaker 1:So yeah, those little things like that, I think again, I think until you're in the position of it's your money that you're spending, you maybe don't pay attention to that stuff as much. But it's it's it just lowers so much complexity. It's not about the cost, it's about the things you have to think about and things that you can avoid thinking about, which is what I really appreciate. Thank you for joining me. This is great.
Speaker 1:Yeah. Appreciate it. Glad I finally got to got to chat.
Speaker 2:Thanks. Thank you so much, man.
