Databases at Extreme Scale (PlanetScale CEO Sam Lambert)

The thing I've loved about AI though is that we don't really do anything differently in the world of AI. We don't even talk about it a whole load. I know there's a lot of kind of folks that claim to be like an AI database or native to AI, and AI has certainly shaped the database world, but not for the segment of it that we're in. We do, however, have a lot of AI customers because it's a kind of picks and shovels situation where they are scaling rapidly because they are immediately very successful because they're providing very successful AI products. And so they need a very scalable relational database to do that. And we've, we're known for that. So I don't think the dynamic of AI using databases has changed much for us other than clients are being written quicker. People can index our suggestions and work off of our suggestions even more quickly. But at the end of the day, you're sending SQL queries. If they're bad SQL queries on lots of data, it's gonna be really bad.

Hello everyone, and welcome to the Modern Web Podcast. I'm your host, Rob Ocel, VP of Innovation at This.Labs. Very excited to be joined today by Sam Lambert. Sam is the co-founder and CEO at PlanetScale. Sam, how are you doing?

I'm great. How are you?

I'm doing great. We are recording this in the start of the new year, 2026. Do you have any like big resolutions this year? I saw one of them was to go to Texas Roadhouse. I don't know if you've made it yet, but—

I haven't made it. I— that will be one thing I need to do, check Texas Roadhouse and Chili's this year. Yeah, no, no real big— I don't believe in big changes, so I don't do resolutions.

I don't either. I find that to be a fun icebreaker at parties around the holidays with people, is ask if they are resolutions people. I'm a theme person. I like having sort of annual themes more so than resolutions. But some people then just sort of don't believe in any of it. Like, it's just, why is this Monday different than another Monday? Yeah, some people—

I'm much more incremental in everything I do. And so like, I think it's very hard to make those large shifts, although like I've read stories of people doing it miraculously. I don't do it that way. I think, I guess I want to automate much more of my life, which I've been doing quite a bit over the holidays. So I guess I'll continue in that theme.

Awesome. Well, listen, we're going to be talking about databases at extreme scale today and at PlanetScale. And the way that I want to kick off this conversation, you know, and including the people that maybe are less familiar with the company, but one of the awesome things about PlanetScale is how it can meet people and their organizations where they are and help people do these migrations to get access to all of the hyperscaling features and capabilities that PlanetScale offers. My question that I wanted to start with is, do you have any stories, either a specific story or a general story, of a company that came to you guys at the perfect time for them? They neither waited too long to start worrying about scaling or they weren't too early to the party. What was that story of the company that just was perfect for what you guys had to offer?

