PlanetScale CEO Sam Lambert on Web Dev Wednesday w/ Theo

Howdy, howdy, y'all. Super excited for today's show. For those that don't know, I have with me Sam here from PlanetScale. Want to quickly introduce yourself, Sam?

Hi everyone. I'm Sam. Like Theo said, I'm from PlanetScale. I'm lucky enough to be here as the CEO. I live in San Francisco and I'm super excited to meet you all and be here.

Super awesome to have you here, man. Yeah, as you know, and as many of the people who are here know, I've been a loyal PlanetScale user for, wanna say 4, maybe 5 months now?

5 months.

Yeah. When I was early at Ping Labs previously as the product round, we were running into issues with connection limits on Heroku. I moved us over to RDS, which was annoying, but totally doable because SQL is SQL. And it was like a Heroku Postgres over to, Postgres on RDS, and not quickly, but slowly started reaching connection limits over there. I sat down and thought, okay, I could learn how all this stuff works and build my own solution to this problem, but that can't be the best answer. I'm gonna do a little bit of searching. And luckily enough, stumbled into PlanetScale. Was a little scared moving over to MySQL, but I took the bite. And here we are 5 months later, talking with the CEO, shilling it immensely, and— happier than ever to be paying $0.17 a month for the best database team I can imagine. So yeah, it's awesome to have you here.

You're very kind. Thank you. And you've been— yeah, like, we love seeing your tweets in chat. Like, so we get these Twitter— these tweets come through and it gives everyone kind of a buzz. So we're very grateful. And thank you for that $0.17. We really appreciate that. By the way, this is the first stream I've ever been on. So I'm a little nervous, but I'm very excited. I'm nervous because we have James and Taylor and Cammie who do streaming and various different stuff for us here at PlanetScale, and they are phenomenal at it. So I feel like I've got some pretty big shoes to fill, but I'm really happy to be here.

They're fantastic content creators. It's one of my favorite things about PlanetScale was the focus on hiring content people early. I will say though, You're doing the fun part right now. All the behind-the-scenes work to stitch a stream together is painful, but it's also what we specialize in. So it's awesome to be able to give you like the formal intro on the platform that we're so proud that we've built.

That's awesome. Actually, speaking of content, it's pretty amazing actually how much content does now. I love seeing it. I think it's— when I was a software engineer, well, developer engineer, whatever, a long time ago, You know, you would never go to YouTube to like learn about software engineering. And the fact that there's now such rich medium and media and TikTok and all of these various places to kind of learn in these new communities, it's really awesome to see. Like it's such a fascinating world to be shipping software and then marketing it this way. And I love it. I enjoy every second of consuming the content and learning about other products. what people do and shows like these make it so cool.

Couldn't agree more. It's one of the reasons that I got in as early as I did. Like, I was into content before I was ever into engineering personally. I've always been like deep in the gaming side. I got into code to host Minecraft servers, honestly. And it's been so surreal seeing the developer world kind of meet me where I was, if that makes sense. Like, even earlier today, I was talking to some people at Netlify and having people who work for Netlify come to us excited as soon as they see the product and its core features, just like getting it is surreal to me still. Because like these are the people I looked up to even like 2 years ago as I was trying to make like our success in the developer space and like really prove myself there. And now the same people who I looked up to are coming to me for help on the stream side of things. And it's really crazy to see.

Yeah. And I, yeah, I know that feeling. It's a really funny feeling when you build something, you put it out there and people start using it and you're like, It's kind of wild. So, you know, even like, you know, we're getting to the stage now where kind of you'll see someone sign up and they're using it, or you'll look at the kind of the market, the end of month billing going out, and you'll look at all the different names of companies that like upgrade and ran up a bill. And you see like real brands there, like name, like companies you've bought from, like e-commerce websites that you've been on or or whatever, and you're going to get— it's a really surreal feeling knowing that there's this— you're going— and we obviously got that. I got that from being at GitHub. That was another kind of a different level of it. But it's different, right? You know the brand is using the software, but then actually knowing their products are completely powered under the hood by the database product that you and your team have built is a really great feeling. So I know exactly how you feel.

Yeah, we just had a few of those moments with some of my favorite kind content creators, be it like the VTuber world, the political world, gaming, having them all come and start using our product. And like, I think my favorite moment was one of, one of my friends reached out because they were watching a live show for like a political person that they were really into. It's like, wow, the quality got a lot better. Any idea what happened? It's like, yeah, they hit us up and they started using our product. And it's just such a cool like aha moment to have that, like even with my personal friends as they notice the difference.

I completely agree. By the way, the team turned the image you made to sort of advertise this into a Slack reaction immediately. So now I see my head with laser eyes coming out on a lot of messages today. So thank you for that as well.

I love that. No credit to me, though. My editor was all over that. He's on top of everything that isn't me being in front of my camera, effectively. Credit to Adam. He's been killing it. And also is available for hire if anybody needs content editing, graphics, video, etc. Give him a shout out. I can link you up to him later on Twitter or wherever else.

Yeah, yeah, he has a very bold design style. I like it.

Yeah, I quickly want to do a check since, uh, people are starting to roll in. If there are any audio or video issues, please let me know ASAP so I can get those addressed at all. Seems good on my end, like surprisingly so. So yeah, I just had yet another Windows update and series of driver issues and crashes, so fingers crossed things are stable for this show. Well, yeah. To kick things off a bit more, you hinted at the GitHub stuff. From my knowledge, you made quite the set of career moves starting at YouTube, going to GitHub, and then finding your way as the CEO at PlanetScale. I'd love to hear a bit more about your history and how you ended up where you're at.

So I wasn't actually at YouTube. The founders of PlanetScale were at YouTube and the technology that came, but before that, yeah, I was at GitHub. So I'll tell you, very quick, I'm the boring part, so I'll just Yes, I was at GitHub for 8 years, I think, by the time I left. Very fortunate to have joined them in the fairly early days and watched the kind of the journey and the growth of a very, very unique and special product. And then, yeah, I was at Facebook for a little while and then I really wanted to be back in a startup again. Like, I really wanted to be back in the early days. And when we were at GitHub, we'd used PlanetScale's core technology the tests. And, you know, it was incredible. And, you know, it was— so we have our head of infrastructure, Sam. He, you know, I was talking to him about it and he was like, yeah, I mean, it's a bit of software that pretty much does exactly what it promises to do and does it very well. And it's kind of a, you know, that was our experience. And it was very great for us because we were trying to scale, you know, GitHub was, I think, the 40th most visited site on the internet at the time. And so there's a lot of traffic, right? And trying to scale the database for that is— It's really tough. And Vitesse was amazing for us. And I was advising the company anyway. And I thought, you know, I'd love to— I think there's an opportunity here to build a product that takes this technology and puts it in the hand of everyone. Because right now, so like Vitesse is the backing for a lot of very like large websites. And if you go to our, like our planscale.com, you'll see like this incredible list of logos. For example, like Slack is that, you know, whenever you send a Slack message, it's Vitesse on the other end that listens and acknowledges it. And then it's sent out to the clients, right? Vitesse is this core piece of infrastructure. And I thought, thought, you know, it can stay as this piece of tech for the really large hyperscalers of the world, or we can go on a mission to put it in the hands of every single developer from the beginning, from the moment they start their company. And that's been the journey of the company for the last kind of year and a half now. And it's going— it's really exciting. And you were talking just about like limits on Postgres, hop to AWS, like companies go through 2, 3, 4, maybe 5 different changes in the database stack until they get to scale and they settle on something. And when they get to real scale, they have 5 or 6 engineers that are babysitting it. They build their own sharding scheme. They go through these like hellish things. And the thing about— the thing that's most egregious about that problem is that it's undifferentiated. Like no matter what your product does, you need a database and you need to solve database problems. And it takes away— from what you should be doing for your users. And the thing I love and I think is truly magical about PlanetScale is that folks like yourself choose to use it because it's the most easy-to-use, simple, sort of joyful database experience that's out there. But under the hood, we've provisioned you technology that runs some of the largest sites in the world. And so The thing I can't wait to track over the years is company founding all the way up to IPO without ever having to go through that hell of database scaling and they just use PlanetScale. And we haven't seen tech like that, especially in the backend before. And that makes me super excited.

That's a really awesome way of framing it. I will say, like, I hope to be one of those big companies someday. I know that Ping isn't on your homepage yet, but eventually we'll get there. I definitely feel the thrash of the database changes in particular, even early for us. Like, I personally changed our data infra 1 to 3 times a month for our first 3 months existing, trying to keep up with our needs as developers and our, like, infrastructure needs for our users. Like, we started on WorkerKV, and that was a mistake, I'll admit it. We moved over to the— As I mentioned before, we did Postgres on Heroku. outright mistake, even more so, moved over to RDS and then eventually here. What was really surprising for me though was that the PlanetScale move felt the smoothest, even though it was from Postgres to MySQL. It felt like the least ask on me as a developer in the sense that I dumped my data, I ran it through some script that converted a pg_dump to a MySQL dump, removed the parts that were table definitions, matched my schema using Prisma and then ran the script and it worked. And that was still baffling to me. I even switched in production. I had a Next.js push that switched the DB environment variable name over to the PlanetScale environment variable, not realizing I had 2 of my biggest clients in calls when I made the switch and it was seamless. Nobody noticed the transition.

That is fantastic to hear. It's funny actually, some of the bigger customers that are migrating over right now are coming from Postgres. And well, like there's definite work, like when you have very complicated applications, um, to work around, but it's kind of like if you're having serious scaling problems, it doesn't matter, right? You have to get through. It's better than kind of trying to do like, I don't know, sharding on Postgres or something like that. Like trying to like going with like an established tech that, you know, can at least scale through. It gives people the motivation to do it. But I was really surprised to actually see We did one recently, this proof of concept with a Postgres customer and they wanted to get to a large scale. Hundreds and hundreds of thousands of queries per second is what they're looking for. They're growing immensely and they wanted to know that we would scale to crazy limits. It was a great proof of concept to watch. They were coming from Postgres and I was really surprised how quickly they were able to adapt the application to run on PlanetScale and then push those kind of numbers. It was great. And so I don't think you're right. I think it's not as scary as one would seem. I think if you're using some of the really deep Postgres features, it would be tough, but I think it's, I think it's well worth the switch, but I'm obviously heavily biased as well.

The only thing that I had to like re-architect was we were using string arrays in Postgres for like one or two stupid things. And yeah. That was a bad decision that we probably shouldn't have been using anyways. But since I replaced them with JSON blobs, I don't know if it's much better.

Well, I think you'll be fine. You're with us. We've got you. We'll sort you out.

Yeah. I am not too excited. It's for a very small feature and for tracking a little bit of data. It's not a big deal. Overall, the move was very smooth for us. I am curious though. I feel like a lot of that smoothness came from Prisma as not just an ORM, but as a middleware API almost between my database and my application. that also serves as a really strong source of truth for the type safety on the client, but also the consistency of my data model on the backend. And I'm curious, I've definitely seen the investment and focus on Prisma at PlanetScale, especially with projects like Beam taking advantage of it. I'm really curious where you think the relationship between Prisma and PlanetScale is and how you view that as the CEO in terms of investment and time and focus.

So if anyone, any company out there that wants to make the lives of developers better, we're aligned, right? Like we want that too. And especially when it's around databases. We love the Prisma team. We have a shared Slack channel with the Prisma team and it often feels like the same company are talking back and forth, which is really great. And I think their goals and their values for what they produce for the world is very, very similar. And, you know, Saurabh, the CEO of Prisma, whenever he comes into town, we always grab lunch or go for a walk or something. So there's definitely a bond.

Yeah.

