Operational Excellence Is the Moat with Sam Lambert

This is the 3rd show, isn't it?

This is, yes. You're the 3rd-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 Meadow that we were gonna 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, there's not really that much IP. It's like all about how you, 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 Vitess, 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. So 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 3rd 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, now you're a Postgres provider. We had to get you back on talking about your new announcement. So lots to talk about today. But I guess maybe just like for everyone, get us updated on, on what's been going on with with PlanetScale and this recent announcement you have?

Yes. 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, PlanetScale's been famously kind of a Vitess/MySQL company. We are the maintainers of Vitess, Vitess 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 post, I say, never say never, because I mean—

Yeah. And 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 convicted, actually. We were wrong, but we were convicted. Yeah, it's been really interesting. We had this weird moment. Actually, we knew the day of Meadow that we were gonna do Postgres. So we shipped Meadow, And that announcement went really well. We announced it with a few of our customers, Intercom, Depot, and Cash App, right? All very large applications. And we showed us kind of dropping their P99 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. Like, databases are like, well boring on their own. They're hard, but no one, you're like, 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. Because like, I think people are very tired of the type of vaporware that's out there right now. People's dopamine receptors are getting burned. So we tried to like 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 very—

Wait, on the day of the, on the day of the Meadow launch, you're saying?

Yes. People just reaching out.

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. And some of them were able to achieve that really easily. Like, some were just kind of using Drizzle or Prisma, and it wasn't much of a conversion, and they were going down on their current provider anyway. So, like, who cares? Just, like, migrate. And yeah, we were seeing people, like, you know, we had people in the office staying up till, like, 2 in the morning helping people migrate because they wanted to move over. And, you know, we realized that Just people love Postgres. Just 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 Metal, you knew you were doing Postgres. Like, I wanna know the timeline of like, when did you think, 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 kind of debated it back and forth. The thing I was very clear about is that we'd have to bring something different. Like, there's lots of good companies doing Postgres. I mean, there's lots of great stuff in the ecosystem, and it's a very dynamic community. I don't want to 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 the, the, when we definitively knew it was happening was the same day of the Meta 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, 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. Uh, and so pretty much like 2 days after, We told the company, we said like, we're gonna do this. Um, clear your— we basically said, clear your plates. Like, there's 2 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, 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, like, we, like, this is why, what we want to do. We may not even do it. Like, let's just suspend all belief. And just try for a week to see if we can get Postgres up running in PlanetScale production and connect to it externally. We had that done by Tuesday afternoon. Like, that was the Friday goal. Like, if we can demo that, and we told people to split off in teams and try and figure things out that we figured out at PlanetScale 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 demos, all hands on the Friday, took 3 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. We, we, the way we worked was really fun, and we're gonna 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 a loop. In a loop. Yep.

And then, okay.

And then, yep. Sorry. And then, so how, how, I guess, how does PlanetScale support it? Right. Because PlanetScale, in some sense, the first time we talked, I was like, hey, PlanetScale is kind of 2 things. It's like Vitesse over here, but it's also like this developer experience and operational stuff as well. That's like useful for a lot of devs. Like you can run unsharded MySQL on PlanetScale. 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 PlanetScale ecosystem do I also get with it? Like, is it using VTgate 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 Vitess product that we're undoing in this world. So for the longest time, we were kind of using Vitess to host unsharded 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 Vitess's trade-offs. Um, even though you didn't need them. And that was like more difficult for people to go and adopt the product, um, that way. It produces exceptional results for people who need sharding. And we're not apologizing for those trade-offs if you need sharding, like we're giving you incredible things in return for like taking away very little. Um, 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 PlanetScale does. Vitesse is an incredibly well-run open-source project run by the PlanetScale team and contributed by a number of very significant and fantastic companies. And it's just a really good project. I mean, it's just a very, very mature CNCF project, and that's out in the open, and anyone can go and use Vitesse to do whatever they want with it. And a lot of people do. In fact, every now and then you just see a project 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 sauce of PlanetScale and the thing that people pay us for is our operations and the software that underpins those operations. So like our operator, the way we use Kubernetes and the way our infrastructure is deployed is incredibly unique and incredibly resilient. We actually tweeted, oh, not 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 incident and sat 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 and 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, like, 5-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, like, the bare bones of, like, what the kernel did when this happened to make sure that that can never happen again. And we're on such this, we're on such a long tail of like things that could go wrong. Um, and we've, we've, it's, it's kind of like airplane maintenance, right? Like, you know, Cessna engines have just got like, again, probably hundreds of millions of hours. Like, you know, just, they just, they, they only fail the known ways and can be repaired. And that's kind of how PlanetScale is, you know, there's like 2 ways to fix a problem at PlanetScale, a PRS or an ERS. A PRS is a planned repairment, 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—