Yeah, I mean, there's been so many of these. I can give examples all along the spectrum, I guess. And we can break that down. And there's times that people have waited like too long as well. And actually there's a, we've observed a difference in waiting too long and how that impacts you across the 2 technologies that we provide, MySQL/Protest and Postgres. So I can break that down. I will say, yeah, I don't think there's a bad time to ever come to PlanetScale. Like is the, is the first, and obviously I would say that now that we have a $5 plan, so you can start for $5 a month. Um, I think it makes starting right away very, very easy. Now I know a lot of people just want to go for free. I get it. I fully get it. Like I strung together a bunch of like little AI tools to build a few things, uh, over the holidays and it's like, okay, yep. Credit card comes out again for like a few bucks here, a few bucks there. And it kind of adds, I get it. It adds up. But you know, if you are building a business and a company, um, and you believe in that company and it's gonna take off, then PlanetScale at $5 from day one is the best way to kind of lock in scale. One that comes to mind is a very popular streaming platform. They sponsor a lot of Formula 1 cars and like, or sports events. And I remember seeing their first bill was like $39, I think, 'cause that's when we had a $39, our first plan was $39 plan. Now obviously they pay us 6 figures now for their Panosco database. And, but that's grown across 2 years maybe. And I recognize the logo 'cause they, they had— done some very big deals, like very industry-leading, famous, like massive deals with streamers. And they go big name, I was like, I've heard of them, that's interesting. And they just created the app from data. They're like, we knew— they knew it was going to take off, um, and they just created their, their database on PlanetScale using Laravel and PlanetScale. And they did take off. And they— and I, I watched— I've watched them closely, and they've, they've grown very rapidly to be very, very successful, very large. And I guess for them the right time was knowing that they were going to need to scale quickly and picking a database provider that can go and do that with them and it can, can actually scale. And it's a very interesting trait I see a lot of second-time founders come to PlanetScale. So I send up like, we have an email that goes out, it's automated but it's personalized. Um, like we send it out and it will come back to me. And so a lot of users email me, like I probably replied to 10 this morning already. It happens a lot and I get to know people. And there's folks I've kind of— a very common thing I hear is second-time founder, database scaling was like the worst thing we had to deal with. I'm just not doing that again. I'm starting with you. Um, and it did— it kind of— it gets me because it goes into a personal journey, which was GitHub for a long time. And I started there as a database engineer, and I watched how databases like slowed our development down. And I really think it impacted our product substantially. Like, I really think it hurt our velocities sometimes so much that it really just impacted the overall outcome for our company and our product for our users. And that's why I wanted to build something that would scale and would work. The difficulty there is like, how do you message that? Nobody thinks about the future that much when they just want to get going. They just want to build out their idea and prove it. So we often, which is where your kind of question asks, we often see a lot of migrations. We see a lot of people coming to us and they look like different ways. So we might get a Vitesse customer come to us with hundreds of terabytes of data, millions of QPS, and a very famous brand name product, um, that is running on it, right? Um, a migration for them can take up to 2 years. Like, that, that— we have seen migrations take that long. Now, there's nothing inherent about PlanetScale or our technologies that make the migration any slower. It can technically be done as fast as you can do a copy. I did watch a very well-known AI company that had, again, hundreds of terabytes of data go from zero to fully ramped up on PlanetScale in hours. Like, they literally just did it in front of us and got moving. And by the time the data had copied over, it took a few days, they were up in prod. That was one of our fastest migrations. They moved within weeks, like fully everything they had was in weeks. But some can take years because you're really kind of, you're changing the wheels on a moving bus for very, very large-scale consumer products. You have to test, you have to validate, you have to do cross-region failover testing, you have to do all of these things that ramping up onto a very serious database requires. And so it can take a long time. I would say the sweet spot for companies that find the perfect time to migrate is when they are starting to get busy. They've maybe had a little few data, but like there's a lot of like very good to start on free database platforms, especially in the Postgres world. And I would say that we're seeing a lot more of this in the Postgres world as well. They start on these platforms they're great for development, they've got good DX, they do all these things, and they get going and they start to take off and they start to hit the upper limits and sort of enter the upper percentiles of workloads on those platforms and start to see problems. And so we've recently seen people coming to us for very rapid migrations. Like, they, they are in a situation where they are down or have just gone down and are concerned it's going to happen again. And so we've, we've moved to migrate them over very, very quickly. But of course you're on the back foot at that point, and you've taken downtime, and you're under duress, and your largest customers are probably unhappy. And with Postgres, we've seen a few that have let the problem go on so long that they've run such large single Postgres nodes that even migrating out of that node actually causes problems. So, so like attaching a Postgres replica— and the way Postgres does replication is I would say more heavy, right? The primaries care a lot more about like the downstream replicas and what they're doing, and it's a lot more involved. And so even actually getting them out of their current database provider has been difficult because attaching our replication stream has actually slowed down the primary. And they're on such thin margins. They're on like the biggest node that that provider has, fully contended, loads of queries. And so even then, just like trying to replicate out has caused issues. That's been pretty nasty. So, no one wants to get up to that end. The ones I've seen is kind of folks that are like Series A, Series B, their company is starting to take off. They've had a few database wobbles and they just know. Like, when they sit and they think, if I double my load, triple my load, quadruple my load, will my database survive? And they don't feel the answer is yes. But they're not yet on fire. Those are the folks that kind of find that sweet spot and move at just the right time. Like, it gets in just before their growth really kicks off and before anything bad happens. Um, and they have the room to do it without being stressed. Now the issue is, in this busy world, most people don't prioritize that way. They prioritize by what's the biggest fire, um, and, and you don't get credits for the fires that don't happen, right? Like, but, but, you know, there's obviously a warm, satisfying feeling for the companies that do migrate. They continue to take their customers, their competitors' customers, by staying up and being reliable, and that just tends to be the absolute sweet spot. But we do get to see some really fun migrations too. Very interesting products that we use and watch them roll out. It's great to do, but it's complicated.

And there's got to be just a certain amount of joy when you do watch something migrate in a couple days to see the system work. I mean, as a builder, that has to just be exciting just to see the process work. Yeah.

Actually, yeah, it truly is. Actually, one of the companies, when I watched them migrate, You know, sharding is not easy. It's not as complicated as people think, but it's not easy. And to watch them go from like unsharded to sharded in our UI very, very quickly at the scale they were at, I was like, wow, yeah, we've built something pretty cool here.

We might be onto something here.

Yeah, it felt really good. And then, yeah, I mean, and these are, you know, we've seen certain customers just like self-serve in very, very large databases. of very large dollar amounts, and that's great for us, you know.

We'll be back to the episode in a second, but first, I'd like to acknowledge the team behind the channel, This.Labs. We're seeing 3x to 5x productivity improvements with our teams and clients using tools like Cursor, Claude Code, and GitHub Copilot. We help teams adopt these technologies and get max value out of them through strategic partnerships, trainings, and other software engineering services. Check us out at ai.this.co. Thanks. Now back to the video.

Awesome. I think especially right now in this age of AI hyper promises, we'll talk about AI generally later, but I think there's a mood right now where people are really hesitant around too good to be true. I'm curious, for all the benefits that people are getting, the sharding capabilities, the edge stuff, The stuff around the, um, the different branches and, and all that capability that you've been talking about. Is there something that people need to understand, a flexibility or a limitation that they need to understand to be taking the most effective use out of PlanetScale, just to help people understand that? I don't know. Or, or do they really get a lot of this for free?