between our companies. And I think it's really nice to see a piece of technology that's kind of getting a lot of traction and is unified and bringing the kind of ORM magic expressly to the JavaScript community. I think Rails provides similar kind of magic with ActiveRecord. And ORMs certainly kind of— we get that. You see this a lot in comments when people are like, well, if you're using an ORM, it's very simple to move to PlanetScale, right? You just change the adapter and that makes it really interesting. But Prisma has grown and built a phenomenal community, very large community very quickly by being very good at developer experience. Their taste is unrivaled. And so yeah, really awesome company to work with. And there's definitely a lot of kind of shared goals and alignment between the 2 companies.

I couldn't agree more. They feel like such a good match. I could go on a rant about referential integrity stuff, but I'll save that for the second half of this. I am more interested in the— I'm trying to remember how we put this one. This is the supabase question. I am very interested in how focused PlanetScale is on solving specific problems really well and then integrating with solutions for the problems that you don't solve versus a supabase where Like, they are solving databases and all the problems around them as a single player, whereas you solve databases and partner with the solutions around to make sure you're compatible with the best players in the space. It almost reminds us of— me of what we're doing with Ping, where we're not trying to solve the entire ecosystem problem of video production. We want to make having guests on your show as easy as possible. And I'm curious how you feel about that difference and how it positions you against other companies in the Yeah.

So I also— Supabase is another company that I feel we're aligned with, right? That, you know, they are delighting users. When I see people, like very often it's people kind of tweeting, it's like PlanetScale or Supabase. And, you know, I'm happy with some people to enjoy whatever tools speak to them. And I know people want more of a kind of an all-in-one solution. We have very deep database expertise. PlanetScale is made up of people that have taken databases to the absolute largest scale. Like, we, we have, you know, um, a number— like, a lot— quite a decent chunk of our employees have worked at not tens of millions user scale, but billions of user scale, right? And that, that takes things to a complete other level. Um, and so our expertise is very deep. So rather than kind of going, uh, you know, a mile an inch deep in a mile wide. We like to focus really deeply on what we're doing in terms of databases because it's a hard enough problem. And I think you could spend— well, so winding back, we go a lot further than database— most database vendors when it comes to how simple we want to make the product. Like we make it ridiculous. You didn't have to specify how much RAM for a cluster or You don't see the word— you won't find the word cluster in our UI or RAM or vCPUs or like nodes or whatever.

You only started showing connections recently.

Yeah, right, exactly. And so we keep it behind an interface, an interface that we talk about and that we work on very deliberately and it's beautifully designed. Shout out to our product design team, Jason and Derek. We agonize over how simple it is to present this database. And when the product is extremely deep and powerful, that gets harder. But we want to not just spend our time building something amazing, but something that's refined to be usable and simple. And other database vendors, I think they think, okay, we've solved like a very hard problem. Databases are very hard. Here's a load of pain in return. Like we're not going to go all the way. Like, you know, you have to do stuff yourself. We don't agree. We want to take it all the way. We want to take it so that single person companies or teams or, you know, small groups of people are leveraging immense power. And that takes a lot of work. And we have got years ahead of us to get it right. We— what we've produced so far is just the very, very beginning. We are very unsatisfied with the state of the world in the right way. We want to see a much better world when it comes to databases. And so we've got years of work ahead of us. And I don't want to distract us. We're shipping, you know, towards the end of the month. And people, you know, will start tweeting around the— we're launching a new feature. No one has ever done it. It literally hasn't been done. It's just like branching, which was again another feature. Like, we brought branching to the database world last year. This one has never been shipped by any database vendor. It's a completely brand new piece of functionality. I'd rather focus on those things. There's things that, you know, there's really incredible experiences and pieces of technology we can deliver, and it's going to be like deep, deep refinement and thinking over the same problems year and year and Is that the stuff that I'll be playtesting on Monday? Yes, it is actually. You're getting a— you're getting an early look of it. And, um, yeah, that is decades of experience from a number of database engineers working very hard to produce technologies like that that come out safe and robust and usable at scale.

Yeah, I couldn't be more excited for that. I have a history of playtesting the things I use and love the most early, and it's cool to get to jump in on that here and for you to be bringing up the same thing that I'm getting to play with soon is super exciting.

That's great.

You touched on a lot of like ideas that I'm really interested in. I'm gonna dig in on one. It's, it's, it's a contradiction. I don't think it has to be. I'm really curious what your thoughts are on it. The idea of like people reaching for a Supabase or something like it for the all-in-one nature it provides of how much easier it is to go from 0 to 10, if that makes sense, like out of 100. Like you can get something working that has all the parts you want. I know a handful of developers, especially some like early developers that are learning software for other— or for reasons outside of wanting a career in it. Like, I have a good friend who is the CEO of a charity for mental health in gaming and like online spaces.

Oh, wow.

He taught himself how to code because Squarespace wasn't working as a platform for them. He's one of my favorite developers ever. Huge shout out, Jason Docton. Love you, man. He is the one who convinced me that Supabase had a lot of value. not because I personally would use it, but because of how much it let him not worry about the problem of getting started. And on top of that, as I described earlier, I feel like Prism— or PlanetScale is a uniquely strong experience in moving my infra over to it. Like, I was able to move to PlanetScale faster than anything else.

Yep.

With all that said, I know that you're pushing the idea of PlanetScale being the the thing you init with and the thing you IPO with. I'm curious when, for people who start somewhere else, the transition makes sense. And if your goal is to, while obviously complementing Supabase and things like it, how do you see this relationship between starting with the simplest thing and moving to the simple enough but scalable thing when it makes the most sense?

Yeah, that's a great question. And so whatever gets you moving and closer to your idea is the important thing. Internally, we talk about that people don't come to us for a database, they come for a backing for their ideas. And the reason— so Lee Robb, he did a fantastic YouTube video that timed sign up to getting a database. of like 20 different database vendors. Do you know the video?

I have not seen that one. I need to go watch that, though.

So Lee Robb on YouTube, he basically does this bake-off of all of the different database products that you can care to name. He signs up and sees how quickly it takes to get a database. We came first. And we came first because we obsess over things like speed. and productivity of our users. And the reason we wanted the database creation to be like— so when I was joining, when I was thinking about joining PlanetScale, I was looking at the competitors. I wanted to, you know, how crowded is this market? How tough is this going to be? And I signed into like one of the hottest ones and they made me wait 24 minutes for a database. And I was like, okay, well, we can beat that. And so we decided we would get as close to instant. And I think it takes about 11 seconds in that video to create a database because we want people to get past the database creation and get back to creating their idea. The more time they spend looking at npm errors, database problems, messing around with deciding CPU and cluster sizes and all of that crap, they're not working on their idea, right? Then they're not— we're not getting out the way and enabling them. And so we've been very obsessive about productivity and building things. And this is where branching comes in, right? Like we believe data branching and branching your schema is the—

Mm-hmm.

The absolute, like, best way to get into a flow of developing quickly. Schema changes are tough, right, and annoying, um, and you want to get past them. So we don't just, like, sell on scalability, right? Like, coming to PlanetScale for scalability alone, you're going to be coming a lot later, right? Unless you're a big company. There's so much we do, and, and especially this year's roadmap, that's not just about scale. Like, in fact, the product scales, right? We don't have a lot of scalability work to do, or as much as the others, because This ran at YouTube across 20 data centers on tens of thousands of servers, right? We're actually scaling down. Like we've got, we've had the biggest use case, right? Like it'd be nice to host YouTube on PlanetScale Cloud. I don't know if we're gonna get there. Every one of our competitors is scaling up. They get the next biggest customer. They're gonna go through all the backend problems and all of that, those issues. We're scaling down from the largest, like second, third largest website on earth. We're now, now it's about human experiences. on top of that scalable platform. And so I would say the right time is now to come and get all the goodness of what's coming for that platform. However, if Supabase gets you most excited and gets you past the setup problem and building quickly, you should do it. And all-in-one solutions are great. I mean, truthfully great for getting moving, but like, you know, like happened with you and Heroku, the database fails first. And there is so many people that are deployed on Heroku and the first service they go to outside of Heroku is Amazon RDS because the database breaks first time. And that's going to happen sooner and sooner in companies' journeys as they get more complex and just the scale of the tech industry grows. And we believe that we're going with the best-in-class solutions, always going to be better.

Obviously compounded by Amazon not updating their free tier for like a decade, but totally agree.

Yeah, it's shockingly low actually, isn't it?

Yeah. Uh, somebody in chat, Adit, actually mentioned that, uh, this particular thought and like the way things are breaking down is, uh, very much a problem that they're dealing with right now, and it is hitting the nail on the head for the complexity that he's dealing with on his team. So it's really cool that like just people who are like idle watching this are immediately resonating with what you're saying. That's how you know you're on to something, when, yeah, when people in chat Like can bring that into the lived experience they're having right now.

So— Absolutely. I mean, we're all having database problems. And like, you may just not know it. Like, that's the other fun thing about when you talk to people is you don't say, do you have database problems? You say, tell me your database problems. Because of course you want to have a database. Your business really isn't up to much unless you have it. Like, you know, if you're building on a tech platform and you don't have a database, I mean, you're not really up to much. So one, that's an amazing opportunity for us because databases are everywhere. And 2, we know that they're a problem. And so we always get asked, what are your database problems? And they're always very similar. And we obsess over those problems to solve them for people.

Yeah, it absolutely shows. One of the interesting ideas you touched on there that was kind of one of my questions, I want to push a bit harder. The idea of moving down the scale in a way where PlanetScale scales. I've referred to PlanetScale as close to infinite scale as you're going to get and gotten pushback from random people. thankful I've been proven right consistently with that. Thank you for making my bold statements look good.

Yeah.

But the interesting idea you touched on is pushing down from the biggest scale to the lack of it and that initial commit. And something I've definitely noticed is it didn't feel so much like moving down so much as switching to the bottom, where PlanetScale's focus used to be the scale part. And it almost feels like there was a conscious decision to switch from that to the experience part. I'd love to hear a bit more about that and how PlanetScale's focus has shifted from scale to experience.

Yeah. And I would say when the— we're obviously super— scale is very important to us. It's more about that experience scaling is I think the way we think about it, right? Is like, what is the best developer experience around a database? And how do we continue? Because if you you know, and I will, I promise I'll get to your question, but the market's fragmented. And we had a slide originally when we were pitching the original idea, which was you have companies down at the, like, the best to use on day one, really cool, like, dev experience, fanciful features that don't work at scale, whatever. And then you have the, like, the databases that do scale that are just ugly and incredibly bad to use and whatever. And we wanted to just cover all spectrums and deliver that experience all the way to the scale of the others. So we do, we think about it as the experience scaling. I think it was, I don't know, it was, you know, we, we were kind of selling to the, you know, I had a customer base of these massively large installations and, and, and we thought that it's about, you know, more people can leverage this technology. Why do folks have to go through loops of pain to get to scale problems before they realize they need to use Vitesse? And also Vitesse is really hard to use. I mean, That's, that's, that's kind of the point of the way Vitesse is architected, is it's extremely powerful, but you're not going to download it and immediately get up and running in 10 minutes if you don't know how databases work, right? They've optimized— and by the way, it is an outstanding piece of technology, and the team behind it are incredible engineers, absolutely incredible in terms of what it does. It's such a well-maintained open source project. It's also People may not realize it's one of the absolute oldest Go projects in existence. It was built— it's the— the test started on Go 0.1. Um, the, the, the— actually, the founders of the project are credited in the, in the Go documentation, uh, because they gave the earliest language feedback. So it's one of the oldest applications built in Go. It was built in— on Borg, which is the predecessor to Kubernetes, and we kind of joke that That means we were ready for Kubernetes before Kubernetes was. So it was built in this very, very unique environment and it's a huge codebase. It's very complicated and the team do an amazing job with it. And we knew to get it into people's hands, we had to kind of hide that, right? We had to give them all of the best parts with none of the harder to use pieces. And, and that's why we went on the mission we're on and we took it all away with a serverless platform, which adds a whole other level of complexity. And, um, but we really wanted to take that challenge.

