Software Huddle - Operational Excellence Is the Moat with Sam Lambert

Episode Date: July 15, 2025

Today, Sam Lambert from Planetscale is back for a third time. Planetscale just announced Planetscale Postgres, so we had to get Sam back to tell us how and why they decided to add support for Postgres. It's always great to have Sam on -- he brings great stories about real customers and honest insight about the state of the database industry. In this episode, we talk about the road to Postgres and how operational excellence is the only true advantage in database providers. Sam walks us through the current Planetscale Postgres offering, along with details on Nova, a new sharded Postgres project that Planetscale is working on. Along the way, we get updates on Planetscale Metal, how demand has been for Planetscale Postgres, and future plans for Planetscale.

This is the third show, isn't it? This is, yes. You're the third time guest. So yeah, excited to have you back. Yeah, it's been really interesting. We had this weird moment. Actually, we knew the day of medal that we were going to do Postgres. You're getting extremely well hosted, real vanilla Postgres.

Like just we hide some of its deficiencies, present you the things that it's very, very good at, and it just operates very well. I will say though, I'm incredibly surprised how many people have reached out asking us to do other data stores. What are the most common ones you hear? Redis, MongoDB, Elasticsearch. You had a tweet recently that I loved,

it was just like talking about how in the database market, there's not really that much IP, it's like all about how good you are at operations. If anyone thinks we haven't done certain things because we can't, that's wrong. It's because we don't want to. What we want to do is have an outcome, and the outcome is extremely highly available databases.

That's it. And we make unapologetic trade-offs to go and do those things. And it's our internal culture around availability and safety that makes what we do to be very, very special. What's up, everybody? This is Alex and super excited to have Sam Lambert back on the show. Sam's one of my favorite guests, one of my favorite people to talk to about database stuff. And, you know, we just had him on a few months ago talking about PlanetScale Metal,

but then they announced PlanetScale Postgres just a week or two ago, had to get him back on to talk about that and how PlanetScale is now branching out, not just doing MySQL and Vitesse, but doing Postgres as well. We talk about that, we talk about operational excellence at PlanetScale and at database companies, what that means,

along with Nova, which is their sharded Postgres project that they're working on, and what that's going to look like in the future. A lot of really great stuff there. As always, if you want guests on the show, if you have comments, questions, anything like that, feel free to reach out to me directly. With that, let's get to the show. Sam, welcome to the show. Thank you for having me again.

I'm really happy to be back. Yeah, welcome back. This is the third time back. We just had you back a couple months ago talking about PlanetScale Metal, which is awesome. But this is the first time that you're back as a Postgres CEO, because now you're a Postgres provider.

We had to get you back on talking about your new announcement. So we'll also talk about today, but I guess maybe just like for everyone, get us updated on what's been going on with PlanetScale and this recent announcement you have. Yeah. I mean, we were just chatting in the office about how the last week has felt like a year. Like everything has been, it's just been unreal since announcing our Postgres

product. Yeah. I mean, I'm just gonna have to spend this entire weekend replying to emails of people wanting to access it. Yeah, so for those who don't know, your PlanetScale's been famously kind of a Vitesse slash MySQL company. We are the maintainers of Vitesse, Vitesse being known as this kind of ubiquitous sharding and scaling solution for MySQL databases

being run by some of like the world's largest companies and you know just known for extreme scale and a lot of these companies run on our cloud. And there's always been this open question that became almost a meme on Twitter, like would we ever do Postgres and people always asked and I said never. And that's why in our panelists I say never say never because I mean yeah and Rick Rick came out and said like this is why we'll never do it too didn't he have like a good thread on that yeah yeah yeah we were yeah we were convicted actually um we were wrong but we were convicted uh yeah it's been really interesting we had this weird moment actually we knew the day of

medal that we were going to do postgres. So we shipped MED-EL, and that announcement went really well. We announced it with a few of our customers, Intercom, Depot, and Cash App, all very large applications. And we showed us kind of dropping their P99s significantly. And it was a really cool announcement. PlanetScale, we're very low on marketing.

We kind of try and really, we just want to tell our customers stories. Databases are well boring on their own. They're hard, but you're not shipping your database as a company. You're shipping a product that needs a database, needs it critically, but it's the dynamic and fun stuff. So we actually live vicariously through our customers. And their needs are very technical as

well. You know, flashy websites and slideshows don't really convince companies that make tens of millions of dollars of profit a day on their product that runs on your thing to like use the things. It could be business ending if they choose the wrong database. So we take that very, very seriously. So with the way we did the meta launch was we just launched with really big customers and said they run on this already, like it works. Like if you want this too, it kind of works. right now, people's dopamine receptors are getting burned. So we tried to release it differently. That went really well.

I mean, we got about 10 times more people coming in for Postgres that day than they did for MySQL. And it was wild. We had the founder of a- Wait, on the day of the, on the day of the metal launch, you're saying? Yes. People just reaching it.

People saying, can you do this for Postgres? Can you do this for Postgres? Yeah, just please. We just saw AI companies that were having really high write workloads just started migrating from being on Postgres onto Vitesse. Some of them were able to achieve that really easily. Some were just using Drizzle or Prisma and it wasn't much of a conversion and they were going down on their current provider anyway, so who cares? Just migrate. Drizzle or Prisma and it wasn't much of a conversion.

They were going down on their current provider anyway, so who cares, just migrate. We realized that people love Postgres. All these amazing companies are being founded on Postgres. It reminded me of the early days of GitHub where we were the same, where everything was on fire. Your company was growing, you just did the thing that would get you through the week and you, you know, that energy is amazing. PlanetScale has done a really good job of earning the trust of hyperscale companies, and that's been really hard and rewarding to go and do that.

And now to bring that expertise to a really rapidly moving part of the industry has been really fun. So yeah, we've gone and done it. We can dive into the story of how we did that, if you like. But yeah. Yeah, and so you said when you launched MED-AL, you knew you were doing post-grad. I want to know the timeline of when did you

actually change your mind and say we're doing Postgres and what did that look like to make it happen? We've thought about it for a very long time and always debated it back and forth. The thing I was very clear about is that we'd have to bring something different. There's lots of good companies doing post-grads. I mean, there's lots of great stuff in the ecosystem and it's a very dynamic community. I don't wanna just like rock up and just not be special with what you do. So we had to convince ourselves we could do that