You get a lot for free, but I think it's worth people understanding that databases just are not magic. Right? Like, it's not possible to kind of expand this infinite pool of resources without some trade-offs or without some thinking up front. So, sharding gives you very easy horizontal scalability, right? Like, you can— and we do this all the time. We add hundreds of nodes at a time to certain clusters, and it just comes up and works. And, you know, when you think about, like, doing that seamlessly 10 years ago, Just didn't happen. It was extremely, extremely difficult to do. That said, um, a small table with no indexes and some terrible queries, it's going to be bad. It's just we've seen people— like, we, we had one customer that was just— they tripped some egress alert, right? Like, because they were just doing gigabits a second out of a tiny database by just reading an incredible ratio of rows. out and just— they weren't even using it. They were just filtering in their app and they were just selecting everything out of the database. That's just going to be slow regardless, right? Like, no AI, um, is going to help you avoid those unless you kind of work with it to understand that you're optimizing a specific type of database. So absolutely nothing's magic. The thing I've loved about AI though is that we don't really do anything differently in the world of AI. We don't even talk about it a whole load. I know there's a lot of kind of folks that claim to be like an AI database or native to AI, and AI has certainly shaped the database world, but not for the segment of it that we're in. We do, however, have a lot of AI customers because it's a kind of picks and shovels situation where they are scaling rapidly because they are immediately very successful because they're providing very successful AI products, and so they need a very scalable relational database to do that, and we've— we're known for that. So in— I don't think the dynamic of AI using databases has changed much for us other than clients are being written quicker. People can—

Yeah.

Index our suggestions and work off of our suggestions even more quickly. But at the end of the day, you're sending SQL queries. If they're bad SQL queries on lots of data, it's going to be really bad.

I guess where my thought process went for it is that I feel like there was a period, I don't know how long ago it was, and maybe it's still active, but that people loved the selling point of, it's just magic, just trust us, it just works.

Yeah.

But I feel like in this era right now, people really don't want to trust that anymore. They really want to at least peek behind the curtain. They might not understand everything that's behind the curtain, but they at least want to look and see that there are spokes and there are wheels and everything looks like it actually does a thing. And it's So I find that that's— I don't know if you felt the same thing of people's sort of attitudes changing around the magic thing. I think companies still want the magic, don't get me wrong. I just think that as a selling point, maybe people have sort of shifted to being a little bit more cautious. Like, it's almost like telling them they have a limitation makes them feel better than trying to convince them they don't have many limitations.

Yes, yes, I do think people's spidey senses go off when it's just automatic, it's auto this. Like, the word auto just gets thrown around a lot. Like, auto-sharding is a, is a term, um, in the, in the database industry that we don't use because we wouldn't try and do anything automatic like that. Like, they achieve automatic sharding by randomly distributing data across nodes and just hitting every node. Like, that's— yeah, the data has been placed, but it's very slow way, way of doing it. And so I think people have— you're right, they've started to figure out where that trade-off is, like, and actually, like, dig in and understand it. And because I think it's just come from us all being burnt by too much magic. But I also think it comes from believing that magic is possible. Like, we can create magical feeling. I was once lucky enough to get a tour by a former— I think it was the former COO of Disney, behind the scenes at a Disney park. And it was amazing. Disney itself is just this fascinating operations machine. I don't know if you know they have an envoy to the Vatican. But just crazy facts that I learned while I was at Disney. Anyway, so I got to get a tour of behind the scenes at Disney. And it is just an Amazon-level operations machine. Like, they just have everything absolutely nailed in terms of operations so they can deliver magic for the guests at the park. I think that's the better way to do it, right? Like, I think people don't appreciate fanciful magic if it lets their experience down. Um, same with airplanes, right? Like, we see ourselves as running like an airplanes provider. Like, it has to just work really well over and over again, and we have to bring you in and give you the knowledge you need to know to make it work really well at the right time. But no one appreciates too much innovation if it's going to let them down. I don't want people innovating with airplane engines. They work really well. Like, we know how to— but it's nice if you make the seats better or do the infotainment. It's just knowing where you do it, right? Like, where you have room to like mess around and be experimental versus where being stable, you know, like we find out all the time, like database platforms, they mess up backups, they mess up all these things. Just lets people— it's such a significant letdown and people don't assume that other people would make trade-offs like that. And when they do, it's very bad.

Yeah. And listen, as a consultancy, what the conversation we find ourselves having the most with people is that they kind of want to build everything. They like have this big dream and they want to build it all. And what we constantly tell people is spend your effort and your money, because software is still expensive, spend your money working on the thing that makes you special. Don't spend all your money building the things that 100 people have solved before, or at least one person has solved really well before. And I think that's probably the same thing. It's like, why spend, you know, your precious engineering budget to build up the competency around A, or sorry, around database scaling when you could be leveraging the things that PlanetScale, for instance, has to offer.