A framing I used once before was Vitess is Kubernetes for SQL and PlanetScale is Lambda.

Yeah, that is absolutely a way of thinking about it. It does make things significantly simpler, but it's very, very hard. Well, not hard, it's solving hard problems and it takes a lot to get it up and running.

Yeah, couldn't agree more. One more point on where PlanetScale is positioned. Like, we touched on it here with Vitesse and how good of a technology it is, but I, I've seen, uh, I don't want to say a trend, but a definite interest in SQL alternatives, if that makes sense. Like, Supabase isn't one, but they provide their own SDK that you can like install and then never have to think about SQL again. There are platforms like Fauna, DGraph. I just saw another one that's like PseudoSQL. It was like an edge database or something that isn't— it was GraphDB. There was something that had like a new graph SQL syntax that was still SQL-based under the hood. But it feels like there's a lot of focus on providing alternatives to SQL both on top and below. And I'm curious what your thoughts are on that trend and how confident you are in PlanetScale's decision to kind of ignore it. That makes sense.

Without revealing how old I am, I've been in databases for a very long time. And every single year, I see someone pop their head up and claim they're going to build a proper alternative to SQL. And there is a graveyard full of companies that have tried to do this. They pop up constantly. SQL's been around, what, 50 years, 60 years, something like a long time. It provides great developer experiences. It has downsides. Um, uh, but it's the interface that we've kind of chosen, um, and has worked. And you look at the success of Postgres and MySQL, I mean, it just, it works, right? I think SQL is actually in the middle of a reinvigoration and a revolution. I mean, I see more and more tools continually using SQL. People are putting SQL in their projects to sift through audit logs or, um, just other types of interface. And, you know, BI tools, whatever, right? I think you have to be long on SQL. And I think there's certain things in tech and that come down to elegance and it's a very elegant, um, language. And yeah, I just, I'm, I, I question why, if you're taking on building a database from scratch, something incredibly difficult to do, takes a decade at least to get a database to any level of maturity where it can be run at any like major scale. MySQL's 25 years old, and that's not a bad thing, right? When it's a data store, you're building on layers and layers of generational knowledge and running at scale, right? Like you use MySQL, yeah, you'll use patches from Oracle, Google, Facebook, the thing like fixes for things they experience running at large scale. If you're building a database from scratch, you've got a 10-year journey ahead before you can even like, before you can even claim any level of sophistication. And then to actually add the complexity of building your own query language and trying to explain to the world, you're just fighting on too many fronts. I wouldn't bother, would be my advice there. I just don't see it. I just like, maybe something will come up. I'll be very excited if someone builds a much, much better alternative that gets mass adoption. But I mean, there's been a long line of people trying to do it.

Yeah, I, I will admit my bias. I couldn't agree more. I had a funny instance, I think it was a couple months ago now, where somebody was really pushing one of these new, like, innovative databases as this seems really cool. Like, you're— you use a lot of bleeding-edge technology, Theo, why don't you use this? And my response was, because SQL's existed for 50 years and this has existed for 15 months at most.

Yeah.

And yeah, it's just that's— I, I will take crazy bets on things that I can change But my database is the source of truth for my business. That's the one thing we can't screw around with. Like, that has to be stable. And then the week after he made that recommendation, the entire core team for that database team left.

Oh, that's really unfortunate. Yeah, I mean, you don't— why screw around with the data stack, right? Like, if you mess this up, you are in like business— sometimes business-ending pain, right? Like, it can be terrible. to get into that situation where you're stuck on a database that doesn't work. You've got a great story. You move from Postgres, a very established, fantastic data store that uses SQL, to PlanetScale, a MySQL-backed data store that uses SQL. The interoperability is incredible. Absolutely incredible. I mean, why would you throw that away? It'd be like, I don't know, showing up and claiming you're going to just completely overturn Linux. You've got a much better solution. You're going to just dominate. Like, you just look silly. I mean, it's just the standards. There's, there's elegance, as things that we're— the great thing about tech is we can build upon sedimentary layers of progress, right? People, to get their business started, had to buy a server and rack it. Now they just have to go to a service platform. They don't even see the word server in the interface. That's progress. Let's keep going. Let's keep layering this progress, because we move forward. Humanity gets going when we do more and technology comes to more people. I just don't have much tolerance for let's throw things away constantly. And it's not what I believe in.

Really interesting. And I can definitely say from my experience, the move off of Worker KV was much harder than the move onto PlanetScale because there was a standard on both sides that I could make small changes around and have a working experience. Hell, moving off of Vite and onto Next.js and rebuilding our entire style system was less painful than moving from Worker KV to a standard. And that's—

Beautiful.

Yeah, like changing your data stack should not be scary. And if it is, then you probably bet on something very scary. And yeah, the scarier it is to move off your current data, the more important it is that you do.

I agree with you. I agree with you. I wish you were coming from MySQL on RDS though. That experience is even better with the proxying we do. It's like 3 clicks. We basically do the connection swap and everything. That is the— if you are using RDS MySQL and you want to try PlanetScale, you can be— we had a customer, they bought the product, they went through the flow and they were up and running in like 2 days. And the flow part, our part of that was hours, just while the data copied. There's some great videos of that, like kind of connect, we connect to your RDS, we move the data over online, you then switch your connections to PlanetScale, we proxy it back to RDS, and then when you tell us to cut, we actually reverse the roles and it's awesome. And so I'd recommend everyone giving that a go 'cause I think the team that put that together, the developer experience, I've never seen developer experience like that for migrating database. Usually you have to dump the database, This is a fully online operation. I love it. It's brilliant.

Yeah, that is so cool. I had no idea that the MySQL integration was that good. I want to make sure you don't out or undersell the smoothness I had moving off with Postgres though, because again, I wasn't confident in MySQL. To be honest, like the scarier bet for us wasn't PlanetScale. It was moving to MySQL due to the lack of experience we had. We're a Postgres house. I come from Twitch, which is a Postgres house. Like every experience I've had has been PSQL and moving to the scary Oracle thing was definitely a hurdle we had to jump.

How do you think people feel about— question for you, how do you think people feel about MySQL and maybe Oracle's ownership of MySQL?

Very bearish. I would say the biggest pushback I get when shilling MySQL or shilling PlanetScale, honestly, people are very scared of that. I've heard a lot of interest in alternatives to PlanetScale specifically because it's like PlanetScale but for Postgres is something I've heard a few times now.

Yeah, so it's interesting. So our goal is to— so we use MySQL because it's very good at what it does, right? It's very proven. Postgres has huge, like, huge user base. Lots of companies are founded on Postgres. And I think I'm gonna— I don't want to upset anyone. I do think Postgres is fantastic. But it is a story as old as time. As we hit scale, we move to MySQL. It happens, right? And I will just say, when you, you know, bit of inside knowledge, when you run or work at some of the largest scale of all deployments on earth, now and then you try other databases in case you can do better on cost, on anything. And the fact MySQL still survives says something, right? Like, and is supporting billions and billions of users. My, you know, if you look at the top 100 sites on the internet, I would imagine that probably 80% of them are using MySQL. It works at scale. It's very robust operationally. And I think where most MySQL falls down though is the developer experience. Postgres ships features for developers that developers love, and they do a fantastic job of that. Operators love MySQL. Uh, it— the, the, the, the technology, like operating MySQL at scale is a lot easier. The tooling is fantastic. Replication is extremely good. Like that, it's, it's very good at that. And considering we're operating it for you and we're providing you a developer experience on top, it's absolutely the best choice. Like my goal, and, and I know this is true because I know that, um, You know, I've spoken to people and they don't even realize PlanetScale is MySQL. It doesn't matter to them. It's— and I think as time goes along and we ship more and more features that no one else has ever shipped in the world of databases, people are just gonna forget it's PlanetScale, right? Like hopefully it just becomes, oh, it's PlanetScale versus MySQL, Postgres. I don't see a Postgres v MySQL world. I think that's a very depressing conversation to have in 2022 because I'm more annoyed about what databases don't do and should be doing And we're working on that instead.

I saw a couple comments in chat about GraphQL. So, I'm gonna go on a quick rant. You don't have to jump in unless you have takes. But I'm a big GraphQL advocate. I love it. I used to be a much bigger GraphQL advocate. And I will admit to have over— to having overprescribed it in a lot of places. If your frontend and your backend have a one-to-one relationship where those things are consuming from each other directly, you don't need a wall in between them to to talk about what that relationship looks like. There are plenty of solutions like tRPC, Swagger, that make it way easier to define that relationship without having to define a giant schema for that consumption. That said, for apps that have a shared backend for different clients like mobile, web, whatever, GraphQL is a phenomenal solution and it's one of the best ways to define a relationship between your frontend and backend teams as the schema is a way to communicate. The GraphQL query language is phenomenal, but it is very important that you respect the intent of the GraphQL creators and the schema and the— like, what GraphQL is. It is not a database. It is Graph Query Language. It is not meant to replace SQL. It's actually the same complaint I have with tRPC, where it sounds enough like gRPC that people think they compete or are in some way related. No, GraphQL is a great way to build an API on top of your SQL database or on top of any other database. But anytime somebody says, what if GraphQL was my database? I get really, really scared of what's going to come next. I think he just—

Yeah. I think people have started— there are people that are working on databases that natively just do GraphQL. I think that's a really bad idea. Abstractions are good. At GitHub, we were a very early adopter of GraphQL. And we had issues. Like, okay, so I'm not an expert here and I don't have a very rich set of stories about the problems with GraphQL. I'm told it didn't go great, but I don't think that's anything to do with the language. I think maybe our implementation or whatever. But if we'd also bundled that like attachment to the database instead of it's just the thing that listened for the request and then sent SQL is different. I mean, swapping out with that layer is much easier than— Oh, now the database doesn't work as well. It's like, what more can we do to ourselves to cause problems? I mean, it's— that's the great thing about abstraction, right? Is that people can talk to the database in SQL. And look, GraphQL came from Facebook. Facebook runs MySQL. You know, you can have these great layers of abstraction and it works fine. And plumbing all this together seems wild to me. Yeah.

Couldn't agree more. Yeah. GraphQL is a big thing to bite on as a full-stack solution because you're now changing how your client queries data and you're changing how your database— how your backend presents that data and models it. But you don't have to also change your database in the process.

Right.

That is very scary to me. And also importantly, is not the intention of the creators, as you said, with Facebook. GraphQL was built to make it easier to work with your backend, not to replace it.

Yeah.

And I think it's important to recognize the difference there. As I've seen more and more people doing GraphQL versus SQL takes, and on top of that, a renewed interest in platforms that generate GraphQL APIs or even Swagger APIs on top of your SQL model, that's a relationship that I want my developers to define. I do not want a computer to generate my database as a service. My database is not a service. My database is a database and my service is my service and I wanna define that relationship.

Yeah.

Even Prisma made the moves themselves where Prisma originally started as a GraphQL, like, platform to generate a GraphQL API against your DB, originally named Graphcool. They transitioned to the Prisma that we now know and love as one of the best ways to interface with your database in TypeScript so that you can define the layer instead because they noticed more than anyone else in the space oh, shit, automatically generating these things is not the best thing for our developers long term.

Correct. Yeah, it's— I believe GraphQL also was there to solve some org problems too. And a lot of tech is done to do that. I mean, you know, architecting properly with your technology to help your organization move faster is also really important. It's not just down to raw kind of technical arguments. And it's very good at doing that. I agree. It's just— and then Prisma gets to work with a bunch of other databases because of that, right? They provide the abstraction, they do the grunt work, and that makes it great for everyone else.

Absolutely. I've even credited GraphQL and how well it helps with the org problem as being a big part of how I— I started as a full stack, in quotes, developer that did backend and would complain about the JavaScript whenever he had to touch it. I did a bunch of video infra and like safety tooling at Twitch with that stack. I moved from Elixir to Golang. And then Twitch started investing heavily in a React TypeScript rewrite off of an old Ember shit show, to be frank. And during that rewrite, we adopted GraphQL really heavily. We actually had Tony Guida, awesome dude, one of like the original contributors for GraphQL Gophers. And I think he was actually the initial commit for it, built like the first big Golang GraphQL client—