first of all, but when we definitively knew it was happening was the same day of the metal launch, we had a big party at the office. And I just kind of walked up to Nick, our CTO, and just said, we have to do Postgres. And he was like, I mean, it can't be harder than anything else we've done. And I was like, that's the spirit. And so pretty much like two days after, we told the company, we said, like, we're going to do this.

Clear your, we basically said clear your plates. Like there's two weeks to kind of tidy up some of the work we have to do. We had some stuff for customers and a few things going on. And then we were gonna do a hack week because you know, it's a big momentous thing to go and do this. And we wanted to see and surprise ourselves.

And I'm very spoiled and lucky to work at Planetscale. And I'm spoiled by the standard of the engineers that we have. I just knew that, you know, by saying we can do this and like letting them surprise themselves, we would just know everything. So we basically did like an all hands on a Monday and said, this is what we want to do. We may not even do it. Let's just suspend all belief and just try for a week to see if we can get Postgres up running in planet scale production and connect to it externally. We had that done by Tuesday afternoon. That was the Friday goal. If we can demo that, scale production and connect to it externally.

We had that done by Tuesday afternoon. That was the Friday goal. If we can demo that. We told people to split off in teams and try and figure things out that we figured out at Planet Scale for Postgres and then demo at the end of the week. By the end of the week, we had full high availability failovers of Postgres done. The demo's all hands on the Friday took three hours. Like every single person at the company had something to show that we'd achieved with Postgres and everyone's feedback was we just completely surprised ourselves. We were just shocked. So then we picked a really aggressive deadline and just ran it down really quickly as a company. The way

we worked was really fun and we're going to stay working that way as we just, the whole engineering team gets on a call on Monday, decides what we're demoing on Friday and then we demoed it on Friday and we just did that week on week. In the loop, in the loop. Yep. And then, okay. And then, yep, sorry. And then so how does Planet Scale support it, right? Because Planet Scale, in some sense, the first time we talked, I was like, hey, Planet Scale is kind of two things. It's like, but tests over here, but it's also like this developer experience and operational stuff as well

that's useful for a lot of devs. You can run unsharded MySQL on planet scale. And that's what's happening with Postgres right now is it's unsharded Postgres that you're running. I guess like how much of the planet scale ecosystem do I also get with it? Like, is it using VT gate or is it using some sort of different type proxy type thing

or what's happening there? Yeah, this is a really good thing to unpack actually. So we've, there's a few things we did wrong with the Vitesse product that we're undoing in this world. So for the longest time, we were kind of using Vitesse to host uncharted MySQL databases to be like very good resilient MySQL, even if you didn't need sharding. But that meant you had to like live with some of Vitesse's trade-offs, even though you didn't need them.

And that was like more difficult for people to go and adopt the product that way. It produces exceptional results for people who need sharding. And we're not apologizing for those tradeoffs if you need charting. We're giving you incredible things in return for taking away very little. And so we'll leave that aside for a second and then talk about the other thing and then how this all comes together, which is there's completely open parts of what Planescale does.

Vitesse is an incredibly well-run, open source project run by the Planescale team and contributed by a number of very significant and fantastic companies. It's just a really good project. I mean, it's just a very, very mature CNCF project. That's out in the open and anyone can go and use Vitesse to do whatever they want with it. A lot of people do. In fact, every now and then you just surprise yourself you hear of a company using it and you're like, wow, I mean, I had no idea. That's really awesome. The real secret source of Planetscale and the thing that people pay us for is our operations and the software that underpins that operation. So like our

operator, the way we use Kubernetes and the way our infrastructure is deployed is Incredibly unique and incredibly resilient We actually tweet it owner tweeted we blogged about our kind of principles for extreme resilience You know, we didn't you know, this is not a knock on anyone who did but like we didn't have any outages during Not a single query drop due to the Google GCP outage. Even though we declared an instance on a call watching to make sure that that wasn't going to happen,

it's because of how resilient and self-healing our infrastructure is in our operator. And it's the product of hundreds of millions of database failures in every pretty much scenario. Like it's fascinating when in the very rare occasion that something goes wrong, like we wedge something or, you know, even if it's a tiny five gig database that's paying us 39, like the whole engineering team shows up and we will sometimes spend days, if not weeks, to figure out exactly what happened

all the way down to the bare bones of what the Colonel did when this happened to make sure that that can never happen again. And we're on such a long tail of things that could go wrong. And it's kind of like airplane maintenance, right? Cessna engines have just got, again, probably hundreds of millions of hours. They only fail the known ways and can be repaired. And that's kind of how Planescale is.

There's two ways to fix a problem at Planescale, a PRS or an ERS. A PRS is a planned reparent, which is where we know we're going to kill the master of that shard. And so we give the rest of the cluster a heads up to be ready to gracefully step in. Or an emergency one, so an ERS, where the master's died and you resolve it back.

We kill nodes. Just all this. Oh, go ahead. Yeah, go ahead. We kill nodes to fix all problems. Like if a node's misbehaving, you don't just try to get on the box. Just automation just kills it because our orchestration knows how to get a cluster back

to a known working state every single time. Like it's just shoot the node. You know, we run petabytes of state this way. And so that is what underpins the new Postgres offering. Like that technology and those learnings, what you're getting, you're getting extremely well hosted, real vanilla Postgres. Like just we hide some of its deficiencies, present you the things that it's very, very good at. And it just operates very well. And you can tell by the things we've chosen to launch with that no one else has. We have full online upgrades for major versions. You can migrate from Postgres 13 straight into 17 on plan scale online and people have done

that. We have a higher availability proxy that buffers queries and allows you to like change configuration like on the fly without fly without interrupting all of these little things that people haven't built. And because they're really hard and fiddly to do, we've just done them by default because we can and that's our standard. Yep, yep. You had a tweet recently that I love.

It was just talking about how in the database market, there's not really that much IP. It's all about how good you are at operations. And I totally love that. And I love Dynamo and getting close to the Dynamo team, the operational sort of excellence and loop that they have there,

I think helps them in a lot of ways. And I see the same thing with PlanetScale where it's like, truly there aren't that many, like there are no like enduring features in a database that like are gonna give you a long-term advantage over someone else. There's like some architectural differences that can account for different things. And then it's almost purely operational stuff.