Yeah. There's a lot of boredom in the industry. I think you look at big companies, right? People are so abstract from the users of their products or how to deliver any form of success that like they kind of want something to work on. And you fight a lot of that boredom, right? And you have to talk people out of that being like, are you gonna really gain this competency? We had to do this at GitHub too. To convince people, don't— why run your own Git servers? Like, why? Like, it's— we do that stuff. It's not easy. Like, we make it easier for you. And we— it's just, it's very funny. Yeah, you're right, you have to talk people— going back to that core competency, but people don't know. And I think it's very difficult because there's this mismatch where there's lots of very technical people that want to tinker, want to play around, and then there's leadership that don't know how to refute that being necessary. And you just get stuck in this kind of kludge of like not, not much getting done.

Right.

Really. But the sensible ones— and this is why AI has been great for us too— is that the AI companies, they are fighting a hard battle, right? Like, it's a hard— like, they are all going hard with incredibly talented people with lots of capital. They don't want to mess around with the database. Like, no one's— like, they— when the database goes down, it sucks. It sucks for their users. Um, but when it's up and it works and you've paid that problem away, it's glorious. You can go back to doing the bits that only you can do. Which is the AI parts.

Yeah. It's funny to think about how long we put up with the fail whale on Twitter while it was finding its footing. And now in this age, like literally with some of these AI companies, if they don't ship new features weekly, they're abandoned as being, wow, they just, they must, it must be an abandoned project. And like the acceleration of delivery in the AI space is unreal for those products.

Yeah.

And that's sort of slowly infecting people's expectation of all softwares. It feels like the pace of all development has accelerated from where it was even a couple years ago, let alone a decade ago, when it was totally fine to say, oh, we're going to spend 9 months working on this new feature, and it'll roll out eventually, type of situation. People are expecting new things weekly, certainly monthly. And I think that's forcing companies to have these kinds of conversations where they're like, what can't we spend our time on then?

Yes.

Because we can't possibly run that fast unless we offload Some of this to somebody.

It's an interesting bar raiser in terms of needing to ship. I do like that generally. Like, I love shipping fast. We ship as fast as we can while being very reliable. I have a question for you then. You remember when we were all tolerating the fail whale and it was like, well, Twitter's new and scaling. Like, you know, like you just knew it, right? Like everyone— God, I love Twitter back in those days. I still love Twitter now, but like back then I just, I was obsessed. Um, but you kind of like, all right, they're figuring it out, right? Like it's kind of everyone wants to be on there. You know, it sucks when it's down, but you know, you just know that they're Like working on it. That's kind of the state of AI, right? Would you agree?

As far as it— people tolerating it sort of being weird at times?

Yeah, weird, less reliable. I'm not even talking about general models. I think that's true.

Yeah, I had the conversation with people that like, this is one of those weird moments when everyone is an alpha tester. And it's because I believe that people have realized this tool is that important and it will be that important. So you can't afford to wait for the production-grade version. Like, you have to be an alpha tester. So to some extent, some people don't realize what that means. They've never alpha tested anything. And so they just kind of get frustrated with its inconsistencies or its lack of documentation, all that kind of piece. You know, we all deal as coders with the 18 million different named Markdown formats because of all the different tools that everybody's using. I think that will lessen over time. But we, yeah, we kind of have to be here now. I just don't think we can afford to wait.

I agree with that. And I think we'll go through maturity as it— as, as software companies grow up into like enterprise companies and want to sell to enterprises, there's less tolerance for those kind of things. Um, and so there's— it will improve. Like, I think it will definitely get better. It's gonna be interesting to see it get better. But yeah, it is, it is interesting to watch. this insane need for scaling and everyone discovering how difficult some of those things are. And now we're turbocharging it with this whole new dynamic.

It's not the subject that we generally discuss on this podcast, but the other part of this that I think is really fascinating is just watching the speed of AI meet things it cannot speed up. And that is usually like compliance, compliance, regulation, approvals, security and these types of things. It's like, I am fascinated to see how that continues to play because it's just like a rapid stream hitting a strong dam. And it's like, which will win, right? The unstoppable force or the immovable object type situation. And I just feel like at the pace that AI is moving, like people will just try to find paths around these types of limitations. But there's only so far you can move, especially at enterprise scale in some of these dimensions, especially if you're working outside of the US. And especially if you interface with Europe at all. So that's been the part that I'm interested to watch develop at the enterprise level, because I think we've both been shocked by enterprises that have maybe avoided AI entirely because of those problems versus also the ones that are being way too naive of what they're actually doing and shoveling way too much data and way too much power to these tools, either because of something they're being told in a sales conversation or just their lack of understanding of its capabilities. So yeah, we're in for some, some exciting news stories in 2026, I'm sure, as some of these enterprises find themselves on the wrong side of this ledger one way or the other.