Oh, wow.

GraphQL server. for Go, and we shipped that super early. And what was cool for it is the first time I had the experience of sitting down in a meeting with a doc that was, here is the relationship between the frontend and the backend. Once we agree on this schema, we can all fuck off, not talk to each other for 3 months, come back together, plug it in, and if it doesn't work, somebody didn't honor the contract. And I'd never had that experience as a developer. And funny enough, it gave me the confidence to the first time in my life move all the way in on frontend because I didn't feel like I had to be solving the backend problems for it to work. I could trust the schema and if the schema wasn't honored, that was the backend developer's job, not my issue to go solve. And I will always love GraphQL for frankly letting me move to frontend more heavily and turning me into a real full-stack developer as a result.

That's awesome. That's really awesome. Software engineering is so funny, actually. We obsess over how we work as much as what we do. I think most of the working world goes to work and work, right? They know what their job is and they work. We have this additional kind of layer and it's really amazing. We actually really introspect and think about how we work in the process of our own work, and we build our own tools to do the work. I love that about our industry. I think it's fantastic. I think it keeps us on our toes. It keeps us moving forward. And applied correctly with a nice sprinkle of pragmatism, something that's extremely important, yeah, we're building something awesome. I love it. I really, you know, it's such an amazing industry to be a part of. Yeah.

We're engineers. We're builders. It's our job to solve problems with technology and have people deal with them less. To me, it makes a ton of sense that engineers are really on top of that. If anything, I almost think it's too much. Like, a fun realization for me was coming from the creator and like audio, video, like media world, seeing how much innovation goes on in a given week in the software dev world and wishing desperately, what if I could like steal these things and bring them back to creator land where they don't see innovation ever? Like right now, I'm streaming using an open source piece of software called OBS. that has been the gold standard for doing live streams for at least 8 years now. And over 90% of the top 1,000 streamers on Twitch are using OBS or a fork of it because of how essential that is. As like, it is the Creator World sequel.

Yeah.

And we're not seeing any of the— we don't have a PlanetScale for OBS yet. We don't have these innovations on top of the platform because everybody is kind of in Fauna land trying to reinvent it rather than acknowledge that strengths, right, the platform has. And it's cool being— I like to call us the first Unix philosophy company in the creator world, where we're building a really powerful input and output that is standardized enough to work with most of other people's setups.

Yeah, yeah. Uh, that pragmatism and that kind of approach, yeah, I think that's the thing I used to rail— I've railed about this for years. I did talks about pragmatism. Throwing things away, not being pragmatic, using the newest crazy fancy tool or whatever. I mean, you then get, you get too far in the weeds and now you're, all you're doing is working on what you build and like, um, what you're building, uh, instead of the product and, and all of these pro— and it just doesn't help. I think, you know, we're so, okay, you've just created a company and created a product. And I was surprised by this, but How, you know, how easy do you feel it was to just get going as a company? Like, like, do you feel there's big missing things that you can't get from a SaaS provider now? They're—

the things that were frustrating were frustrating for stupid reasons. Like, here's a fun one. We couldn't sign up for Rippling when I first set up like HR and payroll, because I was the only American employee at the time. And you have to have a minimum of 2 American employees for for Rippling to take you in. So we had to use a different HR and payroll provider that's been less consistent for us. And the move off of it to Rippling now that we have more employees is more painful than like—

Right.

Not. But that's the weird thing is I feel like a— I feel like I'm architecting an AWS cluster trying to keep together our like business in terms of how I— my job. I don't have too much experience from before the SaaS revolution of starting companies and every YC company that had a bad idea being forced to build the hardest part for them to incorporate around. That trend alone, half of the companies that we use to handle all these things are YC companies that pivoted to a problem that was hard for them.

Right.

So that's all helped. But my job has moved away from managing 40 connections to different teams and whatever to try and architect all that to managing 40 accounts in like our Notion, like 40+ for all of these different things and making sure all of the inputs and outputs are linked to the right places. And then I forget to give Fondo access to our deal account, and now they can't run the right tax for a specific state. And it's way better, but we still need our Firebase moment in starting companies, if that makes sense.

Yeah, I wonder where that's gonna go. It still surprises me that, you know, So I haven't, you know, I haven't been, you know, purchased lots of software in the world of tech before, but never been involved in purchasing HR software or payroll software before. And it's just amazing how much is out there. You know, our IT team is fantastic. And we have this beautiful Okta login that just has every tool that we possibly need. And it all works. And it's wonderful. And it's just, to me, it's really cool how you can leverage all of this stuff. And that's why I love infrastructure. Infrastructure is all about leverage. Right? It's how much can you just, how much lift can you give in return for little action? And that's why I love doing what we do here at PlanScale. But it's amazing how much leverage can be gained starting a company and using all these kinds of tools and us being part of that is really, really awesome. And similar with other providers that provide parts of the stack, you can just go and build. It's awesome.

I'd say one of my favorite parts has been the accessibility of the smaller options, like going with a smaller HR provider instead of a big one where I can personally email or text the CEO what's up, going with PlanetScale instead of RDS and knowing I can hit y'all up to fix things. Like, as I mentioned before, it feels like I have one of the best-in-class developer, like, database or database development teams in the world working with us just like another member of the team, but I'm paying them exponentially less. And that feeling is really cool. And it's definitely part of, like, given the decision or the choice between, like, a large company that's existed for a while that might be a little more work, a medium company that I'm confident could solve the problem, but I'm not confident I can get good support from, and a smaller company that's 80% there, but I know I can push them through that last 20%, I'm always going to pick the small company for us to bet on.

Absolutely. Absolutely. And, um, I want to make sure that our support and the way we interact with people scales. Our support team are phenomenal, but you'll see as well, like, our engineers are just— they're incredible and they love our users and they want to hear from our users and support our users. And I spoke to someone a while back and they're like, oh yeah, every time I tweet that I'm having like a little issue or a question about PlanetScale, 3 engineers of yours reply and I could jump on a Zoom with them. That's just amazing. It's because they truly care about that we really are building the tool we would want to use. Truthfully, we're all scratching an itch of we've got all of this scar tissue from years of scaling databases and we just want to build the product that everyone, we would all want to use at any point in our career and that comes down to support and that interaction. with users. And it goes right up to the top end, like companies that are rocket shipping in growth and adding terabytes of data a month, going wild. They come to us because they know we've also seen the things that happen around the database. And quite often we end up, you know, with our customer engineering team that again, just, I mean, they're the customer engineering team that support loads of those companies you see on our homepage. They, they, there's nothing they haven't seen, just like nothing. Any, like, so we end up explaining to people like the downsides of the database or like they now they bought the product, they want to move from this old data store or whatever. We end up like working on rollout strategies and how they would move and deploy their applications in that sequence. And it all comes down to just having that very human connection with the product and the people building the product. And something I'll be keenly focusing on as we grow over the years is making sure every customer that comes to us gets that awesome experience of, oh, I'm buying from someone that understands me, that, that, that really care about my success. That's something that I will always try and focus on.

This is, yeah, it's a really good point. Something I've felt, and I'm trying to remember for this one, one of the cool things about the developer world is like all these new developer tools and experiences is every single one of them has to be built by a developer. So someone down the line understands our problems as developers. It's a matter of how empowered are they to be the one to speak up and like communicate back, and how good are the processes to do that. Where I felt the most pain here is the things that are just outside of engineering. Like, I would argue AV tech is surprisingly close to software engineering in terms of the amount of engineering involvement that should be expected and is necessary, but it's so different in terms of the likelihood that the engineer on the other side understands a fucking thing about the problem you're dealing with.

dealing with. Right.

Like, I— one of the most frustrating realities I've experienced was realizing that the, the vast majority of people building like mobile applications at a media company did not use that like platform at all. And they were there to, to show off their like prowess in Swift and the new Apple APIs and prove that Kotlin's super cool, not to help the users and the creators on the platform they were Right.

You don't ship your backend. You know, you have to build that experience. That's why the word developer— I'm actually going to— I use it a lot, but I'm going to stop, I think, because it's getting ruined now. It's becoming the new— like every company now says they focus on developer experience. And it's like, okay, what do you do? And they're like, oh, we have an API. It's like, great. Brilliant. You caught up with 2013. Like they just— they don't get it, right? You can tell the best products built for developers are built by highly empowered and trusted engineering teams. Like, they are the folks, if they are producing something and they are trusted to shape it into the thing they, you know, they would love, and if you hire people with great taste, you produce amazing results. No product manager shuffling around Kanban boards is ever going to produce that magic. You just have to let people run and you have to trust them. And everyone at PlanetScale, but especially the engineers that design the things that we all interact with as humans, they have so much trust to go and iterate and evolve and consume and use. And that's why we produce these results. And I feel there's a lot of companies trying to catch up. And you see these companies trying to do the serverless database thing now, right? And you can tell that they're mimicking the movements. They're like, it's cargo culting, right?

Yeah.

They're kind of like doing the actions, saying the words, and then you use their products. Like, you fundamentally don't understand what you're building. You've just latched on to the next thing.

Yep. I've experienced this so much that I am skeptical to try any product that I can't talk to the decision makers of. If I can't see you talking about this thing and understand why you built it, I am significantly less interested in using that thing, period. And if I like, especially in this space, one of the reasons I was so interested in PlanetScale was knowing your history at GitHub and the company's history building with and on top of Vitess and building for all the different like customers and like users you guys have had for Vitess and PlanetScale forever now. That was a huge decision maker for us. And it's crazy how often I don't see see that. To shout out Jason once more, one of the more mind-blowing things— I've talked with Jason a lot about how the hell he became one of the best developers I know in under 3 months from first line of code. Because to this day, he's one of my favorite people to talk about new complex engineering problems with. And I just wanted to figure out how he learned. And he shared this idea of applied wisdom, where all of this information exists on the internet. All of this benefits us, or it benefited somebody in some way. That's why it's there. Nobody's writing a blog post or sharing advice where that didn't apply to them, or they didn't believe it applied to someone in some way. But it is our responsibility as the consumer of that information to distill who wrote it, why they wrote it, and to an extent, their bias in the advice. Like, why does this person think Tailwind makes a lot of sense? How did they use Tailwind?

Right.

to solve their problems. And the way Jason approached this issue was, okay, I know I want a better system for my styles. I know that my fonts look bad and I want to be able to solve these problems more easily. I'm going to look into different solutions. He heard about Tailwind. He went to their website. And rather than going through the docs and reading it obsessively, he went to Adam's, who's the original creator and CEO of Tailwind's portfolio, and he read the source code for the website to see how they use it and what it's doing. And from there, he distilled, this makes a lot of sense for me. This wisdom applies to what I want to do. I should use this.

That's a really awesome way of doing it. And it's all within— it's setting it within context and putting it within context. And I think you can fail any technology by your use of it. And we don't— people don't think about that enough, right? It's like, this thing sucks. Well, you know, okay, like someone could say Postgres sucks, whatever. And then you find out they're using it as a message queue or doing some crazy— you know what I mean? It's just like some silly thing that they shouldn't be doing with the database. We have to be deliberate and intentional about how we choose these things and do these things.

Yep. I think the problem I see the most is a failure to build context on both sides. Both the presenter of the thing they're excited about being too excited to do the part where they built the context. Direct callout, the Remix community is incredibly guilty of this. They think they solved every web problem. They solved a few problems really well, but they failed to contextualize the problems they solved well enough. And as a result, lots of people assume this is targeting my solution space. This doesn't work for me. Now I am mad. But that's a failure to communicate the context in which that technology is strong. As a result, At this point, just assume every person sharing advice and giving tips is bad at building that context. And as a result, I recommend us as developers get used to building it ourselves. When you see any tip, any piece of advice, and this goes for me too, when y'all are here listening to me shill the things I love, I expect all of you to take the time to go through why I love these things and what I'm building with them to get an idea of if it is the right thing for you.