Like who is the team you had? How long have they been doing it? What's their process for like continuing to improve that like operational posture? Like that's the only like durable advantage you have in Databricks is really. A hundred percent. Like, yeah, like you said, everything can be copied. We can all read the Dynamo paper. We can all read the Aurora paper.

Like, you know, if anyone thinks, if anyone thinks we haven't done certain things because we can't, that's wrong. It's because we don't want to, you know, people come to us assuming we would apologize for not being able to do like active act like active active like dual mark like dual like quorum rights, for example. They're like, Oh, you cockroach can do that where you write to both two nodes at once. So we would never do that. We fundamentally do you think we're bottlenecked by being able

to write that code? Absolutely not. Not at all. We don't want to. It's not a good way of doing things. It's bad. Like someone tweeted at me the other day talking about what a Marvel spanner is and all the atomic clocks. It's like, to what end? I mean, we've migrated giant spanner customers and they've got faster, more available. To what end do you mess around with this? It's not being able to do it. It's not wanting to do it. What we want to do is have an outcome and the outcome is extremely highly available databases. That's it. And we make unapologetic trade-offs to go and do those things. And it's our internal

culture around availability and safety that makes what we do to be very, very special. And if that's not what people want, fine. That's fine. I'm not trying to say we're better in any way. We just have an opinion and it happens to align with uptime. Yep. And it's interesting not only how that operational aspect gives you a durable advantage in running those databases and having the availability and reliability and all that stuff.

But also, that's what's powering Metal. You guys could have never done Metal if you weren't that operationally good. So many databases have to say, we're going to use EBS to sort of outsource some of our durability and reliability because running on local disks is too hard for us to... It's just too risky for us. But now that you have that operational advantage, you can run on local disk and still give all that reliability without, you know, giving up the performance of using EBS.

Absolutely. And even EBS at our scale, right? I don't know if you saw our, we have a really good blog post from our studio, Nick, which is like the true failure rate of EBS, which is we deployed so much EBS that we get this global viewpoint on how it actually works and behaves. And even then it's not perfect. I heard of one of the Postgres startups where one of their customers came to us and said they lost $500,000 because that company managed to wedge a deprovisioned EBS node. It's like EBS has done everything for you

and you still feel that. I mean, it's wild, but that's how it is. I mean, computers are not easy, but yeah, it's this kind of just constant operations and there's intangibles in your culture that make that possible is, you know, and like shout out to the Planscape team for being who they are and making that all, you know.

Yeah, and also shout out to your content team. Like you mentioned that EBS post, which like, you know, Ben does like some awesome posts on just like concepts and things like that, which are super like the caching one he just had. It was great. The B-tree stuff, like really good ones. But then also those posts that like the one you're talking about, that Nick wrote about EBS failures is like, no one else could write that post. Like very few people are using as much EBS as you all. And just like me as a normal startup, I'm not going to see enough EBS to get a sense

of any of that stuff. So, and Amazon's not going to release that stuff on just like what the true failure rates and things like that are. So just, you all having like the perspective on that and sharing that is again, what I love talking to you guys and reading your stuff. So thanks for sharing that.

Yeah, no, it's really fun. Shout out to Ben and Holly, which our two-person marketing team that produce, not only do they produce amazing content, they make producing content delightful so that engineers where it doesn't necessarily come naturally to them, they make it really easy to do. And I think it shows through our work. Ben did a caching post

this week that people absolutely loved. That's what we do really all like all the animations on it, including like the deep dive stuff. But then like some visualization of that stuff is yes, it's great stuff. It's really fun, right? Like, I mean, I think it's what people want. The more slop that's going, like the content is just getting worse now because people can just, their internal metrics are all wrong.

And we would rather spend six weeks on a single blog post and have it be enduring and people like it and it feels real. That's special. I think someone can just learn something whether they, no matter what they do in their job. Yeah, like I was an event last night and people just come up and they say, you know, your blog is phenomenal. It just makes me so happy. And that's, you know, one of the things I did at GitHub was start the engineering blog there. And it's like way bigger than anything I did now.

It became really awesome, but it just felt so nice. It's lucky to be in a business where just talking about cool tech shit aligns with what your audience wants and it's like very organic and natural way of marketing things. Not every business can do that. Like it's a luck, you're in that industry, the way that stuff works, but when you can, you should. It's fun. Yep. Yep. It's cool. Okay. So going back to again, Planet Scale Postgres and what I get from it. So I guess like the one thing I think about, I asked about VT Gate earlier, but the one thing I think about with Postgres is like limits and just all that stuff.

Are you doing any proxy or anything like that, or is it just going straight to my Postgres instance and I have to think about connection limits there? You can do either. We give you direct access if for some reason you want that. You're running your own proxy. Like whatever you want. I mean, there's a million reasons why you'd want to go directly to the node. But we also have psBouncer which is our own proxy that acts like pgBouncer. It's different in the sense that it's a bit more resilient, it's very fast, and it can do things

like buffering and holding off of queries while we do things and swap nodes out under the hood to achieve high availability. That itself is actually getting major rewrites right now to get even better, but V1 is already an increment above what PG Bouncer is and does, and there's work going on. See, again, this is like another thing. There's these benchmarks that some people,

there's some websites out there where people are benchmarking all the databases, and it just does a select one. And even before we had Postgres, people were always commenting, like, how is plan scale so fast? Well, it's actually because we have an incredibly well-managed edge network, right? Like, we manage traffic. We're not just like serving queries. There's like gigabits of traffic flying out of

of our edge all of the time to serve Extreme volumes of data in and out that's a level of sophistication in itself that really matters, you know, I was reading some other postcards company their proxy and like the P99 numbers of that are just horrifying. Even half that number would just kill most of our customers' queries. It would be a nightmare. So it's those kind of things that are really additive, that people don't really understand or appreciate

and don't have to. But it nets out as being much greater. So we have these benchmarks that we run internally and continually. We have all of that we run internally and continually. We have all of our competitors and Amazon and everything benchmarked. We don't just benchmark queries. We benchmark just connecting to the node, right?

So we can make sure we don't add any latency at all and that we can make sure there's zonal affinity and that's handled properly. It's all very, very detailed and difficult and it's all infrastructure work. But yeah, we're doing that and have done that for Postgres and that's only gonna get more sophisticated and good. Yeah, gotcha.