100%. Uh, well, one thing we've noticed is that AI is increasing and expanding the kind of frequency of attacks and vulnerability finding as well. Like we've seen a number of critical database platforms get completely like rooted, like full access to attackers, because they've been able to use AI to continually go and try everything. That's the thing I don't think people are prepared for, is that the, the scale at which you can be attacked and how these tools can be used offensively is giant. It might actually make all of these EU regulations moot, by the way. Like the, the pace that the way these things can evolve, and the fact that most of the internet's been sucked up into these models, it might just decimate the idea that privacy can be like a thing anyway, right? Like, you imagine— let's say, think of a physical thing. Like, imagine we all end up with these AI with the glasses on, like with cameras in the glasses. I don't know if you remember when Google Maps came out, Germany gave you the right to ban— like to remove your house from Google Maps. Like, what's the equivalent of that now when every cam— when you could— when you're on camera? Just constantly.

Not only that, and forget cameras. I was just watching, I just saw a video from a research paper of a lab that proved that you can do image and object detection using differential Wi-Fi signal polling.

Yes.

And I was like, well, okay, you really can't take yourself out of the spectrum of emissions. So, you know, we really are in a bold future, especially as the machine learning, not even just generative AI, but the machine learning and AI models get more developed in processing that signals. We put out so many more signals than we realize at any given point in time. And really the privacy is only there because it is too expensive to troll that data.

Yeah.

Once, once AI reduces the cost of that, we are in for another set of interesting outcomes.

Oh, for sure. One thing I have noticed actually is, you know, a lot of sales organizations and we did as you do as well is use tools like Gong, which like you record the sales call. And like it helps you get notes and it's good for training with salespeople and it's just good for follow-ups and whatever. In like in 2021 when we started selling our software to enterprises, we would use it and it was remarkable, you know, how many people would ask to have it turned off, which I get. They just don't want to be recorded having a call, right? They just weren't used to it. Now no one asks. It's like, yeah, everyone's used to 5 other AI note-takers being on there and everything being recorded and transcribed. It's so interesting how like it's just completely normal. They just know. Like same with kids, right? Like people have like, you know, kids— my kids— Kids are social. Yes, thousands more pictures of me, of my kids than there was of me as a child. They're just used to having cameras shoved in their face. It just like erodes those concerns very, very quickly. It's not all bad either that we do this stuff. I mean, you know, but like yes, it's interesting how much that has changed very, very quickly and changed that dynamic.

Absolutely. Well, I want to pivot us back to some of the big changes that have been happening for PlanetScale in the last year. I mean, I think for a long time, people that knew about PlanetScale might have thought of it as, oh, it's the database scaling company. It's the Vitess company. It's the MySQL company. Like all those things were synonyms, but we've seen that now break between Metal and bringing in Postgres and then Now, uh, Naiki and sort of an evolution of the sort of the vTest thing, I guess my question for you, which is sort of foundational, what is PlanetScale now at this point? Is it a methodology? Is it a, is it a tool suite? Like what do you guys believe it is that you're now building and developing by, by sort of adding these new products?

I would say PlanetScale at its core is a group of people that have a methodology. for scaling databases and making databases reliable. So when you've spent a long time doing this, the problems, when you squint, start to look very, very similar, and the goals are very similar no matter what the technology is that you're applying to it. And we have spent a lot of time learning how to do the job of scaling a database and keeping a database up in a cloud environment, in a very kind of, uh, error-prone and failure-prone environment. And we've learned a lot of things while doing that. And we proved that we can do that with Vitesse and with MySQL and running the type of databases that we run. If you go and look at our website and look at who runs on our platform, you'll see that we support a large amount of the working world and a large, large amount of like just every app that people interact with nowadays, you know, a lot— well, sorry, everyone who works in the US and interacts with with tech, they're using PlanetScale products, products that are based on PlanetScale. Um, we then decided to go into the Postgres world. We got asked continually, like people would say, we're on this platform, it goes down all the time, when are you going to do— like, you're known for doing this really well, why don't you do it for Postgres? And I would just say, you don't need to, you just move to MySQL or Vitesse. That was our kind of answer. And then we eventually realized that, you know, that's not always going to happen. People just have their chosen technology for the reason they have it, and people use Postgres. So it's— we— so last year, middle of last year, we developed our Postgres product and took it out there. And I'd say it was very disruptive. Like, it immediately— we were all stunned by how quickly it grew. Like, we— it's been as GA now for like 3 months, and it's already surpassed our first year of revenue we had as a company. Just Postgres has, um, that is wild. Like, it's growing really rapidly, and that is essentially vanilla Postgres running on our proprietary hosting platform. And the results are there. People are, you know, we've— there's blog posts out there, there's, um, case studies of people migrating off of other Postgres hosts and just knocking 75% off their P99 gaining multiple nines to their uptime. Like, it— we've applied our methodology as a set of people to another technology, Postgres, and we're seeing good results. We're very early as well. We're very dissatisfied with what we've done so far. It's nowhere near to the standard we got to with Vitess, and we're on that journey of doing it. And that's where NiKi comes in. So NiKi is, is Vitess for Postgres. All of the Vitess maintainers work at PlanetScale, and we've spent years running for tests in production at colossal scale. And now it's time that Postgres has a technology like that. Um, MySQL was for the original web era. Like, it was developed for an ever-expanding internet and the need to kind of scale on commodity machines easily and cluster really easily. And Postgres had a different path, and it wasn't adopted in the same way. I remember I used to go to the MySQL meetup in San Francisco, and it was GitHub, Yelp, Square, Etsy, Facebook, Google, Twitter, everyone. Just the internet, the top 50 websites of the internet would be there. They're all massive and mature now, and their workloads are very stable. All of the kind of new rising early workloads that the comp— this, this generation of companies are building on Postgres, and they need, need that solution. And that's why we're building Niki. Um, it's going very well. We are working with customers right now to start, start onboarding them to, to try and test it. It's different to Vitesse in the sense that the architecture is slightly different. It's better. The architecture is from first principles better. Um, it overall doesn't produce the same results as Vitesse right now. Vitesse is 15 years old. It's going to take a while, but we've kind of— you do a 15-year product project, you make some mistakes, you, you find things you want to do differently. And so we're doing those things differently, and the results are Really incredible so far. And so NiKi will— people will start to see it maybe middle of this year. We, we try not to— I don't really believe in dates. I don't really believe, you know, software's ready when it's ready, right? Um, but it's going to be very interesting to see Vitesse enter the Postgres world and, and that dynamic allow larger and larger companies to scale. Another thing we've noticed that people need to shard a lot sooner in, in Postgres.