And just all this— oh, go ahead. Yeah, go ahead.

I said we kill nodes to fix all problems. Like, if a node's misbehaving, you don't just try and 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 are 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 PlanetScale online, and people have done that. We have a high availability proxy that buffers queries and allows you to like change configuration, like on the fly without interrupting, like 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 like our standard.

Yep.

Yep.

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. And I totally love that. And like, 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 going to 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 operational posture, that's the only durable advantage you have in databases, really.

100%. Yeah, like you said, everything can be copied. We can all read the Dynamo paper, we can all read the Aurora paper. 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, like active, active, like dual, like dual, like quorum writes, for example. They're like, oh, Cockroach can do that where you write to both 2 nodes at once. Like, we would never do that. Like, 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 and more available. To what end do you mess around with this stuff? It's not 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, like, that operational aspect, like, it gives you a durable advantage in Running those databases and having the availability and reliability and all that stuff, but also, like, that's what's powering Metal. Like, you guys could have never done Metal if you weren't that operationally good. Like, so many databases have to say, we're gonna use EBS to, like, sort of outsource some of our durability and reliability, because that's, like, you know, running on local disks is too hard for us to, like, it's just too risky for us. But, like, now that you have that operational advantage, you can run on local disks 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 CTO, Nick, which is like the true failure rate of EBS, which is we deployed so much EBS that we get this, like, global viewpoint on how it actually works and behaves. And even then, it's not perfect. I heard of one of the Postgres startups, one of their customers came to us, and said they lost $500,000 because that company managed to wedge, like, a deprovisioned EBS node. It's like, EBS has done everything for you, and you still screw that up. 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 those intangibles in your culture that make that possible is, you know, and like, shout out to the PlanetScale team for being who they are and making that all You got it.

Yep. 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 rate And things like that are. So, just you all having, like, the perspective on that and sharing that is, again, why 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, you know, our 2-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 natural, lead 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 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, you know, we would rather spend 6 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 mean, it was, I was at an event last night and people just come up and they say, you know, your blog is phenomenal. And 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. And so, you know, it became really awesome, but it just felt so nice. And 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 just luck you're in that industry, the way that stuff works. But when you can, you should. It's fun.

Yep. Yep. It is cool. Okay. So going back to, again, PlanetScale Postgres and what I get from it. So I guess like the one thing I think about, I asked about VTgate earlier, but the one thing I think about with Postgres is like connection limits and just like, all that stuff. Is there, are you doing any like proxy or anything like that? Or is it just going straight to my Postgres instance and I have to sort of 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, I mean, there's a million reasons why you'd want to go directly to the node. But we also have ps_bouncer, 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 PgBouncer is and does, and there's work going on. See, again, this is 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 PlanetScale 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 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. I was reading some other Postgres company, their proxy, and, like, the P99 numbers of that are just horrifying. Like, just even half that number would just kill most of our customers' queries, like, would be a nightmare. So, it's those kinds of things that are really additive that people don't really understand nor appreciate, and don't have to, But it nets out as being much quicker. So we have these benchmarks 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 like just get 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.

Yep, 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 wanna read from the primary or replica, or how's 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 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.

Yep. Yep. 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 write, the like read-write skew there on that?

Yeah. Yeah. Now, Our kind of customers often do skew towards being write-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, what we've observed in the AI world is companies that are like a lot younger and smaller producing a lot more writes than a company 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. Like, there's, you know, they kind of, you can imagine you're a company that uses like some of the large models that are out there from the model vendors, but you want to eventually produce a model that's kind of yours or closer to being yours. You want to store like 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 necessarily model. It's not going to be model data. It doesn't even going to be vectorized necessarily, but it's just like metadata that's really useful. Like, I mean, look at like, I don't know, the GitHub dataset, for example. It's something, but like the pull request comments, that's useful. Like, 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, that's a long-winded way of saying, yes, they're doing a lot more writing, and that means they're hitting problems a lot sooner because writes, that's where like all the scaling reads is like really easy. Can't cache writes, you know.

Yep, yep, exactly. Okay, what about other features of PlanetScale? Do I like backup and 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 Insights is there.