And so with like zonal affinity, are you routing to replicas? Or like, is that something like, do I specify, do I like, I want to read from the primary or replica? Or how does that work with that? You can add replica and basically we will send you to the nearest replica close to you. And that's great because that means you can just, you know,

not have to worry about that too much. You do have to care again, if you start delaying replicas, right? Like reading your own, right? Might not be the best thing. So some people do hacks to care again if you start delaying replicas, right? Like reading your own write might not be the best thing. So some people do hacks to make sure they like speak to the master for a certain amount of time after a write. But most OLTP workloads are much lower write volume than read volume. So having a good like replica story and ability to add tons of replicas and then just intelligently

route to those is a really good scaling story for people. Yeah. Yeah. On that note, you mentioned a little bit ago about a lot of the AI, like the new AI startups are much more write heavy. Is that are they like anomalous compared to like a lot of other customers that you've seen, like just in terms of the right, the like rewrite skew there on that. Yeah. Yeah. Now, our kind of customers often do skew towards being right heavy just because of what we do and because they're like very large consumer apps and a lot of what powers consumer apps is your own data, right? And so keeping a lot of information, even though it's not always presented back to the

users is often very helpful for these companies. So we do, and sharding is like the best way to scale, right? So we do see that, but it's, it's what we've observed in the AI world is companies that are like a lot younger and smaller, producing a lot more rights than what you'd see from other types of product. And that's for various reasons, like people are chatting to agents or whatever, and people want to log all of those things. AI companies also want to train, so they want to store a ton of data

to then access later. You can imagine you're a company that uses some of the large models that are out there from the model vendors, but you want to eventually produce a model that's yours or closer to being yours. You want to store a lot of stuff. You want to store what the user asked for, what we sent the model, what the model sent back, what the user like reacted and what they did next. You're storing a lot of this kind of metadata that's like next to like, it's not necessary model. It's not going to be model data.

It doesn't even going to be vexed necessarily, but it's just like metadata. That's really useful. I mean, look at, like, I don't know the GitHub data set, for example, yet something, but like the pull request comments, that's useful. There's always just additional things that AI companies want. Storing those in a database that allows you to access them quickly is really important. So yeah, we've seen as long as they have saying, yes, they're doing a lot more writing. And that means they're hitting problems a lot sooner because writes, they have that's where all the scaling reads is like really

easy. I'm cash writes, you know. Yeah, yeah, exactly. Okay, what about other features of planet scale like backup in the restore? I'm sure but like, what about branching or query insights? Are those integrated with Postgres into the PlanetScale ecosystem or what's that look like? Insights is there. We have to finish off a few bits to like have it as mature as it is for the Vitesse product. Branching is on its way, but we chose to ship sooner. The Postgres schema change story is better than MySQL's by default.

Vitesse makes it extremely good on top of MySQL. Rewind and all these kind of things. And we want to bring that to the postgres as well. But what we discovered, and we spoke to so many people. Like we sent so many NDAs. It was unreal. Like at least 50 or 60 people knew we were doing this. It was just all under NDAs it was unreal like a lot like probably fit like at least 50 or 60 people knew We were doing this it was just all that all under NDA basically we were talking to all these people

And what we found is they had like a schema change workflow They kind of liked or weren't that mad about whereas the my sequel world doesn't have that my sequel has a much worse schema change story So we thought to ourselves. I mean there's's so many people that want what we do in terms of performance and cost that holding back, you know, just shipping those things is just not worth it. So they're fast follows, they're coming soon. And they'll be different, right?

They'll have to be contextual to what Postgres needs. And they'll be pretty special, I think, once they once they get out there. But insights, insights is actually Postgres makes doing insights a bit easier because we can, you know, we've modified MySQL, we run our own fork of MySQL to like allow stuff to come back from the headers, for example, to give us information we need to feed insights. With the Postgres, doing that with postgres, extending it to grab that information is easier. So we'll see some different and interesting things with that.

Yep. Okay. What about, so y'all are in preview right now, but I also know you're having launch parties and people are migrating during these parties and things like this, I guess, like what's the process to get in into PlanetScale Postgres and do you have a timeline for GA on this? Yeah, so it's weird.

It is G, it's like, it's production, it's in production. Right, it is in production. It is, can I just sign up and choose Postgres right now? No, not unless we give you access. I will give you access after this call if you wanna try it it. What we would say now is like private preview of the production thing. Companies making revenue run on this thing. It is production ready. We are constraining access, again, because we're like this. We want to make sure that everyone's going to get a really good experience. And letting the floodgates open means that may not happen. Now we're glad we did that. We have

hit capacity limits with the amount of people wanting to move already and so we're figuring those things out or just making sure that everyone has a good migration path. But we have been letting people in. If you look on Twitter now, people have gone and had access and are seeing crazy good results. Convex runs on it. That was a partnership that we announced as part of this. That's extremely cool, seeing the results for their customers just magically getting faster. And so yeah, we're working really fast to fully GA.

There's just a few things that we want to iron out to make sure everyone gets a good experience, but if you if people DM me or email in and There's like a form that you can fill out and we ask for an you know on the second page We ask for like an expanded set of information if you fill that out We're likely to get back to you. You know, we're prioritizing just certain types of workload that we want to see. We want to make sure that we bring people in from pretty much every other provider to make sure that they have a good workflow and

there's beneficial things to them and that we're not missing things. You know, it's just those little things like we want to make sure that we get good feedback to make sure our docs are good and comprehensive. We want to make sure there's a good guide for migrating from every different place into the product. And so it's just, we're just keeping things constrained to make sure it works, but it is fully production ready. And anyone migrating over is getting something that we fully stand behind.

Gotcha. How did convicts get involved? That was like, that was an interesting launch partner where it's like, hey, it's another sort of a database, but also more on top of a database. And then they're also using you, I guess. What's the story there? I've been watching Convics for a very long time.

I have an immense amount of respect for their team. Their team really understand databases. They have a very similar origin to the Planar Scale team, which is a bunch of them have run hyperscale databases. They have a very similar origin to the planet scale team which is a bunch of them have run hyperscale databases so the team behind convex ran the my sharded my sequel at Dropbox which is like 15,000 servers in like a single my sequel cluster. That's really... Is that Batista at Dropbox or is that their own sharded thing? No, that was their own storage layer. We have some extra Dropbox people as well.