Right. And we should, like, I think technology should express its opinions very clearly. And like interfaces are so powerful and standards. That's one thing, reason I, you know, I think the Rails community does so well as well, is it expresses a very strong opinion of how things should be built and hands back a ton of freedom there. And obviously we saw Rails do very well at GitHub being one of the largest in the world. And, but Rails comes with an opinion, right? It comes with its style. And I think that helps people learn and get up to speed much, much easier, and they express it very deliberately. And so I'm with you. I'm completely with you.

Interesting. To contrast that, I'm curious what your thoughts are on things like Beam and other examples of how the pieces assemble, because I find those to be some of the most useful projects to put out. And I'm surprised at how few companies I'm seeing taking advantage of the opportunity. Like, Beam's interesting because in terms of the tech, there's only one piece of that that is built with PlanetScale technology. And I could argue it's the easiest part to replace in Beam would be PlanetScale.

Yeah.

Putting that on a different database would be much easier than changing almost any other part of the project. But I think it's such a good example of being where the developers are and being able to like have those communicate— those conversations, share examples, and have a great place to start the learning from. I always like going back to source and having a simple focused source example to work with is one of my personal favorite things. And I'm curious how you feel when you look at something like Rails that has all these opinions and solves all these problems and where you're at, where to some extent you can't have opinions, you have SQL. SQL has no opinions and you have to build on top of that. Where do you guys think you fall there?

Well, it's interesting, is that we have a very interesting challenge, right? Like, you know, we have users using Java, we have you, yeah, we have to stay interoperable. But I try and keep up with the community and the folks building the newest of the new because we learn, like, we learn that tech is generational and someone is always working on something new and exciting and I don't want to miss it. I want to learn and see why people take our tech and hold it differently. and understand and learn from their use. So I try and understand these technologies and why people do these things. And it was obvious and natural to us to put Beam out with the stack that we did because it's where a lot of our audience are. We obviously have a very large enterprise audience, but we also have this extremely large and growing very quickly audience of developers that are building this new stack. Beam has got— Beam is— there's many reasons Beam is out there in the world. So first of all, Beam started as us needing a communication tool that was like Team at GitHub. Like, so a lot of us, a bunch of this company is from GitHub, but there's an immense amount that aren't, but we're all remote and we all want to represent ourselves in one place. And so we, you know, we created Beam and, you know, it's beautiful. And we thought, you know, we should open source this to the world. The world should see and get some value from a tool that you could just use internally at your company. And if they use PlanetScale with it, that's really great. That's nice. But We love open source first. We believe in open source. And so it really came from wanting to give back, but also provide a tool that's a good reference, right? You can take it now and like say you wanted to just like do a video that's a demo of an app. You need an application and you have to always make one up, right? And it's always really awkward and annoying to try and make up. So we just thought, well, it's a real app, has real use inside a company. People can use it for demo apps. We can use it for whatever. Super easy to build tutorials on top of, so we went that way.

I want to dive a bit more into this because I think it's so interesting. I am curious in terms of staffing, hiring, and the team. Obviously, you have tons of database experts, but it also seems like you've been hiring really awesome user experience people too. I'm curious, how much things like Beam are them looking for more user problems to solve versus how much it's relating with your customers by building things like them versus how much is the desperate need for that communication tool? Like, what's the split between those things? And do you have a good gut feel of how the more user experience-focused engineers feel about their day-to-day work?

Yeah, actually. Okay, so first of all, we would have built it regardless. Like, you know, yesterday it was 1, 2, 3, 4, 5, 6, 7, uh, 7 Beam posts in a company of 90 people, right? Like, it's got high use for us. We needed it. Like, when I, uh, I, I know, and one of the most experienced database engineers we have just at PlanetScale, but also in the industry, uh, is a guy called Shlomi. He was at GitHub, but he came to PlanetScale before I did. When I showed up, my first meeting, I was like, right, what can I do for you? He goes, I miss team. I was like, okay, let's get going. So we built an early version and it was not the Beam that you're seeing now. We went for a new look kind of approach, made it really nice. So it's all utility. Our frontend engineers and our design team as well, like we have We have product designers and then we have brand designers and they all work in unison. They like, for example, when we're picking colors that go into the product, we work with the brand designers to make sure they're unified with all of our marketing. And so I'm gonna speak for all of those phenomenally talented people when I say they all, I think they love their work because they take on this challenge that most companies would not, in the sense of taking very, very deep tech and delivering it in an unrelentingly simple way. Our user interface is incredibly simple, and our marketing is incredibly beautiful because we really respect the craft of what we're trying to do and put it out there. And Scully's in chat, and I can see she's one of our immensely talented designers. And I spend my time, I mean, Skelly can tell that, I think she'd— I spend a lot of time with the design team, a lot of time. And it's because I really care about how things look. And so do they. And we have this healthy tension in the middle of backend folks solving really deep problems and frontend folks that don't understand don't know, don't like, don't, wouldn't even begin to. And we don't want to resolve that. Like we want their user journey of, I want to be able to do this, this, this to be possible with the backend tech. And that's what data— most database companies don't do that. They're like, here's the thing. Here's a, here's a docs page with 25 commands to run to get what you want. We say, well, it should be one step, right? So like that import tool. we had Jason Long, who is one of our product designers and was one of the earliest product designers at GitHub, one of the earliest employees of all of GitHub. So if you wonder why PlantScale looks familiar, it's because it's the same person that spent a lot of time designing both products and making it beautiful. And he knows the rules of developer experience, he knows the rules of explaining these like hard concepts. And then we just work. So It's, it's a hard job. They do an amazing amount of work because we just refuse to put CLI commands that— and all piping this and shove this variable there and do this thing. I can't believe it. I go and look at the instructions to do the same operation on PlanetScale and other things, and it's like 5 pages long. And if you go to our documentation, shout out to Holly, it's phenomenal. It's like, it's really good, but it's instructive and it's, it's there to give you sense of what we're doing for you and explaining it to you and how to get you through the user journey. It's not just a list of commands blurted out at you. So it's— we spend as much time on design as we do backend.

That's a really interesting way of putting it. Uh, an idea that was being like hinted at throughout there is the idea of almost letting your frontend developers be as close to your ideal hard-to-get customer as possible so that you can have them as an internal testing ground, but more importantly, intimately familiar with the pain points. If your frontend developers got too familiar with databases, they might not notice the difference between a 1-step and a 20-step setup because they're so familiar with the 20-step that it feels like 1 step to them.

100%. We talk about ourselves being optimistically unreasonable. And the other reason I spend my time with the JavaScript community is You know, I talk to Guillermo or something, and he'll say, well, database should just do this. And it's the big should, right? Okay, we can all say should, but he's right. They should. It should be this simple. We should say should a lot about our product. It should, should, should be better. We should do better. So I love working with optimistic and unreasonable people. And we're deeply unreasonable. Like we hold stuff back. We redo things when they're not to our standard because we want to. And I'm not even going to justify why. I don't know why. Because we want to. Fuck it. I don't know if I'm— whatever.

Swear all you want. No, this is— we curse all the fucking time. Go nuts.

Yeah, like, fuck it. We really fucking want to do it. I mean, like, truthfully, truthfully, it's just our standard. I don't want to put ugly shit in the world. Enterprise software is gross. Like, we— and we could just have really boring solutions pages that talk about, like, all of the enterprise goodness and all of the stuff that our database is wholly capable of.

But why?

I mean, this to me, the iPhone, is one of the most inspiringly wonderful devices. They had to work on the LiDAR standard to be able to do Face ID unlock, right? But it's all hidden behind a single pane of glass in this tiny, you know, that's what we want to bring a similar level of— I mean, we'll never get close to the iPhone. It's a work of art, but we, we just, we just want to produce something so powerful, so simply. And that's why we're not cluttering up our UI with all of the other unactionable crap that every other database provider wants to shove in your face.

I really love that framing. I try to find the right way to put this question. One of the interesting ideas, and this gets pushed on me just as a recent founder, is the understanding and working for your customer. An experience I had a lot working at a place like Twitch was the average person's customer wasn't Twitch's customer in the sense that a backend developer's customer was the frontend developer.

Mm-hmm.

The frontend developer's customer customer to some extent was their PM and their designer, but it also was closer to the user. The PM and designer's customer is definitely the user. I found it was important to have everyone top to bottom, despite their immediate customer not being the Twitch user. I found it benefited everyone top to bottom if they had a better understanding of the user. So an interesting thought I have with where PlanetScale is, is it almost feels like by both the need of the product and by the sheer way things happened, everybody at PlanetScale's customer is the PlanetScale user in the sense that the database team, they're providing the thing the users are using. The user interface team is providing the experience those users are having. And all of these people also are the customer of PlanetScale's product.

Right.

You've blurred these lines so far that it's like a big blob of everyone Kind of getting it. And I really enjoy it. That seems surreal to me.

Yeah. And that's why I'm really nervous to apply much process. We don't have product managers at PlanetScale, by the way. Not a single one. And that's deliberate. Because if you spend your time very deliberately thinking about the user, the customer, you listen and you discuss and work with that tension and use your own product, you can build something really, really amazing. And product managers, I'm sure, will be somewhere in our journey. Maybe they're not. I will actually say, no, I want— a large part of PM's jobs is incredibly important to companies. And we will hire people to do the very essential things of talking to customers. Like, we do talk to customers, we do user research, we do interviews, we do all of it. Like, you know, you're gonna experience this next week, right? Like, you're gonna go and experience the product early, get your feedback, and then we'll do the same with someone that's running a majorly large, massive website and get their feedback too and synthesize and rethink about it. We'll do all of those things. Like, we're not hostile to that way of working. But the people that decide the roadmap, it's a discussion between myself, Nick, who runs engineering, and our engineers that care, right? At PlanetScale, an engineer or a designer or someone in marketing, they're all perspectives and they speak at the highest levels about our product. We are highly cross-functional and you can have someone from any part of the org shepherding delivery of something because if they have the most context, it's not about title or rank or whatever. We're open to learning and listening from everybody that has a perspective. And we discuss it and it's a really awesome thing about our culture. And a large amount of our culture is defined by those engineering philosophies.

Yeah. This is very— this is a relief for me because this is very much how I'm trying to build what we're building. And it's awesome to hear that at PlanetScale scale, it's still working. Like knowing that my disdain for process getting in the way of solutions can get up to 90 people, that's a huge relief.

You can go a lot further and go to 120,000 people. There's less than 20 people at all of Apple that decide what product delivery looks like.

That's great.

The human interfaces team at Apple pretty much decide. And again, they have no PMs in that org either. They work on everything. And it's that, you know, layering of hardware and software together to create something incredibly beautiful. It can be done at massive scale. It's how the most beautiful products are built. They are not built by committee. They're built by small teams of people with massive amounts of context and a love and dedicated to their users that hone their craft. They're obsessed with their craft. And we are going to scale that. If we lose that, we lose our soul.

That's really exciting to see. And I hope that I can stay close enough to continue learning from all of the lessons that PlanetScale has been learning throughout. Speaking of one last lesson that I've taken from PlanetScale, it's a bit of a topic shift, but it's also one of the more exciting things y'all have done. Holy fuck, the pricing. How much cost are you guys eating on that reads change? Because that is absurd.