Mm-hmm.

So it's gonna it's going to impact more people, which will be really, really nice. But in the meantime, just seeing the incredible amount of companies that just need unsharded, really reliable, really fast Postgres, um, that's been awesome. You also mentioned Metal. We just in December, we shipped— internally we call it Baby Metal, but what it was is we've allowed Metal to now go on much smaller machines. You can now, for like $50 a month, you can have a Metal node. And like for $99, you're getting like a like a cluster that you could run— nearly every Series B SaaS startup could just run on these things, right? Like, and incredibly quickly, um, and a great price point. We said one customer come off of another Postgres platform, they went from $2,100 a month of spend down to $99 on PlanetScale, um, just because the performance difference meant they just didn't need as much resources. Uh, that was awesome. And so, yeah, we're kind of, we're going from having some of the largest relational databases on earth. Now we're trying to bring this down to day one early companies that want to grow and scale and Postgres, Metal, and all these things are making it much more accessible.

But then talk to me a little bit about, because, you know, as the lead, as one of the leaders of the company, like talk to me a little bit about the sort of decision and the journey and the trade-offs on taking this approach, because I was reading some of the documentation and it was talking about how Like, why did PlanetScale make this decision versus this other decision? And there's like a whole post about, well, because we think that like OLAP needs are different than OLTP needs, so we have to optimize in different ways. Now, obviously, you know, we're talking about MySQL and Postgres as well. It's like, you know, the decision to do multiple things very well is like hard. Is that just something you guys have unlocked by becoming a bigger company? Or like, when you view what you're building with PlanetScale, do you see it as trying to find like an optimized middle point across a broad set of use cases? And how do you trade that off versus wanting to hyper-specialize products for very particular use cases? Like, do you guys have those kinds of conversations internally as to like whether what we're building is hyper-specific to one thing versus, you know, working across a set of related problems?

Yeah, we try not to generalize when generalization will be really unhelpful. And in fact, across the Postgres product and the Vitesse product, they don't share a massive amount. They run inside the same sharded— it's like we separate Kubernetes backplanes as well. It runs in, inside our very large global Kubernetes infrastructure, but the operators, um, the technologies are all very different, but they're built by the people that built the MySQL ones. And it just takes like learning and adjusting and knowing what the end goal is, cuz you've already achieved it elsewhere. Luckily, Postgres and MySQL, Are not massively different in terms of mental models. Replication and cluster management's certainly been different, um, but it's, it's more like, can we do something that's actually good and better than other people? Like, what's the point in doing this if it's just going to be average? That's, that was our whole journey at the beginning, which was, well, if we're not going to just show up and go, yeah, it's like bog-standard Postgres hosting, why is it good? I don't know, it's got the PlanetScale logo on it. Like, it had to be different. And that's why we started with performance. Like, can we be significantly faster than everyone else? And we were. We did that. If you look at our Postgres announcement, we shipped benchmarks. We benchmarked everyone and just destroyed everyone. Like, we put— we had to give other providers double the resources just so that we could see them in the graphs, just so that their QPS was at a number that would show against the one we were driving. Once we were able to do that It took a week, by the way, to do that. Um, we were like, okay, well, we should do Postgres now. And then we went on the long journey to productionizing it and getting it up to our standard of how to run databases. And it— we make it contextual. Like right now we're working on a specific thing that we've executed very well in Vitess. Postgres makes it very difficult to do, but we have the people that literally invented this concept for the world of databases working on it. So I just know we can get there. We have not hit a technical challenge related to databases that we've been unable to solve. But you get there by recognizing what's similar and what's completely different. And kind of you set the criteria and the standard for how it should look. And then the what you do to achieve that is completely contextual to the environment. And we have to get really good at that.