So, like, convex is kind of like people are people have worked with, they're doing something really cool, they're very mature and very operationally mature, their business is doing really well, like they've built something that's incredibly new and dynamic as a database product, but without breaking the rules and being reckless, you know. And so we were already challenging to them because they were looking at moving to MySQL metal. Because they were previously on RDS. They're innovating in a place that doesn't require you to go and have

to rewrite the underlying storage engine of your product. You should build it on things that work. In the same way Facebook runs the world's largest graph database on Chata MySQL, they run a massive message queue on Chata MySQL. It just kind massive message queue on Chata MySQL. It just kind of boils down to what you know, and then you kind of build up from there. And so we were already chatting,

and we went over to their office and said, we've already been chatting a bit, and Jamie was in the office the week before here. I was like, look, we're doing this Postgres thing. There's gonna be good things about it. The world is shifting this way. Why don't you become an early design partner and work with us? And then within a week, they were onboarded.

And for us, selfishly, you get people that actually know how computers work in a very deep level. Using your product to the extreme is fantastic for getting really good feedback. And so it's a really good symbiotic way of getting great feedback, giving them a boost, like providing them value and them providing us value. And they're just fun people, and we share an audience. So it's really nice.

Yep, yep. So I mean, you said no to Postgres for a long time, and now you're doing it. Do you have the ability to host any sort of stateful-ish system. And I say ish, you were joking about Redis. Are you guys just going to become the data host layer for all sorts of things? How broad does this operational expertise go that you could specialize in a lot of different things?

I don't know. I think you have to be really humble about what you can do and what the challenges are you could specialize in a lot of different things. I don't know. I think you have to be really humble about what you can do and what the challenges are and what you should be doing. No one gets an infinite license to go and do everything. People who try normally end up building nothing. I also believe in intensity and focus. We're not a giant company, and that's on purpose.

And we really run problems down as a like a tight team. Right? Like you get the tip of the spear. It's much more like a special forces than a standing army. Right? Like there's companies out there that are standing armies and they put 300 engineers on every single thing they want to do. We don't do that. We target problems very, very specifically and use being small and everyone here being very senior and experienced as a way to run problems down. So we put like a lot of people on doing post-graduates to get this done and now people are going back

to you know working on other things and we're working on Nova until I'm convinced that we've done anything good in the postgres world. I wouldn't entertain doing anything else. I will say though, I'm incredibly surprised how many people have reached out asking us to do other data stores. And it made me feel really nice to do that, to hear that they actually like, like what we're doing. Is really- One of the most common ones you hear. Redis, MongoDB, Elasticsearch.

Yeah, I mean, a lot of the other ways, there's a lot of postgres extensions that are doing non OLTP stuff. And people wanna know if we can do them too. That's like stuff we're looking at. We're going to run a few benchmarks on some of those and see if there's any interest from people. But yeah, we're good at certain things.

We're going to stay good at those and we'll see what the future holds. Yep, yep. On that note, extensions, what's your extension story like? If I want to bring in post GIS or any extension off the shelf, can I come bring it to plan scale postgres or is it more locked down like RDS where it's like some approved extensions but not all of them? It's a bit more locked down, but we aim to be able to support everything that RDS supports

essentially. The reason RDS supports essentially. to give people full super user because they could just wreck their own machines. There's like nothing if you like accidentally lock out our automation, we can't help you. You know what I mean? Like stuff like that. So it's like making a kind of pseudo super user story to allow people to run a lot more extensions. There's good prior out there for doing that.

Our intention is if you can do this on like your own laptops, Postgres, we want to be able to make it pretty much possible on planet scale. The Postgres community are just incredibly vibrant and they've done amazing things. We don't want to hamper them. We do hamper you on doing certain things with Vitesse. Like we kind of have to, to go and achieve the things we've achieved. And that's the reason Nova and what the current, like the internal name for the Postgres we've just shipped is Horizon, because we had to do this under utmost secrecy.

Nobody outside the office. And we're in South Park in San Francisco. I mean, you go and have coffee and someone hears Planscale people talking about Postgres, you know, it's going to be gossip. So we had to have a code word. We had to be able to ship JavaScript in the UI that doesn't say Postgres, all of this stuff. So it's Horizon internally, but we just call it Postgres externally.

And then Nova is the internal name for the sharded product. And the intention there is when you want sharding, you opt into that. And if there is trade-offs that we've made you make, you make them then and you're not gonna be mad about it. Cause like you're clearly, you've got a ripping business and sharding is gonna keep that business going.

You'll make the trade-offs then rather than living with them from the beginning, which is one of the mistakes we made with the test. Yep. Yep. Okay. I want to talk about Nova. One last question I have on this is, so you mentioned like at the juice launch, it's like

sort of when you decided, hey, we're really doing postgres. How much of just like the, how much is, how much does, did I say juice? I meant metal. But how much does metal, how much does metal itself, I guess, convince you to do post-grads? Just because now you have this advantage that is gonna be more durable and harder for other, post-grads hosting is a crowded category.

But you have this advantage that's hard for a lot of those hosts to provide? How much should Metal itself convince you to do that and decide to go in with post-grades? We have a cost story and a performance story, especially at those tails, that is going to be hard for other post-grades providers to replicate. Metal, I'm sure, will get copied in the fullness of time. Again, it's like no one has, you know. But then that will take two, like I mean, I'd be really suspicious of people that were shipping that soon. Going from like nothing to that, I'd be a little bit worried.

Like they're all losing data anyway without doing that. So I mean, I just don't know. But it will happen, right? Like again, you know, it's just it's time, computers, money, whatever people want to spend to go and get that done. Will of course be three years ahead and be doing other things, you know, and we'll have our track record of uptime and customers.

That's the main, you know, that's the thing that's most. So I think Metal projected a message big enough to attract people and was tempting enough to get them to come and talk to us. And then hearing their stories is what truly convinced us. Like I was just shocked, just absolutely shocked to what I was seeing. And even in my inbox right now, people are just sending me essays about the experience they've had elsewhere. And, you know, we were talking to one company, and we were like, you know, would you try it? Would you be interested? And they were like,