We have to finish off a few bits to, like, have it as mature as it is for the Vitess product. Branching is on its way, but we chose to ship sooner. The Postgres schema change story is better than MySQL's by default. Vitess makes it extremely good on top of MySQL, rewind and all these kinds of things. And we want to bring that to the Postgres as well. What we discovered, and we spoke to so many people, like, we sent so many NDAs, it was unreal. Like, probably at least 50 or 60 people knew we were doing this. It was just all under NDA, basically. And so we were talking to all these people. And what we found is they had, like, a schema change workflow that they kind of liked or weren't that mad about, whereas the MySQL world doesn't have that. MySQL has a much worse schema change story. So we thought to ourselves, I mean, there's so many people who want what we do in terms of performance and cost that holding back, you know, just shipping those things, it's 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 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 into PlanetScale Postgres? And do you have a timeline for GA on this?

Yeah, so it's weird. It is GA, 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'll give you access after this call if you wanna try it. The way it— what we would say now is like private preview of the production thing. Like people, companies making revenue run on this thing. It is production ready. We are constraining access again, because it's, 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, you know, seeing the results for their customers just magically getting faster. And so yeah, it's, it's, we, we're working really fast to, to fully GA. There's just a few things that we want to iron out, um, 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 any, you know, on the second page we ask for like an expanded set of information. If you fill that out, um, 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. And, you know, it's just, 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 that 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 Convex 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 like more on top of a database. And then they're also like using you, I guess. Like, what was, what's the story there?

I've been watching Convex 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 PlanetScale team, which is a bunch of them have run hyperscale databases. So the team behind Convex ran the sharded MySQL at Dropbox, which is like 15,000 servers in like a single MySQL cluster. That's really—

Is that Vitesse at Dropbox or is that their own sharded thing?

No, that was their That was their own storage layer. We have some ex-Dropbox people as well. So like Convex was kind of like people our 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 chatting to them because they were looking at moving to MySQL Metal. And because, you know, they built, they were previously on RDS, you know, they're innovating in a place that doesn't require you to go and have to like rewrite the underlying storage engine of your product. Like you can just you should build it on things that work. In the same way Facebook runs the world's largest graph database on China MySQL, they run a massive message queue on China 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, you know, we went over to their office and said, like, 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, you know, there's gonna be good things about it. Like, the world is really shifting this way. Why don't you become an early design partner and work with us? And then within like 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 like the extreme. It's fantastic for getting really good feedback. Um, and so it's a really good symbiotic way of getting great feedback, giving them a, like a boost, like providing them value and then 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, like, you were joking about Redis. Are you guys just gonna become the data host layer for all sorts of things? Or, like, what is that? How broad does this operational expertise go that you could sort of specialize in a lot of different things?

I don't know. Um, 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 like gets an infinite license to go and do everything, right? Like people who try normally end up building nothing. I also believe in intensity and focus, right? Like we're not a giant company and that's on purpose. And we really like run problems down as a, like a tight team, right? Like you get the tip of the spear.

Yeah.

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 to make— and 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 Postgres 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 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, like, 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 gonna run a few benchmarks on some of those and see what people If there's any interest from people. But yeah, like, I, you know, 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 PostGIS or any extension off the shelf, can I come bring it to PlanetScale Postgres or is it more locked down like, you know, 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 does that, it's one of the number one ways people got hacked, is they would just install extensions that they didn't, that were untrusted, and then it just starts like S3ing their data. You know, that's not good. We don't want people to be able to do that. We also, we're working on a, like, that's one of the things we're getting ready for GA. It's like a really good superuser story, right? Because we don't want to give people full superuser 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 superuser story to allow people to run a lot more extensions. There's good prior art out there for doing that. Our intention is, if you can do this on like your own laptop's Postgres, we wanna be able to make it pretty much possible on PlanetScale. The Postgres community are just incredibly vibrant. and they've done amazing things. We don't wanna 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, you know, we're in South Park in San Francisco. I mean, you go and have coffee and someone hears PlanetScale people talking about Postgres, you know, it's gonna 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, because 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 Yep.

Yep. Okay. I wanna 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 does—

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 Postgres? Just because, like, now you have this advantage that is gonna be more durable and harder for other— Postgres hosting is like a crowded category.

It's true.

But you have this advantage that's hard for a lot of those hosts to provide. How much did Metal itself convince you to do that and decide to go in with Postgres? We have a cost story and a performance story, especially at those tails, that is gonna be hard for other Postgres providers to Um, to replicate.