Our free tier is spendy. Luckily, again, our fantastic infrastructure team have worked to heavily optimize it. It's very well optimized. It's not flat. Abby. But it costs us a lot of money. And you know what? Like our larger customers make sure it's paid for, right? Like that's one thing. And we want to be there with you when you're starting your business, right? Like again, we don't want to have people kind of forking over their credit card on day one to get something done. We want them to just build, build, build. Um, and so we made an extremely generous free tier. So we, we analyzed our own usage as a startup and we were kind of like, okay, so we've got this many users, um, we have this much going on, like, should we be paying for this now? That's honestly, that's how we thought about it. We didn't, we weren't like, how much do the servers cost underneath? We were like, when is it like kind of like, oh, we're doing something serious with this thing. And like $29 is not unreasonable for what we're doing. That's kind of how we felt it out. Again, that's user-friendly, that's user-centric in how we do it. And then we worked out we could make it even cheaper with the resources we— because we give you a Vitesse cluster under the hood. We worked out that with the resources that were available, we could give you more. So we did. And now I think you could run a pretty meaty app in the free tier. And we have a channel when people upgrade and we see it, like we just see it like, woo, someone's upgraded to the scaler plan. And that happens nicely frequently, and that, and that's great. And we have our very large enterprise customers that we serve through our sales. And in the meantime, while you're building your business or you're running your blog, it's on us. And we love— and we, and we make it that way.

The sales alert channel is essential, and I cannot wait till it gets noisy enough that I feel like I have to mute it. But we're not quite there yet, but we're getting there. I know you want to take a quick break. I want to make sure everybody in chat has opportunities to ask questions quick. So if you want to run, I can field some questions.

Oh.

Take your time. Well, yeah, any of y'all got some questions for us? I— this has been super cool so far, and I hope that y'all are enjoying this as much as I am. This has been one of my favorite interviews so far. Anybody got questions for our friend Sam when he gets back? No questions?

Lame.

Someone's got to have something. I saw somebody mention that MySQL was the way to like learn and get started and Postgres was production. That was one of the, the things that I was scared to say out loud because that could become the entire conversation. But that was an interesting point that I, I couldn't disagree with more on. SQLite is how you start, everything else is how you go to production and scale. But, uh, that aside, the chat's been awesome. You guys have definitely gotten it overall. Switch the scene back over for our friend Sam. Debbie, back.

I'm back.

No questions so far. Uh, cats drunk in Cav on the way home, our legendary creator of tRPC, always lurks these. It seems like everybody's been loving the conversation so far.

Yeah.

Mohammed mentioned that the pricing was suspiciously cheap. I would definitely love to talk more specifically about the change in reads. Like, that was strange to me because I already felt like the pricing was so cheap. And it went from cheap enough to be ignorable to cheap enough to be invisible. At the same time, I know that there have been users who have had problems around the things like the lack of foreign key constraints causing them to just do way more reads than they intended because they're going through every single row in a table to find one field. I'm curious how much of this was to make the cost invisible versus how much of this was to make like developer mistakes digestible, if that makes sense?

Interesting. I think it's the first, but it has a nice second-order effect on the second. So first of all, we had people make mistakes in the early days. They got bitten. That's the big downside of serverless pricing, right?

I think we both know the article that inspired this question. Yeah.

And, you know, we comped the whole month And we have currently, there is nobody who has ever settled a bill after making a major mistake. We have, we've sorted them out. We understand. Um, there is a few things in our roadmap coming that will mean that making mistakes like that are just not an issue. Um, uh, we'll see. More geeky streams? There's some great stuff coming that will, and many actually, like, there'll be 3 or 4 things that are coming that will mean that that's not even much of a problem. But the main is we looked at what people were paying and what their bills were. And we wanted to make our pricing really friendly, really intuitive. Because again, like, you can't claim to do the things we want to do and to love your users, then have hostile user pricing. When you see people that are like, oh yeah, I started on— I did some tutorial on AWS and now I have a $400 bill. I didn't want anyone to ever experience that. And we felt really bad when someone actually ran up a big bill, but immediately we were in seconds, we were out there settling, sorting it out, making it happen. So yeah, we just wanted pricing that was extremely fair and friendly to developers who are our core audience. We are developers, we love developers. And so we just kept refining it. We spent a bunch of time on it, looked at a lot of data. to understand where people like— it's also the, the first pricing you saw from us was just like us just taking a shot in the dark. I mean, like, let's do this, we're going to market, whatever. And then now we've got loads of data on usage data and got some really interesting proportions between writes and reads and understanding that people are doing a lot more reads than we thought. Reads are kind of when your application's suboptimal, that's when they really creep in. People like get N+1 problems or they're doing some really unscalable things with reading. They're reading Like not caching properly. So reads are where people get heavy when their application— but we also don't want to force users to have to optimize to stay within a budget. We want them to move fast. So that's why we kind of got super generous on reads.

Want to guess how many reads my stupid Pokémon app got to?

Tell me.

It was over 90 mil for a little bit.

Oh, wow. See?

Yeah. I made stupid mistakes there. I redid the cache layer and that helped a ton, just taking advantage of Next intelligent caching pages and invalidating them not on every request. And there was definitely some users who took advantage of how forgiving the API was and sent like 20,000 calls to try and force Dialga to be the roundest Pokémon. So yeah, that was a fun one, but it's back in the free tier. So thank you for that.

That's good. I'm glad. And those, you know, so many funny stories from the GitHub days of developers doing things that seem kind of innocent and normal against the GitHub API and causing just unbelievable amounts of problems and traffic and what it took to fix those. And, uh, yeah, it's a never-ending issue.

Yeah, I've definitely felt that a bit at Ping in terms of like we built a primitive to make it easy as hell to take somebody's video feed and put it somewhere else and could not have guessed the crazy things that Some users are doing. One of our early customers used the tech that we built here to have a guest. So he runs an organisation for VTubers, which are virtual avatars where you have face tracking software animating you as an animated character, usually live on stream. So to allow these animated avatars to go out in person, they used our tech. They took an embed, which is the technology I used to get you into my stream, full screened that on an iPad, strapped it to somebody's face, and had them walk around.

Wow.

walk around Tokyo as the VTuber in the real world using our tech. We could never have imagined this use case.

Yeah, that's actually another fun thing is you learn about the companies that use your stuff and get really excited about it. I love looking up the companies that upgrade and you see so many things. We had a really great one is we were like, oh, there's a customer that's growing really quickly on the platform. we looked who it was and it was Solana. They're powering their community and their site and everything off PlanetScale. And it was like, that's cool. That's really awesome. We're a Web3 database without even realizing it, without me fully understanding Web3 yet. So that again, you get excited by proxy, right? And so we had another customer, Playboy. They launched a new platform. And when they were going live, like I was getting all excited. I was like watching the press. I was like, they're on PlanetScale. You know, you just get super hyped about what they're doing. And so we're in Slack with them, helping them launch, all of that. You know, it's just really cool to be part of it.

Yeah.

Scully's listing Pokémon, that one that I don't know. So I'm gonna have to look up that Pokémon. I used to play Pokémon. I played it, but in the old, old Game Boy days, that was when I was, uh, I haven't played it in years.

I, I am definitely a Pokémon millennial in the sense I got in Gen 3, which is probably right when you left, like Ruby, Sapphire, Emerald. And I'm a firm believer in the stance that the older Pokémon, specifically Gen 1 and 2, were weaker in design. And the reason people continue reaching back for them is nostalgia, not design quality. And specifically from like Generation 4 and 5 upwards, the quality of Pokémon design improved a bunch, but was frustrating to like players because it wasn't nostalgic enough. But yeah, I—

Yeah.

I am a huge Pokémon fan. My only non-tech videos on this channel are Pokémon reviews and skateboard videos because everything else is engineering. It's a huge passion of mine and I've always loved the Pokémon scene.

Nostalgia is incredibly important. Actually, it's very funny. Scully, who's doing some design right now for our new feature, has some very nostalgic design as part of the feature ship. So you'll get to see that in— not that I'm aware of. Maybe that's why they moved to PlanetScale. They were previously having database outages.

Interesting. I don't know too much. I have stayed out of Web3 for a while now personally, but it's really cool to know that groups like that are on. It's also nice to know that you're with us in the pool of people who didn't know that their platforms were going to be used for like risqué and SFW and like sex work stuff that ended up being cool as hell. Like, that's— it's cool to see like when your technology is good, people People all over the world you would never have guessed start using it for crazy things. Yeah.

I know, I love it. Whatever helps them help their users.

One question I saw come up earlier, and this is always going to be the one, we touched on it a bit earlier, but the idea of how is MySQL better and different from Postgres? There's also a question earlier about how— it wasn't a question, it was a mention of how a person had heard that MySQL was the place you start and Postgres was the place you go to for production, which is really strange to me, especially when I know stories like PlanetScale's. And there was an Uber article you shared a while back about how Uber moved back to MySQL primarily due to the separation. If you're down, want to hear a frontend-focused full-stack developer do their best to describe why MySQL is different and better, and then you could come in and correct all of my mistakes.

Awesome.

I'm going to get it all wrong. Awesome.

Go ahead.

So Postgres is a phenomenal open source technology for strong data system management with direct access to that data. When you make a query in Postgres, you are calling that exact data structure and getting the exact representation of that out. MySQL is different in that the query client and the resolver layer and the actual data system that back it are separated, and that separation allows you to do some crazy shit as far as I understand.

The API that serves queries and the backend storage engines are completely separate. That's why InnoDB came to existence. InnoDB is an absolute marvel of engineering. Truth truly is an incredible piece of technology. That is the primary backend storage engine for MySQL now, and it was actually built by Oracle, and they built it as an open source contribution, um, before they owned MySQL. It's a really funny story. They, they— and it is incredible technology. And so it's got this, the pluggable backend, um, and that makes it really powerful to— there's been a lot of storage engine like iteration, which is, it's pretty incredible. I don't want to say there's— that MySQL is better than Postgres. I think it's different with a different set of trade-offs. But the thing you're saying about how a lot of major websites moved to MySQL is just true. I mean, there's just, I mean, there's so many stories of this, so many. And it really has surprised me how much of our very large customers that are coming on board are coming from Postgres, right? They hit scale limits. And I want to do a post on this one day because we don't have all the data yet, But based on what people, the data size and traffic volume that people come to us, anecdotally, they come to MySQL customers when they come to PlanetScale with scale problems, have a lot more traffic than the Postgres customers that come to us having scale problems. Like I know like a lot of the Postgres installations that people are coming to us from, um, would be totally fine on vanilla MySQL. So it's a very interesting thing to see with Postgres, but I don't want to say bad things about Postgres. It's powering so many websites and so many cool products, and it's a great piece of database technology. I just think they haven't made their focus, you know, very large scale, and that's what we're here to do. And ultimately, we're here to make it a non— an irrelevant thing, right? You should just know you're using PlanetScale and feel great about it. Hopefully.

I am definitely getting pretty close to there. Funny enough, the frustrations that I have are not things that I'm used to from Postgres that MySQL doesn't have.

It's the—

I don't want to say— yeah, the compromises that exist in moving to a fully sharded data system such as Vitess and PlanetScale. And I'd love to talk a bit more about what your stance is on things like foreign key constraints, cascading deletes, and some of the things that you don't have. How much of that do you feel should impact developers? How much do you think it does? And how much do you think PlanetScale's stance on these things is the right call, not just because it lets you use PlanetScale, but because those things do hurt scaling and potential data consistency long-term?