we run on X platform right now. And so it literally can't be worse. So yes, you can just take it and get the workload. And so yeah, I mean, it was more that it was just like speaking to everyone. And being like, wow, I mean, just actually having more than three nines of uptime is a differentiator. You know, and, you know, by looking at Aurora Limitless, looking at all these products that are out there and people's lived experience. So it was the customer that convinced us truly. And that's like the most wonderful way of doing things.

Like why, like let people tell you what they see you as and if they believe you can provide them value, take an honest stab at that. We just tried to be humble about it. There was no point in going in pretending we're like God's gift and that we should have to earn that. If we feel we can earn it, try and we're trying. Yeah. It helped that MetaLaunch to have those customers with the charts showing both cost and performance. And same thing at this launch, showing convex. Like, hey, they're running on Aurora. That's like the flagship database from Amazon and still seeing those P99 changes that they were getting just a lot lower and a lot smoother curve on that sort of stuff.

So yeah, I mean, that helps for sure. Let's talk about Nova. You talked about Nova. that sort of stuff. So yeah, I mean, that helps for sure. Let's talk about Nova. You talked about Nova. So currently, Planescale Postgres is uncharted. Nova is the sharded project that you're all working on. It's not going to use the tests that you said, which is interesting. The test is like this 15 year old project. And so in some ways, that's good.

It's like you've learned a lot. It's paved the way, but it's also bad because it's going to take a while to get that kind of maturity. Why did you choose not to use Vitesse? I think in life, in company development, company strategy, you can really get sentimental about things you've done and try and shape and shift and leverage stuff you've done in the past. And it can cloud you against making the good decisions. Vitesse is as much a collection of code

as it is a collection of learnings. And you can build the Vitesse for postgres without the actual code. So Vitesse, from a practical standpoint, is built for MySQL. It leverages a lot of what MySQL does exceptionally well. MySQL does some things better than Postgres and some things worse. Postgres does some things better than MySQL and some things worse. And you should do things from first principles And you should do things from first principles and decide like how do you get to the same, how do you achieve the net result,

though the result that the test gives customers, which is like linear horizontal scalability for that workload, you wanna achieve that for Postgres and that's it. Like you're not wed to to how that is done. It is just, you do it, right? And so we very quickly realized that it doesn't get us much further ahead to just cargo-coat what we have in Vitesse,

even though it's going to be the same people who build and maintain Vitesse and their learnings, it's going to be special to Postgres, and there's going to be things people want. Vitesse is incredibly mature and has so many things in it that not even is available in the planet scale cloud product that are just not going to be necessary for a while to get within and like why pull that project in another direction when it's healthy, it's supported by us, it's well funded and we can start a new thing that is

discreetly different but has the same goals. Yeah, yeah, absolutely. So it's more just like, hey, Vitesse is... It's not that it's so MySQL specific that it'd be hard to untangle that, but also more just like, it's so big, it probably got backward compatibility back to who knows how many versions and things like that.

It's got all these features that you don't want, where it's like, you know, it's bigger and more than we want at least to start with Nova, that it's better to just sort of start from scratch and clear out some of that crop almost. Yeah, I mean, just, you just do things differently when you do them again. And yeah, I mean, Vitesse is just an incredible piece

of engineering as it is, right? Like, and it will continue to achieve. Like, I think it will still remain for a very long time, impossible to outscale it with anything else, right? And so we see people still like, you know, AI companies this minute are migrating to the test because there's just nothing's coming in any timeline that's going to outscale it. And that's great. We will continue, like we're continuing to

push that scalability even further to take on even bigger workloads. That should be the main goal. And it shouldn't be in any way interrupted by another project. And so that's why we're choosing to do it this way. And Nova will be awesome for Nova's reasons. And it will be a purely plant scale. It'll be the way plant scale does things manifest for Postgres. So we're very excited about that. And the other thing is crazy.

I knew this intuitively. I've run engineering teams for like 15 years. I knew that the real hard work was like learning what you need to learn, not the actual production of the code. But I was surprised at how big that difference was. Like the team are getting so much done so quickly just because they figured it out first time with Vitesse and the operator. Like you know the locking order for doing this exact thing.

Like just do it this way for Postgres. And yeah. I mean, also like part of our architectural principle is it's a shared nothing system that gets you to the real storage engine as fast as possible and can converge in the happy state for that storage engine quickly. So if you really think about like the unit of scale

is three nodes in a shard, right? And they're happy when they replicate the way they replicate. And, you know, when a certain set of conditions is always met, then you are in a very robust place. Our goal is to keep every shard in that state continually and get you to that from whatever transitional state you're in to that state. That takes knowledge and learnings then applied to the domain specifically. And so it's our principles that we're not going to try and do some. We toyed with the idea and threw it out very quickly.

The idea of doing some sort of post-growth translation layer that is for tests under the hood, that violates our principles of using the real storage engine. Yeah. Are there any high-level architectural or maybe even That violates our principles of using the real storage engine. Yep, yep. Are there any high-level architectural or maybe even feature differences with the test that you're thinking right now? Just like, hey, we're going to do this part differently?

Are you going to follow that pretty closely? Yes, and we'll be sharing a bit more of that as we move along. Like, the plan right now is we're working with some very large Postgres customers that want this. They're migrating to the unsharded thing and they may like some of them have self sharded postgres, right? So they'll change their self shards from like Aurora like clusters to Vitesse, no, sorry to planet scale postgres clusters. And then we work with them to like build in the middleware that is Nova to kind of give them an incremental path. scale postgres clusters.

deep relationship and we're building for them. So we've got like a bunch of design partners that we're working with. Cause that's again us, you know, we're like, we could like knock out in like a kind of out there version of this super quickly and it wouldn't mean anything to us. You know, when we announce this, it will be here is Nova. Oh, and by the way, X giant companies already running on it and it was designed with them. Yep, gotcha. And do you have a timeline for getting this out or is it too hard to know at this stage?

Too hard to know. I don't, software, timelines and software are just bullshit. Like, you know what I mean? Like we might, our plan's going never, chipped to timeline and quite often we're early. You know, like honestly, like it's just, if you set the wrong date, you're gonna, it could be later than you could have got it done. never chipped a timeline and quite often we're early. If you set the wrong date, it could be later than you could have got it done. It could have been too aggressive and then you screw things up.