Yeah. So Metal, I'm sure will get copied in the fullness of time. Again, it's like no one has, you know, um, but then that will take too, 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 that they're all losing data anyway, um, without doing that. So, I mean, I, I just don't know, but, um, it will happen, right? Like, again, you know, it just, it's time, computers, money, whatever people want to spend to go and get that done. We'll of course be 3 years ahead and be doing other things, you know, um, 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 at 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 up, get the workload. And so, yeah, I mean, it was more of that. It was just like speaking to everyone. And being like, wow, I mean, just actually having more than 3 nines of uptime is a differentiator. You know, and, you know, right, 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. And so we were really, We just try to be humble about it. There was no point in going in pretending we're like God's gift and that people, you know, we should have to earn that. And so if we feel we can earn it, like try, and we're trying.

Yep. Yep. And it helped that Meta launch to have, you know, those, 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, from Amazon and still seeing like those P99 changes that they were getting just like 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. So, currently, PlanetScale Postgres is unsharded. Nova is the sharded project that you're all working on. It's not gonna use Vitess, you said, which is interesting. Vitess 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 gonna 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 kind of shift and leverage stuff you've done in the past, and it can cloud you against making the good decisions. Vitess is as much a collection of code as it is a collection of learnings. And you can build the Vitess for Postgres without the actual code. So Vitess, from a practical standpoint, is built for MySQL, 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 decide, like, how do you get to the same— how do you achieve the net result, the result that Vitess gives customers, which is, like, linear horizontal scalability for that workload? You want to achieve that for Postgres, and that's it. Like, you're not wed to, like, 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 cult what we have in Vitess, even though it's going to be the same people who build and maintain Vitess, and their learnings is going to be special to Postgres, and there's going to be things people want. Vitess is incredibly mature and has so many things in it that not even is available in the PlanetScale 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, Vitess is— it's not that it's like so MySQL-specific that it'd be like 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 to 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 cruft 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? Um, and so we see people still, like, you know, AI companies this minute are migrating to Vitesse because there's just nothing's coming in any timeline that's going to outscale it. Um, and that's great. We will continue, we're 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'll be purely PlanetScale. It'll be the way PlanetScale 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 3 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, like, learnings, then applied to the domain specifically. And so it's our principles that we're not gonna, like, try and do some, you know, we toyed with the idea and threw it out very quickly, the idea of doing some sort of Postgres translation layer that is Vitesse under the hood, and that violates our principles of using the real storage engine.

Yep. Yep. Are there any high-level architectural, or maybe even, like, feature differences with Vitesse that you're thinking right now, just like, hey, we're gonna do this this part differently, or are you gonna 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, for tests, No, sorry, to PlanetScale Postgres clusters. And then we work with them to build in the middleware that is Nova to kind of give them an incremental path. So if you want sharded Postgres from PlanetScale, the quickest way to get that is move to unsharded Postgres, because then we have your queries, we have a deep relationship, and we're building for them. So we've got a bunch of design partners. that we're working with. Because 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 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 plans go, we never shipped timeline, and quite often we're early. I mean, like, honestly, like, it's just, you, if you set the wrong date, you're going to, you could, it could be later than you could have got it done. It could have been, you know, too aggressive and then you screw things up. Like when it's ready, like when we surprise ourselves basically is, is like, it's like, well, 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 app, objectively the best way. Like, we're not running out of money. We're not like, um, we have 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 PlanetScale quality that people expect.

Yep. Yep. Why haven't other sharded Postgres solutions taken off in the same way that Vitess did? There's Citus, in some sense, and then there's the proprietary ones, I guess, like Aurora and Cockroach, Yugabyte a little bit. I guess, just, why haven't those sort of taken off in the same way as Vitess? Or am I wrong? Maybe they have.

They have, in, like, their own ways, right? Some have been— so, Postgres is really interesting. There's, like, companies doing real Postgres, and there's, like, fake ones. Like, dSQL is fake. Cockroach, they're, like, faking it out. Yugabyte, they're faking it out. And they have different goals. Like, 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, Citus, I don't think it doesn't go kind of far enough in terms of relieving Postgres of some of its duties when it shouldn't be doing the things it's doing, although it has been pretty successful.

It has? Okay. Yeah, I just don't have a sense, like, because did Microsoft buy Citus?

Is that right? Mm-hmm. Mm-hmm. Yeah.

Okay.