Yeah. So if it was not a trade-off, there's no philosophical— we have no philosophical disagreement with foreign keys at all. And obviously people can use foreign keys, we just don't support the constraints. And you can do cascading deletes if it's supported in the ORM, if the ORM isn't relying on foreign key constraints. So We didn't run with foreign keys at GitHub and we used ActiveRecord and you could use, you know, dependency delete, I believe, is the call. And you can do cascading deletes to go down through all the dependency tree and delete those objects. So it's doable. It's— but yeah, we don't support it, right? And there's a reason for that. They don't fundamentally work with the way we do online schema changes. They're very difficult to do in a sharded system. The idea there is we're making a trade-off for you. More developers tell me they're terrified of making schema changes when they have traffic on their site than they do tell me that they desperately rely on foreign keys. And I know some do, but we've made that trade-off so that people can scale more seamlessly and not rely on fundamental patterns that just disappear over the long term, right? Like if you can— Like I think about this like when someone uses and builds against any platform that you build, you're making a cookie mold and their application's gonna get baked into that mold. So it's your responsibility to choose a cookie mold that's shaped— now the analogy falls down. I mean, I don't know why I started with cookies, but the point is, um, it's your responsibility to set the defaults that are sensible, that work, will work for the future, won't betray them when they're like Oh, I loved this at the low end. You talked about some low-end databases earlier that had like developer experience. Like, this was amazing. Oh, my favorite version of this is the distributed SQL crowd. The, the, all their marketing is like, oh, you write to Tokyo and it shows up in New York magically instantly with no trade-offs. It's like bullshit, utter bullshit. If you've built any system with latency in it, you know that's complete nonsense and it's lying to the users. And then when you look, there's a million caveats on their documentation page that explain why we know that's impossible and whatever. Serialization doesn't work and everything, right? So this just falls into that category of like, we're not going to try and fake it for users. We genuinely believe that the trade-off we've made to allow seamless, massive, at-scale schema changes happen and not be able to support foreign keys is the right one. And if we could magically and it worked, we could, but it doesn't. So we're there, unfortunately.

Really?

Same with Lexity. We're not going to pretend— when, like, you know, as we allow more and more easy ways to scale your data around the globe, we're not going to do it the irresponsible way that pretends that multi-master global distribution just works out of the box. We're going to do it in a way that accurately Kind of shows the trade-offs of building systems that are distributed.

Very interesting. And I'm so much more excited for the conversation on Monday knowing this framing of things. Yeah, it's a really hard spot to be in where in the standard there are standard practices that make the standard way harder to scale. And just like a dumb example from the web dev world that I saw, was that Create React App is having a bit of a crisis right now where they moved over to Webpack 5. And one of the cool things Webpack 5 does is it stops bundling your Node.js built-ins into your build if you call them. So if you call fs or crypto inside of your React app, that shouldn't have built and it finally doesn't anymore. But as a result, there's a ton of people freaking out about how their Create React Apps broke with the latest version.

Right.

And I'm curious, Like, I know the foreign key constraint thing isn't a philosophy, but at what point do you have to make philosophical adjustments to meet developers where they already are at the— knowing that that will compromise some point of the scale or the way that PlanetScale builds?

Yeah, we are always open to feedback and listening, and we will continue to weigh it. The reactions and excitement to being able to do— like, we've come to— customers have come to us and they've said, it's been 6 weeks since we were last able to make a schema change. We just can't do it. Like, things go wrong, they break. You know, our application is like— like, we've got 3 features that need schema changes to ship, right? And it's a major serious problem. The customers coming to us with excitement about the features outweighs the ones that are worried about foreign keys. Like, it comes up now and then a bit on Twitter, but it hasn't been a blocker for anything big currently. So our ears are open, but it'd be hard to imagine we would fall away from some of the really cool stuff we're doing and going to be doing in the future to bring back foreign keys. I think, you know, there's lots of iteration cycles left. Time is you know, we have time on our side. You know, you never know, there may be a solution that is better, does something better, does something differently, is better within our system. We're always listening to those concerns. We think about it a lot. I wish we could change it, but for right now, it feels like the right trade-off based on how things are going.

That makes a ton of sense. I will say I have the concern of like responsibility shifting where PlanetScale's done a phenomenal job of taking a lot of the responsibility of good database management stewardship away from me as a developer and just made it the default. But there are practices that are necessary to continue operating that database well that are necessary at scale. And it feels as though to some amount, things like foreign key constraints have been— like that responsibility's been shifted up out of PlanetScale's space in order to make PlanetScale the best solution at what it does. How important is it to keep track of where that responsibility lands? Like right now it falls on ActiveRecord or Prisma.

Yeah.

Prisma's— I'll be frank, I don't know how many Prisma people are here. It's not working for us. The Prisma like, uh, or foreign key like relations that are built in using like the Prisma wrapper on top error every time we try and cascade a delete. If I have a room that we remove The user-in-room mapping should be cascaded. And instead, we get a production build error. We get a runtime error that's an obscure Rust binding thing.

Sure.

I wrote an issue a while ago. It went stale. It's whatever. I'm not trying to vent about a specific issue so much as that shift in responsibility where the problem is the database's decisions and assertions. And I agree with those assertions, But now that the responsibility's left PlanetScale, the likelihood of that responsibility being handled correctly has gone down dramatically. And I'm curious how you mitigate those problems, both in the design of PlanetScale and its product, but also in the relationships you build with these other companies like Prisma and how they solve the problems on that side.

It's a hard question to answer because I feel a little guilt, right? Like that we've moved that responsibility. Like, I think you've gained from like telling me today and, you know, I deeply care about the user problem and taking those, that pain away. I think we're just taking a greater pain. Like the fact is we've like on this specific issue, I don't think we'll pass any more pain on anything else. Like our bar is so high for not doing that, right? that throughout the user arc and the journey of the customer, I think we'll solve way more pain than they have. But yeah, you're right, it won't be done as well. It's somewhat— maybe there's an opinion we have to make upwards. I don't know. Yeah, it's something that will get continual iteration and thought. And we have ideas. I think we're still talking about a few other things and the things that our tooling can do. Yeah, I think we'll just have to keep iterating and trying to make it better.

I want to be clear. I actually think y'all are in a really good spot with this overall. If I didn't see the collaboration between Prisma and PlanetScale that I have been seeing, these concerns would've went from concerns to deal breakers that I would've taken action on. But knowing that people much smarter than me and much more dedicated to these problems than any team I could possibly hire, are working as hard as they are to solve them means that I'm not particularly worried. I'm more curious how these things are thought about and decisions are made around them at scale as you guys try to be the solution for everybody.

Yeah.

How do you solve the problems everyone has, even if those are problems that don't fit perfectly with your model? And yeah, it's a really tough thing to solve. And we're running into this too with Ping, where there's people who want to do crazy things with this. Like we're regularly getting people who want to do game streaming on this product. This isn't a game streaming product. This is for calls, but it's, yeah, it's a really hard line to walk.

Yeah. I think you've got to be very honest about what you're there to do. So another buzzword in databases is HTAP. Hang on, let me look. Hybrid Transactional Analytic Processing, I believe. Yes. Okay. It's the belief you can build a database that will do analytics as well as OLTP, which is what we're good at. Um, I mean, how's that real? Like, how is anyone able to truly do that? They lie. People tell that— they'd say like, we've achieved it, we're the best analytical database and we're the best online database. That's just not true. It's like, so avoiding stuff like that is how I think you do it, right? So Mahmoud in chat said having docs, guides, recipes is a good solution. I agree. Like, that's the point. I think if it's not honest and if it's not like, here's our trade-offs and why And if you disagree with them, you're no less of an engineer, no less of a great product person or developer or whatever. As long as we make them clear as why we've done it and you look at this and you think, yeah, there's a fair exchange of value for me from PlanetScale, then I think we're in the right place. When it comes to large customers and thinking about their problems, we're very lucky that a lot of people when they're in pain with databases, they just want to get out of that pain. They have to unlock their business. So I genuinely think, and I mean this, and I've spoken to customers, I spoke to a really very successful large growing tech company, and I said, how many, you know, probably 10-year-old company now. I said, how much time do you think you've spent of engineering time on the database? Like how many person years of just like database scaling? I couldn't believe it. He said probably 100. Like he said, a 5-person team cracking away at it for years and years and years. And all the other engineers, that's just the database team, then the engineering team, and then all of these. So, and I had this experience at GitHub, right? You know, you'd fix a database problem, then you'd be okay for a month, then you'd run into the next one. You'd want to ship this thing, you want to ship this thing. And that's because databases are just very hard and very hard to scale. And so much has gone into it. That's why when these large customers come to us, they're very excited that we fix that and we'll solve that for them. And then that is done in a simple and easy way with a great CLI. Suddenly it becomes like, okay, Theo using it to build his startup versus a developer at General Electric using it. Actually, it's pretty much the same user story. Developers want to wake up, produce value for themselves, their boss, their company, whatever, get their shit done, not get hounded by the database and go to bed. That's how we solve for both ends of the spectrum is we really think about what are the developers interacting with the system. And then we have the other stuff that gives the boss a win, right? Like we, like that person's boss might get some cost saving wins. They might get, they might get better security by moving to PlanetScale, more scalability. You can make it an everyone wins things, but pretty much developers, enterprises, they use the product the same way. And then throughout the power of the backend, the enterprise capabilities are really there.

That makes a ton of sense. And like to go back to the framing you had earlier of starting from the performance and pushing down to the initial commit, including PlanetScale, I think that does make a ton of sense. It's weird because I'm so used to seeing companies that are focused on the easiest customer and then working their way up to the hard one with the biggest constraints. You guys are doing it backwards in the sense that you made it work for the hardest customers with the biggest, scariest problems. And now you have to convince the rest of the world that it's worth buying into early so you never have those problems ever.

Absolutely. And it's fun and it's awesome. I was talking to Nick, who's our VP of Engineering, and we realized that to onboard some of these large customers that we've been working with, We haven't had to— we've— all we've done is configuration changes for Vitess to make it tweaked to be optimal. We haven't had to go like, oh, there's a— that's a performance benchmark you need to hit that Vitess can't do. We just config— we've just been doing configuration. And that tells us that we've got something great. And, you know, Vitess has run at extraordinary scale. I'm like, there's one Vitess install in the world That does 28 million queries a second. God.

I'm assuming you can't share who, but that's insane.

Many GitHubs in scale. It's huge. Like huge. There's huge installations of this thing. And then, yeah, like you said, we scale it down. It's the same tech you're using, Theo, to build your startup, right? Like, that to me is amazing. And we've only ever seemed to get that— like, we have never had that from really deep tech like databases. We've had it from tools like Vercel, right? Like, they scale to massive scale and leveraging the nature of static sites and CDNs. And that's a much more tractable problem. It's not easy, but it's not like databases. And so to take databases to that scale, it's awesome. And it's the same codebase as well. That's the other thing that is really cool. You see companies that are building database that are inspired by Spanner. Well, it's not Spanner. Yeah, you read the Spanner paper, cool. It's not Spanner. This is literally the same codebase. They literally open sourced it straight out of YouTube. So it's pretty amazing.

I really like that way of putting it. Yeah, it's crazy to think that this technology that was built to make YouTube's databases scale is running that level of stuff at GitHub and is open for anyone to use. And now I, at a small startup, don't need to know a thing about databases or even SQL, can go click 2 buttons and be using the same tech. And that's a really awesome place to be.

Right. And there's some really cool features in there that come from that journey, right? So, um, who— and I'd love to hear in the chat— who's ever brought down a database or caused database problems by incrementing a counter? Just like hammering a single row Like you're counting views or something on a table, right? And you're just smashing a single counter, right? I am definitely guilty.

Or even better, reading from a counter, not that aggressively, but it turns out that specific GraphQL resolver isn't cached well. And having 30,000 people reading from one table that didn't expect that is enough to take down all of payments at Twitch, it turns out.