When we surprise ourselves basically is like the way we launched Metal last time was we just spoke to a load of customers, showed them what it could do. And they were like willing to migrate. And that was like, okay, this is the objectively the best way. Like we're not running out of money. We're not like, um, we are a profitable business. We have time. We're going to do it the right way. We're not like desperately trying to like limp forward to the next raise and have to like rush something out there. Uh, we'll build it and it will come out as the, like the plan scale quality that people expect.

Yep. Yep. Um, why haven't other sharded post-growth solutions taken off in the same way that we tested it? Like there's like, situs, you know, in some sense. And then there's like the proprietary ones, I guess, like Aurora and cockroach,uga Byte a little bit. I guess just like, why haven't those sort of taken off in the same way as the tests or am I wrong? Maybe they have.

Yeah. They have been like their own ways, right? Um, some have been, so Postgres is really interesting. There's not like a, there's like companies doing real Postgres and there's like fake ones like D SQL is fake. Um, Cockroach, they're like faking out you goodbye effect and they have different goals like that they're using the right protocol and they're using the postgres protocol but they're not running Postgres under the hood. I don't know it's hard to

answer that you know, Cytus I don't think doesn't go kind of far enough in terms of you know, relieving Postgres of some of its duties when it shouldn't be doing the things it's doing. Although it has been pretty successful. Yeah, it has. Okay. Like, yeah, I just don't have a sense. Like, cause did Microsoft buy Sinus? Is that right? Yeah. Okay. You know, I think it's a point in time thing as well. The reason the MySQL ecosystem is so mature is because the former generation of company were all growth companies

while it was happening. So we would all get together in San Francisco. And the MySQL user group was Facebook, Yelp, Yahoo, Google, GitHub, Twitter. And then we do all just be like drop box. Yeah, I mean, yeah, dropbox. So yeah, we're like, okay, so we are like the top 100 websites on the internet and like 50% of the internet's traffic in one room, talking about one database and sharing war stories. It gets good really fast. Postgres is now that database, but it's the beginning of that journey, right?

Like we didn't, there's companies that have already started and died and are going to die or whatever, because they came into this thing early. We're playing in the fourth quarter and showing up with something like Mature and Additive and we're going to get to work with a load of growth companies that are growing. And we're still not seeing post-growth databases out there that are anywhere near the size of some of the large sharded MySQL ones, but they're heading that direction at the right time. So it's kind of a timing and maturity thing as well. And like the postcode replication story is getting better and improving.

That will, you know, replication is a very key thing when it comes to making sharded systems work well. So a lot of it's just like timing. I mean, some people have been too early, like being too early is as bad as being too late, right? There's just people too early trying to try this. It's hard to say. We don't even know if we'll be successful at this. We're just we're going out and seeing. Yep, yep. Sort of on that same note, so Shugu, who's one of

the creators of Attest, founders of Planet Scale, recently announced he's going to SuperBase to work on a similar type thing, multigrass, right? Sharded, post-grass. I guess, first of all, tell me, remind me like your overlap with Shugu, because I know he was one of the founders. I guess, did you guys overlap a couple of years before he left? We overlapped by months, really. Not long at all.

So Shugu's not really worked at PlanetScale for like four years pretty much. I mean it's great to see more things happening in the community quite honestly. Like I mean I wish everyone luck on going and doing those things. I'm sure we'll maybe converge somewhere in the future. It's an open source project that is being built out in the open, right? And so that's going to have great benefits. We're taking a different approach to doing this and going down the kind of like more the actual original path that Vitesse took, which was Vitesse was private at YouTube and

built for YouTube scale before the world saw it, right? And that's how Nova will be built too. But this is a different approach. And like we might be entirely wrong, they might be entirely right. As long as like the world of Postgres wins, I mean, that's all that's good. And at the end of the day, like, we guard our operations and how we operate more closely than we do. Our open source, like Vitesse is out there to be open source. People can do whatever they want with those goals. At the end of the day, it's can you monetize a business hosting

databases? And that's what we're out here doing. Yep, yep. I also remember in our first episode, I think you mentioned Paul Coplisone at SuperBase as one of the Postgres founders you really respected. And now your terfs are starting to collide more, right? You're doing Postgres, he's doing sharded database.

I guess, has that been hard? Does it feel like you're more rivals now? Or you say, well, I would like to have a friendly relationship. What does that look like? I think, you know, as long as everyone's like respectful, I don't think you need to have these crazy rivalries. Like I still have a lot of respect for what they do.

They are enabling so many people to build applications and developers and building a very successful business. I have more respect for people going out and doing this stuff because it's really hard. Founding companies is really hard. Building companies is really hard. Building companies is really hard. So I tend to respect people that are doing those things way more, even though it doesn't maybe seem that way, and everyone's supposed to be rah-rah upset at each other

all the time. I just don't see a point in being that way. The database world is so huge that there will just always be winners. And there's so many reasons that people choose databases that are just intangible to all of us, that you're just going to get many, you know what I mean? There's just going to be many different versions of this. Um, they've definitely done incredible things for the Postgres world. I think they've been very good stewards of other projects within Postgres,

right? Yeah, I mean, all power to them. There's some, there's some day like Postgres companies I don't respect. SuperBase is definitely in the crowd that I do respect. Yeah, yeah. I also want to talk about just like some Postgres industry news, or I guess database industry news, but, but Neon getting scooped up by Databricks for a billion dollars, Crunchy getting scooped up by Snowflake for 250 million, crazy time there. I guess like, it's interesting to me

that these like giant sort of OLAP-y type providers are buying OLTP. I guess like you have a better look at the sales cycle and how stuff works in big companies. Are companies looking to buy Oltb databases from their o-app providers like what's the What's like the synergy there? I guess yeah, I wonder that actually First of all, it's like M&A activity in a world you're in like it's good. I mean it sets

Different precedents. It's like nice to see that activity It's nice to see that activity. It's nice to see people building things that people like and making money from doing that. Like it's really good. I do one, like the OLAP space is very different. It feels much more like frenetic and their constraints are very, very different. I don't know if being good at one gives you license

to try and be good at another, but maybe money and time helps, right? You know, I don't know if being good at one gives you license to try and be good at another. But maybe money and time helps, right? You know, I don't know. You know, I tweeted about, you know, engineering cultures, right, and how things are innate from the very beginning. I don't know if OLAP companies have certain DNA that makes being good at OLTP. We don't have the DNA that necessarily means we'll be good at OLAP, you know? Like, it's just different constraints,