I think it's a point in time thing as well. The reason the MySQL ecosystem is so mature, It's because the former generation of companies 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'd all just be like—

Dropbox. Yeah. All the—

yeah.

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 gonna die or whatever, because they came into this thing early. We're playing in the 4th quarter and showing up with something like mature and additive, and we're gonna get to work with a load of growth companies that are growing. And we're still not seeing Postgres databases out there that are anywhere near the size of some of the large sharded MySQL ones, but they're heading in that direction at the right time. So, it's kind of a timing and maturity thing as well. And, like, the Postgres 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. don't even know if we'll be successful with this. We're just, we're going out and seeing.

Yeah.

Yeah.

Sort of on that same note. So, Shugu, who's one of the creators of Vitess, founders of PlanetScale, recently announced he's going to Supabase to work on a similar type thing, Multigress, right? Sharded Postgres. 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 was—

We overlapped by months, really, not long at all. So, Susuku's not really worked at PlanScale for like 4 years, pretty much. Um, I mean, it's great to see more things happening in the community, quite honestly. Like, I mean, I wish everyone luck, um, on going and doing those things. I'm sure we'll maybe converge somewhere in the future. Um, 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, 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 they might, 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, Vitess 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 Caposone at Supabase as, like, one of the Postgres founders you really respected. And now your turf is starting to collide more, right? Like, you're doing Postgres, he's doing sharded database. I guess, like, has that been hard? Does it feel like you're more rivals now? Or are you still able to, like, 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. So I tend to respect people that are doing those things way more, even though it doesn't maybe, it wouldn't maybe seem that way. And you're supposed to, like, 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 gonna get many, you know what I mean? There's just gonna be many different versions of this. 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, like, Postgres companies I don't respect. Supabase is definitely in the crowd that I do respect.

Yep. Yep. I also wanna talk, like, about just, like, some Postgres industry news, or I guess database industry news, but Neon getting scooped up by Databricks for $1 billion, 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 OLTP databases from their OLAP 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, is good. I mean, it sets Different precedents. It's like nice to see that activity. Um, it's nice to see people building things that people like and making money from doing that. Like, it's really good. Um, I do want, like, the OLAP space is very different. Um, it feels, 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, I, I don't know. I tweeted about 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. It's just different constraints. It's a different world, a completely different world. In some way they have it. There's a funny disconnect between the OLAP and OLTP communities. I think we, like, the OLTP sees the OLAP world as not having many 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. Yep. I agree. Yeah, that operational, or, like, the cultural aspect, that's 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 OLAP 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 and a million 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. The interesting bet on, I think, especially Neon, especially is like, hey, with AI agents and things like Lovable and Bolt or all that stuff, it's just like we're going to have a need for lots of tiny, cheap, maybe somewhat slow databases, comparatively slow, not going to have deployment-scale performance, but good enough for those use cases. Do you think that's What do you think of that bet? Is that something that is gonna play out, or are we still gonna, you know, we're not gonna have as much, like, tiny sort of specialized little apps everywhere that need just cheap, 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, like, I've got a ton of apps now that I've just, like, vibe-coded together and don't need high availability. don't need much. We're never gonna 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 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 mean, I said this, I was talking about, like, people don't understand the difference between a database engine and a 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, It's 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, you know, it's, they'll go off and do stuff. They're a great way of like building software. At the end of the day, either the world shifts so fundamentally, or there's just always gonna be one, like if for certain products, there's gonna be one monolithic large store of state, which will be a, like a large sharded database probably. And that has the, 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. Like, 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, they, you're dead then you're like, you're finished. Um, so then like people were using it and it just didn't feel And 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 like, it's really easy to like hijack my brain on that. So like, I'm always just very open to, um, 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, I had that same loop with crypto where I'm just like, I just don't see the use from it. And then, But with that AI, you can, like, so clearly see that it's helpful in so many ways and 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 what's special about PlanetScale, 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, more has gone into safety science checklists and, and because the, the kind of the letdown of the system is, is, is much bigger when it's so rare and unique.

Yeah.

Correct. Like there's like, there's famous crashes of, of, from airlines where they've, you know, it's in run state 3, which is fully automated and then it drops to run state 2 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 gonna still take people with deep ingrained knowledge to figure out, like, the meta 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.

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 the really good, you know, engineering blog posts, the stuff Ben's doing. And then like the, just like the metrics and interesting things you're seeing across these providers, like, man, keep sharing that stuff because it's so good.

So we will, we will.

Awesome. Thanks, Sam.

Thank you.