But I'm sure you get this a lot. I think it's funny how human brains go from like, 0 to 1 is a scaling tier, and then it's 1 to infinity, right? Like, as far as you supported no other databases, and now you support an additional database, and now people are like, okay, so now you support every database.

Yeah.

And it's like, I can see that part of what's governing that decision will be, can you deliver the same types of speed benefits you've been able to deliver for your existing offerings in another platform? Then sure, let's look at it. But, uh, you know, I guess for people that maybe are sitting with a different one than Postgres or MySQL and kind of hoping, oh, does that mean in the next couple years maybe PlanetScale will offer mine as well? Like, what should they understand as far as what's standing between that reality and, and occurring and not occurring?

That's great. Yeah, actually, you're, you're, you've hit the nail on the head. We have been asked for untold technologies, like not even databases now. People want us to go and host because they just trust it. Like, you know, I had the CTO of a company say, like, you should do hosting. I'm like, I don't think we'll do hosting better than others that are doing hosting. So, probably not. But he was like, but how, you know, when the database was the worst problem we had, is it now the lowest? Like, it's the— we don't have any issues with our database anymore. Now, silly things are our problems. You know, we want you to do more for us. And I was like, well, I think it's The reason that is the case is because we don't do much. We try and protect our focus. We're small. We have less than 40 engineers at PlanetScale. We're a very small engineering team. It's an elite engineering team. They're exceptionally good at what they do. But you only get to deliver good things with focus. And having a bar for reliability that's as high as ours requires a lot of operational maturity. And that bleed— and in decision-making is what bleeds into that level of maturity. But I never say never. The way to get us to do something is tempt me, is email me and tell me why we should do it and how much money it will make us. And that, quite frankly, we will look and consider anything. It just truly depends whether we think we could do well at it and whether it's worthwhile or lucrative enough. Because, you know, we look at the world around us and see how unsolved database hosting is as a problem and how— little progress we've made or anyone else has made in this world. And we see, so, you know, lots to do and a lot of money to be made going and doing that. And we're very focused on that right now.

We've touched on this briefly, but I think for this sort of our last topic, I'm curious about how the— again, we've talked a lot about how the AI is just sort of consuming all the oxygen in the space. How is that pushing on what you guys do? Because I can see that like the, the, the day-to-day needs of enterprises is not changing that substantially because of the presence of AI. And so I'm curious, like, to what extent PlanetScale is still being largely driven by the very real, never-going-away needs of enterprises delivering content and software every day versus the sort of the emerging needs of agents, not just AI companies, but also companies using AI agents and hobbyists and all that ecosystem of new— kind of creators and entrepreneurs. Like, how are you guys feeling that? What kind of pressures is it putting on or demands on what you guys offer?

It has inverted the ratio of writes to reads. Nearly every workload pre-AI— not, not— I mean, there's plenty that are very write-bound and we have lots of those. In fact, the workload I first learned MySQL really well on was this incredibly high-write workload. And that's why I built like an own version of sharding years ago, like 2010. However, the majority of apps that you used to see would have like 100 to 1 read-to-write ratio. And you, you like, look at Twitter for example. So many more people view your tweets than, than— like, it's like that's a select query every time. It was write once. GitHub, how many pushes versus pulls? Like all of these, you know, It's, it was always this ratio. Now we are seeing AI workloads that do significantly more writes and need them to be very, very performant. And this is what sharding is very good at. Distributing writes across many, many nodes means you get much more concurrency and you also just don't saturate and overwhelm specific clusters. And, and, and we've seen folks that come to us like a very— another very popular AI company that's in like the go-to-market space. They have a new product that they just know is going to have a massive write volume. They just know, like, one, it will do very well because their company is doing very well, so humans will be using it. But just by the nature of what they're trying to deliver through AI features to guarantee their product is successful, to supercharge the humans that are going to use it, they're going to write a ton of data. So they immediately come to us and just say like This AI era has been the first time we have just seen people come in and create new databases sharded. Like, we don't have any data, but we're going to shard from day one because the moment we switch this thing on, it will start generating writes. Like, we again, we have like Cursor as a customer. Their agents are doing things constantly and constantly generating data, and it goes into PlanetScale database. So it's a very heavy write-round workload. It's the same for a lot of these AI companies, they're storing so much data. And it's been great for us for those reasons. Metal and sharding are just built for this world of writes. Like, you can— if you separate storage and compute, which you shouldn't do for OLTP databases, reads you can get up to a good speed. Like, you can just cache very locally on the machine. Writes have to go across the network. Slow. Well, if we fix that problem, We're very good at that. And so, yeah, I would say AI pressure is coming from storing massive amounts of data at very high write volumes, um, with much lower read frequencies. And so it's meant— it's very different.

Yeah. As an architecture that was developed in part that really support that write-heavy thing, does that feel like a validation that you were right all along, or is this more a right place at the right time kind of happy accident situation?