a different world, a completely different world. In some way they have it, we like, there's a funny disconnect between the OLAP and OLTP communities. I think we, like the OLTP sees the OLAP world as not having any real problems, and the OLAP world sees us as just being boring and fragile and like way too caught up with how long a query takes

and things like that. So it's just a very interesting different cultures and watching them combine is, you know. Yeah, yeah, I agree. And you had that operational or like the cultural aspect. That's interesting. Yeah, obviously it'll be interesting to see if, you know, especially Neon or whoever will sort of be able to build that within those existing LAP cultures.

I mean, yeah. I mean, acquisitions are hard to get right in any way at all. I mean, just like, so it just, I mean, the Databricks team have built an amazing company in a building business and now they'll take on the challenge of making acquisitions successful and they may or may not do that. We just, you just don't know. Yep, yep. I guess the, and the interesting bet on,

I think especially Neon especially is like, hey, with AI agents and things like Levelable and Bolt or all that stuff, it's just like, we're gonna have a need for lots of tiny, cheap, maybe somewhat slow databases, comparatively slow, not going to have the Playment Scale performance, but good enough for those use cases. What do you think of that bet? Is that something that is going to play out or are we still going to... We're not going to have as much tiny specialized little apps everywhere that need just sheep free databases essentially. I think we're entering the plastic apps era, situation apps that don't need long term maintenance

and don't need, I've got a ton of apps now. I've just like vibe coded together and don't need high availability, don't need much. We're never going to optimize for that because we optimize for something different. And that's fine. And people should, things should be built for the use case they need. Like the unfortunate thing about database engines is being good at one makes it not so easy to be good at another, right? So you have to pick.

I mean, you get to the world where everyone picks their trade offs. And if those make sense, like it's the ones that pretend there's no trade offs are the ones that are really stupid. You know, we we tell you our trade offs, and if they work for you, then they work. And then we're just like, we don't we're not ashamed of them. So yeah, the thing I don't fully understand is why SQLite isn't the winner in that world. I love SQLite. Yeah, interesting. Like pure embedded SQLite? Yeah, I said this, I was talking about like people don't understand the difference between a database engine and database server. Right, like SQLite is an incredible engine. I mean, it's everywhere. Like how many personal,

how many SQLite databases are personally attributed to you alone? Like hundreds, maybe thousands, right? Truly. Yeah. How many run on your Mac right now? It's a marvel of engineering. So much of the problems that we deal with in the database world is concurrent,

is to enable concurrency. MVCC is all because there's more than one client and they can clash with each other and they need to have certain guarantees and properties. If you don't need that in this agentic world, then why not just use SQLite? I don't know. I've been wrong about so many technologies. There's some that have then I felt like, yeah, that just doesn't seem to kind of obey the rules of physics or why things could work, but we're too early to know. I think AI is amazing.

I think agent use is amazing. The tech we're seeing, the things our AI customers do, it's just incredible. I'm really bullish about that. I don't... But agents, you call them what they are, it's like software development. They'll go off and do stuff. They're a great way of building software. At the end of the day, either the world shifts so fundamentally, or there's just always going to be one, like if a certain product, there's going to be one monolithic large store of state, which will be like a large sharded database probably. And that has the way that's built, the software

that runs on it with agents, agents accessing it still has no bearings on the constraints of that running. So yeah, I just, I don't, a lot of it I don't get, but there's like tons of hype and interest around it. And you know, I'd hate to call something out. The moment you start, I always worry about this, you know, the moment you kind of harden to new technologies is when you start to miss things. Why is Mark Zuckerberg an incredible founder? I mean, like nothing sacred to him, you know, it's just like what's the world look like today and what does our

position in the world be? I just don't want to, that's why I've got this hijackable loop in my brain that crypto used to hijack constantly, which is everyone that stops saying, like everyone who eventually like locks up and says that new tech isn't coming, you're dead then, you're like, you're finished. So then like people are using it and it just didn't feel like NFTs like that doesn't seem right or real to me. Like that can't, but maybe, and then back around the loop again and then, you know, and it's just, it's really easy to like hijack my brain on that. So like I'm always just very open to it being a complete future and, you know, we might miss part of that by optimizing for what we've optimized for. Yep. Yeah, I had that same loop with crypto where I'm just like,

I just don't see the use front. And then, but with that AI, you can like so clearly see that it's helpful in so many ways in doing awesome stuff. That was incredible. Like impact on the data stuff aside, like, yeah, it's clearly, yeah, just helpful in ways that crypto is not. So, yeah. Yeah.

I think AI expands the what's special about planet scale, which is if you like, if the cost of doing software development is so low, then it really actually amplifies more the opinion and taste that you have, right? Like, truly, I mean, if, if anyone can just like enable themselves to build software a lot more quickly, then it's actually about the more intangible things of what they try and build and how they can respond to it failing in the middle of the night. So it actually becomes more so about, like we've seen this with aircraft pilots, like the more autonomous planes have got, the more they have to be good during a crisis. Like it more has gone into safety science checklists

and because the kind of the letdown of the system is much bigger when it's too- So rare and unique, yeah. Correct, like there's like, there's famous crashes from airlines where they've, you know, it's in run state three, which is fully automated, and then it drops to run state two

and the pilots don't realize and don't know that certain safeguards are gone now. Right. That has caused a lot of issues at the end of the day, like models are not perfect. It's going to still take people with deep ingrained knowledge to figure out like the matter of what's wrong and fix those things. So I'm nothing but excited for this AI world. Really excited. Yep. Awesome. Well, Sam, always a pleasure to have you on. Thanks for coming on. Like I was super jacked about the Postgres stuff and glad we could chat again. Yeah. Thank you for having me. Thank you to your audience as well. Like, you know, the feedback we get when we do these is awesome. It's just like such a cool group of people to come and chat to. So thank you for having me. Thank you to your audience as well. Like, you know, the feedback we get when we do these is awesome It's just like such a cool group of people to come and chat to so thank you

Awesome, that's great I would say on my end the one thing I ask is like keep sharing those like customer stories are always awesome and like that really good, you know engineering blog posts and stuff Ben's doing and then like the Just like the metrics and interesting things you're seeing in across these providers like, man, keep sharing that stuff because it's so good. We will. Awesome. Thanks, Sam. Thank you.