Sam Lambert, CEO of PlanetScale: databases that never go down | Evil Martians podcast

Sam Lambert, CEO of PlanetScale, explains how his MySQL and Postgres databases stayed online during AWS's massive US-East-1 outage. He describes the company's fault-tolerance strategy, competition with Supabase, and why AI-generated code creates cheap databases while PlanetScale targets always-on, high-load workloads.
Chapters
Hi everyone. Welcome to Dev Propulsion Labs, our podcast about the business of developer tools. My name is Victoria Melnikova. I'm the head of new business at Evil Martians, and today I'm very excited to introduce our guest, Sam Lambert, CEO at PlanetScale.
Hi, how's it going?
How is it going for you?
Good. I don't know when this is going out, but we are recording this in the afternoon after sort of a 12-hour AWS US-East-1 incident where thousands, maybe millions of websites have been offline. So I've been sleeping on and off since midnight. I got paged at midnight last night with this incident. Luckily, touch wood, it's been completely fine for our customers and clusters, but it's been a fun day today, I would say.
So I'm watching Silicon Valley for the first time ever, right? And as you know, Piper made a bet on metal. So they built their own infrastructure in their garage. And I'm like, how funny is that, that today I'm interviewing Sam and we're talking about metal.
It's too weird.
So tell me about this bet on metal. Like, did you ever envision Today's day, like, was it all building up to this moment? Is it your star hour?
We still run in AWS, so our metal machines are still inside Amazon. So a lot of— there are folks with like metal products that run outside of the cloud in their own infrastructure. And you're seeing from Twitter today, a lot of people are very excited about running their own infrastructure. What we do differently is obviously have it inside Amazon. The best thing about today for us, I think, was how resilient our software was throughout all of this. And that was really less about metal and more about dedication to extreme fault tolerance. There's a post out there by us that talks about our rules for extreme fault tolerance. And this kind of played out today with this incident going pretty nice for us and outstripping a lot of other services' availability, which was good.
So for you, was this decision kind of like the PlanetScale's moat? Or was it just like a wild bet? Maybe one day this will pay off.
It's part of our moat, I think, is operational maturity. Someone asked me about this today. They were like, wow, I mean, it's pretty amazing that you've been able to like just stay up and go through all of this. And I said, yeah, I mean, it shows like the day the marketing pays off. You have to have days like this to show that you actually are resilient. So it does feel good, but at the same time, These types of things are so rare. Most people are going to go back tomorrow, and hopefully not many people will change too much of their behavior. Hopefully they're not going to start doing crazy multi-cloud, multi-region things. The fact that today was so extraordinary is because it doesn't happen often. It doesn't really go on much. For me, the thing that I think is more of a moat of PlanetScale is that the constant reliability in an environment that is obviously very hostile, which is the cloud, and the scale we run at, and the amount of machines that we deploy, always having a kind of constant replacement, always being very, very resilient and reliable is something we're proud of. It's what we do. Our job is to keep these large brands online, these large customers that depend on their databases. That's what we're here for. We call ourselves like a tier zero database, 'cause—
Mm-hmm.
How critical our infrastructure is to the world.
It's interesting. And you are betting on guys that are growing, right? And sharding is part of that philosophy and the only way to make it happen for big, big guys. And recently you also added Postgres offering to your, to your, you know, to PlanetScale services. So where do you find yourself today? Like, who is your ideal customer? Is it— Like enterprise that, or is it startups that are growing crazy fast, kind of like Warp?
But it's both actually. So we, I think a lot of people think we're for enterprise only and forget that, you know, you can just, thousands, if not hundreds of thousands of people have started their companies just choosing PlanetScale straight away. Like the entry price is like $34. So it's not very expensive. And you get like a ton for that, right? You get a high availability setup that you don't have to try and configure and mess around with yourself. But some people think, you know, we're just truly for large databases and enterprises. That's just not true. We need to generally try and do a better job of that, 'cause we talk about scale, we talk about scalability, talk about some of our large customers, and people look at that and go, well, we're not there, it doesn't matter. But generally, anyone that wants high availability, uptime, and performance from their database, which I think is most companies once they get to a level of seriousness, that is who we're for.
Mm-hmm.
Postgres though, we've seen a lot more skewed towards startups. There, you know, we're seeing some large Postgres deployments out there, but nowhere near the amount and the scale of the MySQL deployments that we have. But in terms of diversity of customer base, that's where Postgres is, because that product has been GA for— it's our 3rd week GA, and it's growing incredibly, just incredibly quickly in terms of revenue and customer base, which is really amazing to see.
Yeah.
And that comes from lots of smaller customers. So Vitesse is our MySQL shilling product. We are building Vitesse for Postgres, which is Naaki. That's coming at some point next year. It's going very, very quickly. We have customers migrating to us now, ready to be ready for NAKEY. And that will then be even better for unlocking scalability for the Postgres world.
You're kind of dragging me into the hot topic of Multigress. So I was just at Supabase Select the, you know, the other week, and they announced Multigress, which is built by Sugu, the creator of Vitess, one of the creators, one of the authors. Do you think that that competition is good for you? It means that there is a big market, or what are your general, like, what's your general sentiment on that?
I don't think it's neither good nor bad. Sugu left the project 4 years ago, left PlanetScale 4 years ago. 4 years ago, Vitess had maybe 15 large users. That was it. The user base for Vitess in the last 4 years has grown by 61,000%. So huge change. What Vitesse is today is a culmination of hundreds of engineers' work going into the project over time, all of the learnings that we've gained in production. And we are still the Vitesse maintainers. 9 out of the 10 maintainers for Vitesse work for PlanetScale. The other one works at Nozzle. So yeah, I mean, founding something and being part of that is one thing, but Vitesse is far past what it used to be. It's an evolving thing. And really, it comes down to hosting it in the cloud. You know, we are the only kind of company outside of Amazon that hosts anywhere close to the size of workloads that they do. In fact, some of the largest that run on— like, so their largest Aurora Limitless customer migrated from that to Vitesse.
Mm-hmm.
So you can have an open source project that's a copy of Vitesse. Nike's architecture is not a copy of Vitesse. It takes heavy inspiration. That's one way it diverges. We wouldn't just copy Vitess. Vitess was built for MySQL, and the architecture's better. It's actually like, some of the things that we've decided for Na'ki are actually gonna get backported to Vitess. Vitess has been around a long time. It was built at YouTube. We spent 4 years bringing it into the hands of so many more people. We've learned a lot of things.
Mm-hmm.
So those learnings will go back into Na'ki. The competition's not really relevant. You know what I mean? There's nothing to learn from it. They're not taking any approaches that we would take. It's from, you know, a 4-year-old version of Vitesse is not necessarily gonna be the same as what we would build today. And we're building it, and we are serving queries from it right now. It's going into prod. So yeah, I don't really think about it. You just have to stay in your own lane.
Yeah.
We've proven that our ability to operate is completely unrivaled by any company. Whether or not there was 1,000 Multigresses or Nakis out there, it really comes down to who's gonna host those workloads. I don't see any competition for PlanetScale in that world from anybody, anybody at all.
I'm also curious about the future of PlanetScale. So when it comes to, let's say, MySQL and Postgres offering, how do you see that ratio, like in, let's say, 5 years? You know, when some of your customers grow up a little bit and they become those like hefty databases? What do you think?
I think we will probably see more customers by number using Postgres, just because it's kind of the default database now for startups. And none of them get like massive, like there's just this giant power law to all of tech. Whereas I think, you'll still see the overwhelming data and query volume being among the Vitesse customers. When I say it's a power law, we have single clusters on PlanetScale that will do a lot more QPS than any of the other Postgres providers total for their entire platform. We are talking about, when people talk about scale, I don't think people will truly understand what scale means. And I was going into some talk conversation in DM with someone on Twitter recently that, was talking about scale, and I kind of asked them to guess some numbers, like, what do you think we think a large cluster is? And they were like, I don't know, 100 replicas. I was like, thousands and thousands of replicas in a single cluster. So yeah, I mean, long way of answering that is essentially, I think the majority of the scale will be among Vitesse, with Postgres and Na'Vi rapidly changing that over time. But within the 5-year scale, I think you'd still see the majority of QPS and storage with Vitesse, and then lots of smaller companies. And it's how it's looking like now. Like we're just seeing just a crazy amount of signups for the Postgres product. None of them are just gigantic.
Yeah.
Because it's where Postgres is right now.
Yeah.
It's just how it is. I mean, MySQL was in this position at the beginning of the '10s, and that's why MySQL is where it is today, is because it was the chosen database of that era. It no longer is as the default, although Huge websites run on it. Pretty much all of the top 100 of the internet runs on it. And when you look at the scale of even the top 10, we're talking millions of servers behind every one of those websites. It's going to take a long while for that to change. And Postgres is going to go into that era now with AI, and it's going to get better.
Yeah.
And there's companies like us that are operating, bringing our perspectives from running at that sort of scale. And so I think Postgres is going to go through this wonderful kind of maturation from the ecosystem and from the technology itself. And back when I went to the San Francisco MySQL user group in, say, 2013, you'd have Google, Twitter, GitHub, Facebook, Yelp, Box, all these companies coming together, and they were still young companies. They were small in comparison to where they are today.
Mm-hmm.
And by them adopting those technologies and us all working together to improve the ecosystem, MySQL got significantly better. And most importantly, the tooling around MySQL got significantly better. We're about to enter that age for Postgres, I think.
Mm-hmm.
And there's a lot to mature and it'll be great to see.
A big portion of those users that are using Postgres right now are vibe coders. The other day you actually posted something like, oh, you can't actually vibe code the infra for, you know, database infra. How do you think that, like, CodeGen and vibe coding, how are they changing the way the tooling is being served, the way the tooling is being built, particularly when we talk about databases?
So firstly, I'll say I love AI coding. It's great. I mean, I spend a significant portion of my time doing it. We use tons of AI at PlanetScale. But it's humans guiding that process, right? Like, it's humans with their intent, the designs, and what they want to build. That's different to vibe coding. For me, vibe coding is just talking to an agent, going through, and you don't really care about, like, what is the quality of what it's coming out with. Like, in the last year, I've created more websites than I probably have in the rest of my career. That's like vibe coding. I suck at making websites. Like, I'm not making really seriously informed choices. These are also just not production-grade apps. They're things for demos or—
Mm-hmm.
Small marketing sites where it just doesn't matter so much. That's vibe coding. I think there's value to that. I think it's massively overhyped by certain vibe coding companies that are just kind of pretending essentially that you can just type in, make me this business, and it just like produces something. I just— that's just not true. That has not happened. There'll be certain small cases, but there's going to be some fun in that area when this kind of comes in. You know, there's these high churn rates for all these And so that, as vibecoding, the impact that's had on database infrastructure has been very little, except people are optimizing towards building databases that are designed to turn off or be very cheap to run. Again, it's like the power law of, you know, we know from speaking to people at these companies that support the infrastructure behind a lot of vibecoding is that within the first hour of a database being used, it will never get used again. So you're seeing these incredible user growth, numbers for companies, but the retention is abysmal because it's just not— they're not necessary. They're created on a branch of an experiment. It creates a database. So those databases better be cheap to run and cheap to switch off and cheap to stay at rest. None of those things are anything we're interested in. Our database is designed to be cost-effective, running 24/7, 365, under extreme load constantly. There is just no off time for some of these global applications. And so it's a completely different set of constraints.
Mm-hmm.
We would not make the optimizations to be easily switched off or be cheap, cheap to run. We want to be cost-effective, obviously, but like cheap in the sense that it can just power down and do nothing. Like, that's fine. Single-use databases are great. I don't even understand why people use Postgres for that. I think you should probably just use SQLite, but whatever, people can do what they want. It's a weird era in tech, but I think a lot of that's going to pass. I don't think it really relates to real production professional databases in any, in any way. Lots of hype though. Lots of noise.
So you understand a lot about dev tools. You invest in dev tools, and some of the dev tools that you invest in are loved by people, right? And we're talking like Railway, Graphite, right? What are some others that you—
Fly.
Fly.io is awesome.
Some of those are more infrastructure providers than dev tools. Yeah, but dev tools is a really interesting space. It's a very difficult space. I think it's very, very hard. I've watched friends of mine in the purely dev tool space go through it, and it's really, really tough.
Yeah.
PowerScale's not a dev tool, right? It's an infrastructure provider. But I also worked on— it's an infrastructure provider, it's GitHub, but it's probably considered among the dev tools community as being one of the greatest. in terms of not just the scale we took it to, like we pulled together a community of 100 million people, but also how beautiful that product was. I think if you look around the industry now, you look at some of the earliest things that were, you know, are now accepted in the industry, they were pioneered by GitHub. So it was great to be part of that and see it. It's a great space to be in, but it's a hard space to be in, right?
Yeah.
We see continually that you can provide dev tools that even just exist on every single person's laptop. Monetizing that into a business is extremely difficult. That's why I've always wanted to stay in consumption. The thing we charge people for is mapped to them using our product more, and it's infrastructure. We provision servers for you, they stay on at a certain amount of time, they have a cost to us, we have margin on top, and we charge you for that. That's very pure. DevTools is harder to monetize in that sense. The way the value maps is not always as clean or easy.
What do you think makes a successful dev tool founder?
Taste, intuition, the ability to intuit what communities want and to market that to those communities. Developers are very tribal. People don't like to— a lot of people think software engineers, we're the most objective buyers that are out there. We're making it purely on technical criteria. That's not true. People, you know, it comes down to brand, the chosen language they like. Like, look at just the wars and the arguments I get into these about MySQL and Postgres. Ultimately, it doesn't matter for all intents. Like, you know, we're experiencing this right now, right? I'm, you know, midway through a very long blog post about the difference between Postgres and MySQL replication, MySQL being significantly better.
Yeah.
It doesn't matter. People don't really care. I mean, they choose Postgres. The cloud providers take care of that for them. So, It's just lessons in how we're not always cold and calculating when we pick things. We pick them because of the brand we like, the way they make us feel, and that's fine. But you have to encapsulate all of that if you're going to be a dev tool founder. People are just not reading papers and benchmarks all the time to just find the right tool.
Yeah.
It's often what community they're part of, how quickly they can get building, how quickly they can get going. There's amazing tech in the Java ecosystem, and people see new companies like adopting this style of doing stuff. And like, the Java community, like, hang on, we've been doing this for years. Yeah, again, no one cares. Like, it's just, it just depends on the generation you're in. And so a DevTools founder has to be very good at intuiting what communities want, understanding that it's relevant to their community, and that they can be successful that way.
How long does it take you to kind of evaluate whether an idea or a founder has potential to grow into something like a big product? Is that something that takes time?
Like, for certain things it can. For certain, you can see that the person, the founder, the idea is so compelling and that they will just will it into existence. First time I met Guillermo from Versace, it's just like, you just know. He knows his audience. He understands branding. He understands that that has an inordinate impact on his community. And so he— I just knew he would make something huge. And he has. He's done it twice now. v0, again, just his intuition towards creating brands and products. He knew it had to be a separate brand. It has the— it's the perfect name, like everything. There's just certain people that just, they get it and they fully understand it. And the GitHub founders were exactly the same. They just understood their community. Multiple great products and communities came out of Ruby in those days. Like Ruby was the thing when GitHub was created. DevOps came out of the Ruby community too, and so did GitHub. GitHub is so uniquely a Ruby product, it's just unreal. That was a different generation of folks that really cared about developer experience. That was the kind of early discussions around developer experience. Ruby was a language that traded off performance for the experience of writing it. You had to— it was there to be enjoyed. The founders insisted on GitHub having very good technical writing.
Mm-hmm.
There was a GitHub voice that you were trained in when you joined. All of these things were intangible things, They created a greater sum of the parts of caring about taste, interactions, and all of these things. And it wasn't talked about as DevEx then. It was just talked about as obvious and things that you just should do anyway when building a product that people love. And it just came from that. And so it really is about a place. It's often about time and place for certain communities and the things they want to do or that resonates for them.
Do you think it's possible to maintain and stay at that level of excellence as the product grows? Let's say with GitHub now that, I don't know, let's say all the engineers in the world are using GitHub, right? Do you feel that their level of developer experience and product excellence is still there or inevitably with scale? You have to compromise that?
I don't think you have to compromise it. Maybe it has been compromised, though. I don't know. I think it's difficult when you're building for a very large user base, connecting to a lot of different products. It's not impossible. You know, it's still flourishing and still the default for every single developer on Earth. We're now entering a new era. They've been great stewards of that era. They brought AI coding to people early, if not first, with Copilot. That's an incredible thing that Microsoft did for GitHub, VS Code, all of these things. It's impressive at the scale they've done this. And not just the scale of the website, the scale of the organization as well. It's hard to get things done inside big companies. They're clearly listening. I think as long as The CEO, the founder, the people that are involved still care about what made the product successful and still understand it. Yeah, you can be fine.
Let's talk about you for a second. There is this whole thing about San Francisco, and we can talk about that for a second because I'm one of those people that had a very rough first experience in San Francisco. Like, I didn't like it at all. But when I moved here with my daughter, who was just 1, I had the best experience, you know. So now when I hear a lot of like hot debate that San Francisco is not great for a family or, you know, whatever it is, like there is no work-life balance here, I actually don't believe it because I have a very different experience, you know. And I understand that it's kind of like almost my responsibility to make the city work for me, you know, because it's a big city. You can choose very different lifestyles here. Let's quickly talk about your stance on San Francisco, just because I know that you are a fan.
I love San Francisco. I also know why it wouldn't be for everybody, but I personally do love it. I think the issues of San Francisco are very visceral. They're very visually disturbing. And I don't think anyone wants to be cold or uncaring to these issues. I think there's also, without getting too political, there's a number of issues that are Just down to corruption and problems generally in that area, which makes it feel arbitrary or makes it feel— it's like an own goal. Like, it's not necessary to have these issues. Now, I would agree with that. I'm from the UK. I'm now an American citizen. I'm a proud American citizen. And I'm proud because of the opportunities this country gave me. I don't think I could do what I do now anywhere else. And certainly San Francisco, if you're CEO in tech, it's the place to be, right? It's where your customers are. I took a short Uber ride over to here to do this recording, and I would go back. It's a really amazing place to be. And no matter where you work remotely, at least the leadership team of your company has to come here and do sales or have a satellite office. So it's one, just very, very important to tech. And I think that might lead into some of the dislike people have, which is If you don't like it here, you may feel forced to be here. Or as if it gets an unnatural level of praise for what it is.
Yeah.
When those problems and issues are so severe. And it is viscerally terrible. And I mean, all of the hotels are in the area of the town that are just horrible. People really are suffering. On the other side, when you live out in the neighborhoods where the residents live, this is where it becomes this kind of—
Yes.
You don't see any of this. You live in a really nice, actually, suburban. Before I was doing a lot of business stuff, when I was just doing engineering, I never went downtown. Sometimes you spend a whole year and go twice, right? So you just don't see this stuff.
Yeah.
You could live out in the neighborhoods and have a lovely time, and there's beautiful parks, and the weather's okay. It's not the best. LA weather would be nicer. I would swap that for sure. But there is a lot of good here. You just don't get to see it if you stay here from Monday to Friday in the center of the city, and you miss it.
Do you feel like there is like a good era starting? I feel like there is a lot of like great energy in San Francisco right now. So I only moved here in March, and since March I see that there are a lot of events, many more than 2 years ago when I visited for the first time.
Yeah.
A lot of people are trying to move here, and I see that on Twitter everywhere. You know, there is like a lot of excitement around AI, obviously, and As you said, for young founders, it's almost like the only chance to make it with AI. You have to come here and you have to be here physically and network with other founders and network with VCs and do all of that legwork here on the ground. So I actually feel like it's getting better.
I would say things are definitely improving. It's improving in multiple ways. So we have a different mayor. He seems to be more engaged in improving things. So people do comment that It is cleaning up. Recently, someone came by to visit the office that used to live here 3 or 4 years ago and said, wow, it's definitely improving in that regard. It was pretty dark during COVID I did worry. It was very dead. It was scarily dead. Now and then I would take a trip to New York, and New York felt like it had bounced back so quickly, and everyone was having a great time, and San Francisco still felt very quiet and very dead. That, I think, we're moving out of. It does feel more like when I moved here. I moved here in 2015, but I was coming here all the time from 2013 when I joined GitHub. And tech is very all-consuming. That's the problem with tech is your competitor is likely obsessed with what they're doing.
Yeah.
And their job means they can be online constantly. Like, I work 7 days a week in some form. It's not all day, every day, on weekends, but I can move things forward. I can talk to customers, I can write, I can talk to other employees and do things on the weekend. And so when you are almost having to do that level of obsession, then moving to a place where there's lots of other obsessed people is really beneficial. You can go on a hike with people that care about tech. You can go meet folks at networking events. And when you're young, you should. I mean, socializing and meeting people when you're young is difficult. I'm thankfully no longer young in that regard, actually. But when you're in that period, your 20s, you know what it's like. You're insecure.
You're— Yeah.
It's difficult. Yeah, it is. Social media, I think, makes that way worse. But connecting with people, seeing people, I try and talk to folks that are newer in the industry or they're building things and try and chat with them. And this is a place to make that really easy. So I think SF is going to stay strong for that. It's very hard to unseat those places. Our office is in South Park, and I always joke there's ley lines under South Park that have the magic for creating startups. You can look out, There's the building where Square was founded, where Twitter started, where all these things— it's these sedimentary layers. Nat Friedman's always used to talk about the sedimentary layers that tech is built on, and I believe in that. Those sedimentary layers, the fact you can go and talk to— I guess I'm old guard now, but then there's an old guard of folks that I used to talk to about the first dot-com era while we were building Git. You know what I mean? You just get to speak to people. And the thing I love about tech is people always pass it down. People seem to really want to help the newer generations. And when that's all in one place or very close to being in one place, then it's very special and it's hard to beat.
So it brings me to the point of my hat. This is actually a very special hat and I want to tell the story because when I just moved to SF, which was in March, I went to one of the meetups, which was at PlanetScale. And this was the first hat I got in San Francisco, you know, since I moved. It's my special hat. I wear it all the time. Like you can see me in Pack Heights wearing this hat because it's just my go-to hat. And when we agreed to, you know, to to do this interview, I'm like super excited because I can finally wear my hat to the interview.
You know, and it's you preserved it very well. It's in great condition.
You know, I sweat a lot in it because you know Pack Heights has a lot of hills.
You know, thank you.
Well, but thank yeah. I take good care of it. So the community around PlanetScale, you know, you do a lot of events, you do some educational events about migrations and things like that. What do you think is the most valuable resource for your users? Like what helps people convert? And let me expand on this a little bit. Database is such a sticky product. Like if you choose a database, you're committed to it for—
Yeah.
It's very painful to migrate, right? So that decision early on, you know, it's risky. Like you have to weigh different options. You have to think about pricing. You have to think about scale, like a lot of different things. And what do you think really moves the needle for your customers? Like how, like what is that spot that you can bring them relief on, you know, so they feel like you de-risked this deal for them?
The magic phrase we hear from people is, I just don't wanna think about my database anymore. Now, that is a goal that's tough, because your application is often the reason the database is not always optimal, right? Like, it depends. The thing I'm proud about with our uptime and the results we give for our customers is it's not just that we have a service, it's a service where we don't control the client. And so I've worked, when I was at GitHub, we had control of the client. The problem was always coming from inside the house, usually, right? there's some rogue query or something in the app, and we had control of the app. We don't have control of people's apps. We can make recommendations, and they follow our recommendations. Luckily, they know we're the experts, and we can talk about those things. But some people get into these conditions where it's very, very tough. Really, it's when people want to hand off the daily opera— nothing sits still in databases. If you are at a company that's growing, the database load, all of these things, is just a moving target continually, and you want to rapidly develop your product. especially in a world that's as frenetic and moving as quickly as it is today. So you need to keep ahead of operations. It's like this constant gardening that has to be done.
Mm-hmm.
And that's where managed services are really powerful. And that's why we have this managed service. And the kind of it being a product, the kind of rising tide raises things for all boats. So we implement a feature for one customer, it has a tail impact for other customers. It's great. And so we are constantly thinking with our, you know, with our team how to improve our database product. and manage its resilience. And when companies onboard, that's huge for them. That takes tons of problems away. Today, during this US East 1 apocalypse, I tweeted the picture of the status page of one of the largest consumer apps in America that runs on PlanetScale, all green. And I'm sure they feel good. We feel good. It's nice. It's a customer outcome that I care about. But really, it's about when people need to have something be reliable or scale or be usable. And a lot of the time it is migrations in. We see a lot of people that run out of steam on RDS or Aurora and run out of scalability there and have to migrate. Because of this, we've sort of picked an area of the market that's the hardest to serve.
Yeah.
Because they come to you with a real business. Downtime is not an option for them. Migrating has to be done online. They have to test, they have to do all these things. So we go through these really long, migrations for certain customers where we have to do multi-region testing, game days, we have to make sure we have capacity. People are spinning up thousands of nodes at a time just to serve a peak or all these things. We have to have answers for doing all this stuff. So it takes a lot of coordination with customers. That said, the easiest time to move your database is now if your business is growing. And that's why having products that address the bottom end of the market, they're really important to us. And that's why we try and make it easy to onboard. So we're in a situation where we're helping some customers, Postgres customers, very large ones moving out of like Google, for example. Their source cluster is now so contended that even getting the replication and data out is very painful.
Yeah.
And we've, like, we're public with this, we've joined customers with WAP, right?
Yes.
They are just this, phenomenal company of just— when I went to visit their offices, it was like, yes, this is exactly what it was like to be in every early company I've ever been at. It's just this young team of—
It's infectious.
It's infectious. They know their audience so well. They are genius marketers, absolute genius. And then they suffered from all that success with database problems, and you get very stuck. The database becomes fragile, then migrating out of the database becomes fragile. And that was an operation we had to do very quickly with them. to get them out of that. And that's obviously a situation that was very painful and can be avoidable for most companies if they think to themselves, well, we're pre-launch or we haven't been launched long. Let's get off of a previous provider that's not doing so well and move to something like PlanetScale. Another one is Kick.com, right? You see their graphics all over all the sports events and whatever. I remember when they signed up and I remember I'd seen some controversy because they were migrating streamers and folks. onto their platform. And I remember they just signed up and created a net new database with the Kick app was just brand new against PlanetScale. It was awesome. They were just from day one, like their first, they paid like their first bill was just tiny on their credit card. And now their business has grown and become so successful that they're in every sporting event I turn on, I see their logo and I'm like, oh yeah, I remember the day you created, like you had some foresight to think, you know, we are gonna build something successful. So we're going to bet on ourselves. We're going to put it on a platform that we know has so much more runway for us, which is PlanetScale. And they've grown. And now, you know, they were having an event this weekend and I just kind of checked in and saw, and it just, the traffic volume compared to where they started is immense. And the fact that they've not run into all those painful database issues that stopped them innovating has meant that their business can continue to scale really well. Their customer base is happy and they grow. This is great. It's a lovely success.
That's so interesting. You know, a lot of technical founders fall into this trap of overthinking scale, like very early on. They already envision how they're going to be scaling, but it's not like they haven't found product-market fit yet, you know, so it's too early. And PlanetScale actually comes in nicely because it can scale with you, right? Like you don't have to think about, oh, like what will I have to change to actually enable the scale later on?
Yeah, there's a lot of over-engineering that happens. I rail against this on Twitter all day long. Like, I can't stand it. You know, people with 50 microservices and this and, you know, at the end of the day, we're just asking you to speak to a MySQL database or a Postgres database, not asking you to shard upfront. That comes later.
Yeah.
Last week I was at Cloudflare Connect where I resharded a database live just to show people like, yeah, it used to be scary. 10 years ago, it used to be hell. A really hard thing to do. Now it's easy-ish. But from day one, you'll just connect to a Postgres, just Postgres, it just works. And then, God forbid, knock on wood, if your business takes off, we're there for you. You've got it locked in. We can take you to scale if you want to be the next Cash App, you want to be the next Intercom, Cursor, whatever, whoever runs on PlanetScale. I mean, we'll be there.
I also had a question about your personal journey. So you joined PlanetScale as a CPO, right? And just in a few months, you took over as a CEO. Can you just give a bit more context to what happened? What was it that made you such a good fit for this role?
Well, it remains to be seen if I am. That gets measured in decades or more. But I knew of PlanetScale, and I was an advisor to the company before I joined. And I knew of them because GitHub used Vitess. Back then, 4 years ago, Vitess was an immensely incredible technology, but it was a very niche technology. PowerScale was basically a consultancy that had support customers like Slack and Bloomberg and folks like that that run Vitesse on-prem. And that was it, really. It was not really a tech business. It was more of a consultancy. It wasn't a tech product. And there's obviously no future to just doing that if you want to build and you've taken venture capital money to go and build a platform.
Yeah.
you need a platform, you need cloud consumption.
Yeah.
That's for sure. And now I remember Vitess being so good at GitHub. It did exactly what it needed for us, but we were at scale. We had lots of engineers dedicated to it. When I joined, Vitess was not broadly compatible with any frameworks. You couldn't spin Rails up against it. You couldn't spin up any major framework. So I joined because I saw the opportunity to turn PlanetScale into a cloud platform that would endure and bring Vitesse and the best of Vitesse to a mass audience. So that's what I came to do. And so I joined as CPO, took over engineering, took over the product team, and started to build a product, a cloud product, right?
Mm-hmm.
We then set about modifying Vitesse to be much more compatible, and the Vitesse team did an incredible job. going from very little compatibility with all of the frameworks to almost full compatibility. So we now have testing against all the major frameworks, CI tests, to make sure that when we push changes to Vitess, it becomes— it stays compatible and performant for the app. So that widened the aperture for how many companies could go and adopt PlanetScale significantly. And like I said, the user base for Vitess has grown 61,000%.
Wow.
So it's gone from maybe 10 to 20 hyperscale companies using it on-prem to now hundreds of thousands of users that use Vitesse. Some don't even realize, they think they're just talking to MySQL. And we then coupled that with a lot of operational excellence. So a bunch of folks joined from companies like GitHub on a very large scale.
Wow.
And so it's not just a technology, it's the running of that technology in a way that can can be trusted. So the old version of the product, the old version of the cloud product before I joined, had about 750 users total when it was shut down. We gained more than double that in the first day of announcing the beta of our new product, and things really took off. And so it was kind of thought, well, it's clear why this is happening. Maybe if we can put all the wood behind the arrow and Sam just runs things how they are, it would work. And like I said, we don't know until the very end, but It seems to be working, and I'm very proud of what we've done. I'm proud of the Vitess team. They took a project that was Googleware and not very applicable, and it's now applicable and behind so many companies. It's just a crazy experience to walk around. And we had the Vitess team in town recently, and we were just all talking about this. And I gave them a really heartfelt thank you because the work they do to run an open-source project that impacts so many people, it's really tough. I mean, every working adult in America interacts with our software constantly. It's just amazing. Some of my favorite products run on PlanetScale and you forget, every Slack message you send goes into Vitesse cluster. It's wild, right? Every Cash App transaction. It's an amazing feeling. And that team from those early days have really turned Vitesse into this incredibly broadly used product. And I'm very, very proud of them.
So I always end my interviews with this question that I called a warm fuzzies question. And it's about, basically it sounds like this. What makes you feel great about what you're doing right now?
I get to wake up and log online and talk to 60 people that I find inspiring and challenging, and they are smart, kind, funny. And we control our own destiny. We have a profitable company that supports incredible businesses that is continuing to grow and is growing very rapidly now. And I'm doing it with people I just like. And that to me is just— I just feel like the luckiest person in the world. Like, they're so funny and so sweet and so intelligent and so caring about the customers that we have. I just feel lucky. That's it. And it also is the same with customers. Databases are very difficult and they're one of the most challenging parts of technology. They're also just databases. When you see the products that get built on top, I get really hyped up about our customers. When I see them launch or raise or do anything, really anything, I'm such a hype man for our customers because I love what they do. And then you just gain this gratitude for, you just think, you trust us, And you trusted us when we were small, and you bought in early, and you're part of our success. And it's just this—it's just so special. I just feel so lucky. The ability to pick who you work with and then do it for something that you feel matters is the greatest feeling ever. And I just wake up every day hoping it never ends. And that truly is. I just love it. I—as long as I'm talking to customers, talking to our employees. And we're doing good, and their vision is, is kind of coming into fruition. I'm very happy.
Sounds great. Finally, I want to provide space for you to invite people to try PlanetScale. How can they find it? How they can start using it? Why should they consider it for their product?
Yeah, I mean, just go to planetscale.com. It's very good database technology. It's highly available. It's very fast. Backed by a team of people that care extremely deeply and are experts. If you have a database migration, you write into sales, it's very likely I'll be the first person you talk to. We have a sales team, but I'm always infinitely curious. If you bring an interesting problem or you have an interesting product, it's highly likely that I will show up and talk to you. If you write into support, I'll often reply. If you DM me with Twitter about questions, I will get back to you. So just come on board and try out, give us feedback if it doesn't work for you. You know, it really is just what I think is very good and well-operated database technology for Postgres or MySQL. And just try it or don't, whatever makes you happy.
Thanks. Thank you. Thank you, Sam, for coming. I really enjoyed this conversation. Thank you for being honest, raw, excited. Yeah, thank you for the interview.
Thank you for having me.
Thank you for catching yet another episode of Dev Propulsion Labs. We at Evil Martians transform growth-stage startups into unicorns, build developer tools, and create open-source products. If your developer tool needs help with product design, development, or SRE, visit evilmartians.com/devtools. See you in the next.