I think it's a happy accident. Like, we built our database technology for extremely large consumer workloads primarily.

Yeah.

Every Call of Duty score goes into Vitess. Every time you get a kill in Call of Duty, it goes into Vitess, right? Like, only Cash App, for example, runs solely on PlanetScale as the main database. Like, when you— millions of people use these concurrently, right? They— there's products on PlanetScale that just have tens of millions of DAU, right? They produce loads of writes like they, they always have, but they're also based on the power law of the— like the way internet and human behavior is, is that they're also the— some of the largest consumer products out there. So we build it for that. Now I think it's the, the breadth at which you see those similar scale write workloads with much fewer human users using it. So it's more of a happy accident. Like, no one could— no one really thought AI was coming or that it would change this, like, create this kind of dynamic. But because we focused on a, I guess, a smaller segment of the market, if you look at it by company or by product, to deliver what they need, which is the most demanding kind of workloads, it's fit really nicely into AI. Other databases have optimized for, like, scaling to zero for a different type of AI use cases, which is like spinning up arbitrary cheap single-use databases that never come back. That's a different trade-off, and that's also brand new to AI. It's not something we do or would need to or want to do, but it's also shaped things that way. And those are definitely much more deliberate, I think, in their approach they've taken to enable this type of AI usage. Ours just came from always supporting very, very, very large web-scale workloads, I guess. Well, there you go.

I mean, hey, we'll take happy accidents. That works, right? That's, that's, that's what, that's what opportunity is. It's when, uh, when, when luck meets hard work, right?

Are most companies built that way? I think, I don't think enough people actually, um, weigh the impact of luck enough in their careers. Like, it really does. It goes both ways. People do silly, make silly mistakes too, but we are just very lucky to get to where we are. And everyone is.

It doesn't devalue the effort. or the product or any of the intention. It's just that sometimes great ideas don't pan out.

Yeah, exactly. You can also put— exactly, you can put all the luck in the world in the lap of an idiot and they'll still screw it up. It just depends. Like, it really, it just really depends. For us, I think it was much more of a waiting game, right? Like, the MySQL market is much slower moving. It's not— all the energy is in Postgres. That's a fact. Postgres has won. And so, it felt like you were kind of just like over in the corner just doing your thing and like, yeah, I mean, yeah, I guess like these new wave tiny startups don't care about our ability to fail over a petabyte of data in seconds across the country. I think that's cool, but they don't. They don't have those problems. But it's nice now to be in a market where the things we do and do really well are appreciated by builders and smaller companies and just— like our customer count's probably nearly doubled since doing Postgres. They're just all smaller. Right? Like, it's still like we've got single customers that pay us more than every Postgres customer combined. That's not going to change for a long time. But it's the kind of diversity of these smaller companies. It's great to see them all building. Or go to a tech event in San Francisco and they're just people coming up to you, we use PlanetScale. It's so cool.

I love, I love to— I'm going to carry that story with me about the idea of tracking the second-time founders as a, as a good sign that you're on the right path.

I think so.

These are people that do not have time for BS anymore.

They know what they need to Yeah, yeah, they've lived with their decisions previously. They also are more likely to build a successful company, so you want them as a customer as well. There you go.

Well, listen, as we wrap up, we'll put links in the show notes for like the main company and things like that, but is there any place that you want to direct people either to a community or place where they can get connected either with your team or with other sort of PlanetScale devs and people like that?

Go to app.planetscale.com. sign up, but also go to our Discord. We have our engineers in there. I'm in there. If you want to migrate to PlanetScale, if you are stuck on a hosting provider that is letting you down, just contact us. We have migration services. We will help you get out of this. Like, it looks scary to you. It's incredibly easy to us. We do this every single day. Um, just reach out. We'll help you. We're very personal. We don't have a big sales team that is gonna hassle you and sign up you to newsletter drip campaigns. You're going to meet engineers, you'll probably meet me, and we'll get you migrated.

Wonderful. All right. Well, that sounds great. That's going to be it for us today, everybody. Thanks for listening to this episode of the Modern Web Podcast. Thanks, of course, to our guest, Sam. As always, we say the conversation does not stop here. You can find Sam online @samlambert or on LinkedIn, although it sounds like you only come in occasionally.

Very rarely join LinkedIn, yeah.

Mostly you'll get me on Twitter very As for me, you can find me online @robocell. For the podcast, you can find us online at modern.web.com or on Twitter @modern.web. As we wrap up, we'd just like to thank today's sponsor, This Dot Labs, one last time, who would like me to remind you that This Dot is dedicated to guiding companies through their modernization and AI transformation journeys. This Dot Labs is a tech consultancy that specializes in amplifying your technical capabilities, whether it's expanding your dev team with seasoned professionals or structuring your streamlining existing team to be more agile and agile. your project's journey from ideation to deployment. We work with clients like Google, Microsoft, PayPal, and more. Check us out at thistot.co. One more time, that's thistot.co. All right, see you all next time, everyone.

Thank you.