Right. So incrementing counters is really tough and to do it really large scale. If it's a single counter and you come into all these different patterns and then they don't use relational databases to do it and now there's 2 systems to do and it's messy. Well, here's a problem that, you know, when Justin Bieber released a YouTube, his new video on YouTube, a lot of people go and watch it. And that little count, that view count is not just something that can be stored in a lossy format. Every single view has to be stored because they pay based on advertising dollars to YouTube creators. So a single view going missing— so we were talking to another very large website that has a counter specifically for like— it's like a like type functionality. And they were like, well, you can't store that in a relational database. And we said, well, you can and we did it at YouTube. And that's— That's because they had to, right? It wasn't just like— if you go on a tweet with 50,000 likes, it doesn't matter if it's like 50,001 or not. Who cares? They can lose a like or two. But with view counts, you can't. So in Vitess, Vitess has hot row protection built in and it will take all the writes you can throw, like every count that you need to count, and it will flush. And if it notices, it will hold them, queue them away from the database. and flush them all at once. So the database can get tens of thousands, hundreds of thousands of accounts a second going against it, but MySQL gets one write as it flushes it straight through. So that is again, like buying database tech from people that have— that it's not— there's not a reason it was built, right? They're just building it from the ground up. Some customers are going to find that problem on that new piece of database tech versus them finding it when they deployed to YouTube. And there is immense power to doing a deploy of a piece of tech having 2.5 billion active users on it and then finding out the problems. You get that really awesome. It's the same with the query caching that we do. If we see 10,000 of the same query, we hold 9,999 of them back. Sorry, 9,999 of them is 10,000. Serve the initial one and use the same results to serve all the others. We can actually hold them in flight even without that primary query executing. So there's so many like really amazing, very robust pieces of technology inside of Vitesse that were there to protect and run the database at scale that we can all leverage now with this technology.

This is combining this with the point you made earlier about something like Vercel being the easiest starting point, but also the infinite scale. I, I've referred to that possibly erroneously as the serverless mindset. When you're no longer thinking in infrastructure, you're spending all your time thinking about the problems users are having. And Vercel did a phenomenal job of taking the technology Lambda that allows you to not think about scale and abstract it in a way where I don't have to think about Lambda either. I just write functions and call them.

Yeah.

It feels a lot like PlanetScale is putting in immense amounts of work to get SQL itself to a similar point where it's almost serverless SQL, not in the sense that there's no server, but in the sense that I don't think about it.

Right. That's why I love serverless because it's just like, it's just, you know, that's when I see products and you log in and they're like vCPUs and what's a vCPU? Like seriously, like why are you asking? I don't know how crap your software is. I don't know how much I have to put into it. I just want the job done. I think serverless is focusing on the user story. Why has the user come to us? To send us queries to get the data back. And that's it. That's all they care about. That's why we store your data in a high replica, high availability fashion. But we didn't ask you to provision 3 nodes so that you can get high availability. We just did it. We charge you for your, the storage, not times 3, just once. Just like you can price by saying, do you have 10 gig of data? Right. That's how much 10 gig of data costs on PlanetScale. It turns out it's free, but you know what I'm trying to say. Like, we don't— we're not asking you to like translate how many replicas you need for this and that. We just, we give it to you, uh, straight on. And I think that's why serverless is so amazing because it's just the user journey and it's just the story that you want to— you want people to use things simply. And yeah, like if you use Vercel and PlanetScale, you could scale to millions of users without a single infrastructure engineer. That's never been possible. That is just new era. That is— I just think the size of company delivering massive scale products is going to get smaller and smaller because of all this leverage.

Yep. Couldn't agree more. Alex just asked a question I was going to sneak in earlier and find a good chance in terms of the streamlining of the developer experience on top of these things to do the reach things, the stuff that sounds impossible. This is one that sounds impossible that I think the right people now exist at both Vercel and PlanetScale to do. Automatic preview links with Vercel CI and GitHub creating a new PlanetScale instance that's fresh based on the schema for that branch. A future where I can make a pull request and then have an instance that that's going against.

Yeah. We're very close to that. In fact, the bare bones are there. If you wanted to, you could wire that up with a bit of GitHub Actions and using our CLI. The reason we wanted to do branching is that we believe that you— like, environments and copies of your database should be instantly available to you like a branch. Like, we don't believe in staging environments. Staging environments have to go. Like, it's another environment to maintain and mess around with. You should just get a branch of your database and it should just be there. So, and you, you, you could very easily, with a little bit of automation on GitHub Actions, whenever you create a preview branch on Vercel, easily get a branch on PlanetScale.

Interesting. I did not know that. I have to play with that. The bigger pain point for me honestly is auth for preview builds because we don't do any email pass auth. We do everything through OAuth. So making OAuth redirects work on an arbitrarily generated URL is its own fun challenge. But since I haven't solved that, I haven't been personally as interested in solving the database side. But the idea of GitHub CI-ing my way to fully isolated environments for every pull request sounds super enticing. It's definitely a point of interest for us.

Well, yeah, and that's how we test as well, right? If you're testing functionality, you can just do it on a branch. And that's what they're designed for, to give you that separate isolated environment that feels like production. How many people are working on a local Postgres or whatever, and that doesn't look like production? that Postgres is completely different on RDS. We don't want that. We want people to— the reason, and if you, any of you listening, go to your PlanetScale database now, if you create a branch, you get a dropdown to place that branch wherever you want in our region map. That's so that you can do local development. You may be hosting in Ashburn, or, but if you live in San Francisco, you can create the branch near like on the West Coast, so you can get lower latency to that development branch and do development against it.

That's actually really exciting to hear. I know one of our developers who isn't on California West Coast is the one person who, to be fair, she was flying and wanted to be able to do dev on the airplane. She made a local MySQL install for the first time since joining the company that we're fully bought in on MySQL. She was the first developer to actually install MySQL on her machine.

Wow.

And after doing that, she was having not a lot better, but enough of a better experience just due to how much lower the latency was on her local DB that she started using that more for dev than the PlanetScale branches. I did not know that we could make those in other regions. I'm going to try and convince her to give that a shot and see if I can get her back on the—

Yeah, there we go. On the cloud gig. Latency and distance between the things doing other things is so important. That's why it irks me so much that other database providers pretend that it's not a real thing.

Yeah, I totally agree. And I've been— I'm surprised that you guys haven't— like, it wasn't so much that you were pretending it wasn't a real thing, but it didn't seem like a point of concern with the additional wins. And like, something I've seen a lot of is the claim that moving everything to the edge is going to make the internet so much faster. How is authing my user at the edge going to be any faster than authing the user at or in West 2 if the user has to be authed against my database that's already in West 2? You just added an extra round trip.

Right. I think the inconvenient thing for people to truly realize is that once you've terminated SSL near the user, You've probably made 60 to 70% of the optimization you'll ever get from doing stuff near the edge. Yep. We get— we made GitHub ridiculously quick for people all around the world by just hosting in Ashburn. We had Git Active/Active across the world, but across Seattle and Ashburn, but primarily served out of Ashburn, but with PoPs everywhere. that terminated SSL near users and backhauled the traffic. That's, I mean, that's most of it. That's a lot of round tripping saved, and you can do loads more. But, you know, I think like databases trying to get out to the edge ruthlessly for anything other than reads gets very, very, very complicated and probably is not worth the downsides.

Totally agree. And I've not personally felt the pain, but I've had engineers that worked with me fix the things I broke because I had a counter and run into all of these problems in that process. And all of those end up being reasons that we're not focused on our users and we're not shipping. I think if there's any point I want everyone here to take home, it's that while PlanetScale is doing these crazy technical things, that's not their focus. That's their solution to solve the problem of the developer experience building against databases. And I think that's what I love so much about you is there are a few companies that know what they're doing so much and don't talk about it, if that makes sense.

Yeah.

It's not that you want to hide the crazy stuff you're doing, it's that you don't want us to, to feel like that's what you're doing. You want us to just use it. Same with the iPhone. I think that's the perfect comparison for how PlanetScale's building versus other people in the space. When I think of other scaled SQL providers, especially in the Postgres side, I go to their marketing page and there's 26 words I don't know the definitions of, and I've been a developer for over a decade. Where I go to the PlanetScale site, it's like, oh, this is how this benefits me.

Yeah, right. I'm so glad you've seen that because we try very hard to do that and it is hard. Sometimes it's It's actually agonizing. Like, it's sometimes you wish you could just fraud the pain on and just be like, oh, well, see our docs for a load of caveats, but we just, we won't do it. We try really hard and it takes a lot longer to do it, but it's great.

But on top of that, when things don't work, you don't hide from that either. Alex actually mentioned earlier, one of his favorite things about PlanetScale and about your team is You guys don't pretend things are working when they're not, and you listen when people push back on stuff. That's one of my big things. I, I'm an asshole. I will complain about every single thing that goes wrong quite loudly and quite often. I think that's why we work so well, is I can't even finish my complaint before y'all are on it.

That's great to hear. Yeah, you have to celebrate your losses as loudly as your wins. Otherwise, you create this weird echo chamber for yourself, and you're like, It's very easy when you're building a product that's growing, right? And, you know, I read our support issues as much as I read the tweets that praise us, right? Like, it's— our Twitter channel is great fun. We get people all day long like, oh, I love PlanetScale. I've just built this thing on PlanetScale. This is my new stack. Like, love it. Also got to work out the problems. And we have got to know the problems. We've got to, like, we've got to be more unsatisfied with our product than anyone else can be. And that's how we'll make it good. If we do victory laps constantly and say it's amazing, then it will get worse over time. You've got to be unrelenting and hold that really high standard.

Couldn't agree more. It's been 2 hours. It's been an awesome show. So I want to start wrapping up. There was one question that Mohamed had I wanted to clear up quick, which was, wouldn't developers have access to production data in preview builds if we were to move to a world where preview builds are automatically creating branches? I'm sure you have the answer even quicker than me.

Yeah, so data branching is close and coming. You will be able to specify having data in your branch or not and watch this space for a nice solution to anything further. At the moment, that is a problem. Yep, that is an issue. Hopefully that's something we can get to in the future, making it way easier for customers.

Interesting. I was gonna flip it the other way, which is one of my favorite things about PlanetScale is that their default is no data comes, when you make a new branch. So the default experience that would exist right now if I automated this would be no production data in preview builds because it's a fresh database instance. With the exact same schema, though.

Right, exactly. And I think the best way is most people do it without data. And that's the default. And it's much quicker to provision. Also, you should be seeding. Like seed data, good quality seed data. It's way better. And you shouldn't test on— you should never be testing on prod data, basically. Like, if it's your little— if it's your own blog, I mean, it doesn't matter. But like, if you get into that bad habit, believe me, when you grow up and like the, the other issues it causes is way worse.

If you're using SQL on your own blog, I want to have a whole separate conversation with you. That's an aside. As a big Markdown fan, you're—

Well, I mean, WordPress is still going, right? And They're friends hand in hand with MySQL.

That is fair. Oh yeah, this has been absolutely awesome. Thank you so much for taking the time, Sam. Means a lot both as like a user and a content creator to know that you guys will have these hard conversations and not back away from anything. Just for full transparency for the audience, I tend to send a heads up ahead of time to any guest I'm going to have with like a bunch of questions and things that I want to ask. I even will label a section saying like, these are the hard questions. questions. I expect you to nope out of some of these. Sam's response was, I'm so excited to talk about all of this. So I wanted to emphasize that point. I think it's so cool to have a company solving these hard problems that is not trying to avoid the hard questions that often come with it. So thank you so much, Sam. We appreciate it immensely.

Thank you so much for having me, Theo. Thank you for being a user of PlanetScale. Thank you so much to your audience for having me and listening to me. planetscale.com. if you want to try the next generation of database. And, you know, my Twitter has been linked in the chat. You know where I am if you have feedback. Yeah, thank you so much for having me. It's great.

Absolutely. I'm going to end it now. Quick heads up for the usual people. I have a big announcement coming, more Ping-related than anything tomorrow. So be on the lookout for that. I'll probably announce it on Twitter. Might put some things other places. Keep an eye out for that. And on Friday, my 2 co-founders, @pinglabs. Mark and Brynn will both be streaming live doing a, a, uh, how do they put it? It was, uh, keep talking and every— and nobody explodes, except repairing a Game Boy, where Brynn cannot look up anything about Game Boys or Game Boy repair whatsoever, and Mark's going to instruct her through it remotely on Ping. So if you're curious about hardware stuff, that should be a really fun stream too. Thanks again everybody for stopping in for this one. This has been an awesome show. I'll see y'all next week. Peace. Peace.