Bringing Vitess to Postgres (Interview)

33:22But when it comes to this, like I said, and like, you know, like the shape of people's data is so different and custom that there isn't necessarily a best way of sharding as you guys found. So it's what's best for your circumstance. And so why have a first class citizen when you can just say, no, you're going to, you're going to figure this one out yourself because we can't actually figured out for you. I think that makes a lot of sense. Yeah. The, uh, the thing that I'm now starting to realize, uh, I'm now learning Postgres, you know, like, uh, a little bit more deeply. I find the same ideas still there in Postgres, uh, where indexes are pluggable.

34:04You can plug in data types, you can define operators. So I'm kind of feeling like, you know, oh my God, there's a lot of similarity between you go full circle yeah yeah so it's pretty exciting to see this well friends i'm here with a new friend of mine harjot gill co -founder and ceo of code rabbit where they're cutting co-review time in half with their ai code review platform so harjot in this new world of AI-generated code, we are at the perils of code review, getting good code into our code bases, reviewed, and getting it into production. Help me understand the state of code review in this new AI era.

34:55The success of AI in code generation has been just mind-blowing, like how fast some of the companies like Cursor and GitHub Copilot itself have grown. The developers are picking up these tools and running with it pretty much. I mean, there's a lot more code being written. And in that world, the bottleneck shapes the code review becomes like even more important than it was in the past. Even in the past, like companies cared about code quality, had all this pull request model for code reviews and a lot of checks. But post-gen AI, now we're looking at, first of all, a lot more code being written.

35:26And interestingly, a lot of this code being written is not perfect, right? So the bottleneck and the importance of code review is even more so than it was in the past. You have to really understand this code in order to ship it. You can't just wipe code and ship. You have to first understand what the AI did. That's where CodeRabbit comes in. It's kind of like, think of it as a second order effect where the first order effect has been Gen AI and code generation. Rapid success there now as a second order effect. There's a massive need in the market for tools like CodeRabbit to exist and solve that bottleneck.

35:57And a lot of the companies we know have been struggling to run, especially the newer AI agents. If you look at the code generation AI, the first generation of the tools were just tab completion, which you can review in real time. And if you don't like it, don't accept it. If you like it, just press tab. But those systems have now evolved into more agentic workflows where now you're starting with a prompt and you get changes performed on like multiple files and multiple equations in the code. And that's where the bottleneck has now become code review bottleneck. Every developer is now evolving into a code reviewer, a lot of the code being written by AI.

36:29that's where the need for code rabbit started and that's being seen in the market like code rabbit has been non-linearly growing i would say it's a relatively young company but it's being trusted by 100 000 plus developers around the world okay friends well good next step is to go to coderabbit.ai that's c-o-d-e-r-a-b-b-i-t dot a-i use the most advanced ai platform for code reviews to cut code review time in half, bugs in half, all that stuff instantly. You got a 14 day free trial, too easy, no credit card required, and they are free for open source. Learn more at coderebbits.ai.

37:11So what's different then? It seems like the concepts, the breakthroughs you had with Vitesse, the proxy with the parser and the smart way of handling these key spaces and the bring your own sharding like all this stuff seems like it would apply at least conceptually across to postgres um but i guess at the nitty-gritty it's just wildly different or so the the the part that i'm still uh i'm still trying to figure out is so in other words every idea that exists in with this will just smoothly port over to Postgres. But as you said, there may be details where it may not port as well. So there's a few.

38:02At this point, we have made a few policy decisions. Let's put it this way. The biggest policy decision is this has to be Postgres native. So that part we do not want to compromise, which means that the end product should feel like it should be built for Postgres. So that is one policy decision that we have made. I don't know how far we are going to get there, but that's our North Star of some sort. and the part which means that from Vitesse there are some parts we will definitely leave behind for example anything that's MySQL specific is not coming over what else will we leave behind we will leave behind anything that is legacy in Vitesse anything that we built in Vitesse but continue to support because there are users using it but if you built it from scratch, we wouldn't do it that way.

39:09So that we want to leave behind. And also anything that's not well implemented. If something is, it works, so we left it alone, but it was not well implemented. Given a choice, I would do it differently. So that we are not going to bring over. And everything else we want to bring over for sure. So there are actually, and there's a fourth category, which is if there are things we can improve, we should. More specifically, I do want to improve the high availability story in Postgres because that is currently a big challenge that users are facing. There is no good high availability solution. So that is something that definitely want to improve on the Postgres side of things.

39:59So we'll bring some components over from Vitesse because Vitesse already has some HA components. So we'll bring some of those components, but we'll also build something that is very specific to Postgres. And the place where I'm still confused about how to solve the problem, but we will figure it out, is how do we solve this sharding and query processing? Because Vitesse can do query routing. Vitesse has the concept of pluggability. The part that I'm thinking about is the Postgres pluggability is more at the binary level where you actually build extensions and link them into Postgres. Right. Whereas Vitesse is built in Go which if we brought that in, how do we make these plugins work?

40:56Do we have to translate them or do we figure out a way to make them still work if we ported the Go code over is the part that I'm working through right now. Actually, we now have some people hired, so I'm working with some of those people too. Does that compromise your desire to be Postgres native considering what you learn with Vitas being written in Go, et cetera? How does that compromise your maybe Postgres for life? I'll maybe put words in your mouth, but this native Postgres way. So if you look at the Vitesse design, it was designed to be for the longest time, we didn't want to implement anything specific to MySQL.

41:41We thought this should be its own database system. And we actually restricted ourselves to just SQL 92. Because SQL 92 is generic, all databases must support it. Therefore, if we did SQL 92, then it'll work for anything. So we could even swap in Postgres underneath. But what we found out is that people were hesitant to migrate over. They said, oh, I want my application to run as is when I move over, which is what forced us to add MySQL extensions. So, in other words, we could port the SQL 92 part of the test directly over into Postgres and it'll work. And the problem is it's a subset. So if you do anything Postgres specific, it's not going to work.

42:33And so I'm beginning to think that then porting that means that, yes, we can port it, but then we have a lot to build to catch up to everything in Postgres. And looking at 10 years from now or five years from now, when, let's say, we manage to get full compatibility of Postgres, we will still face the issue of these plugins, these extensions. So that's the problem that I want to think about right now to make sure that when we get there, there is a solution for these extensions. How important is it to reuse a lot of what you learn with Vitesse in this new world? Because I can imagine like all this work you've put in and countless hours of open sourceness, et cetera.

43:21Like there's a lot in there. How hard is it? How important is it to bring a lot of it over? The learning is totally valuable. and without the learning, we wouldn't be able to build it. Rebuild, like if you say rebuild with tests, to what it is, it is a lot of code, but it won't take the 15 years that it took us to build. It may take us, even if we were to rebuild from scratch, it may take us a year maybe. Especially with AI, right? I mean, that might be a big help there. I mean, Go is really useful in in Cogen tooling and stuff like that. So I can imagine that that might even be a leg up for you to speed up the process.

44:08Yeah, we have been we've been using Claude to, you know, to to analyze Postgres. Yeah. So we you're probably right. We can probably do this much faster than even what I'm talking about. We had to rebuild this whole thing. So there's this common movie trope, you know, the retired badass. I'm not sure what this is called, you know. Like the guy who. Exactly. For one last. John Wick is like, comes to mind here. I'm sorry. John Wick, Bruce Willis often plays this role. It's true. Yeah. Or the Tom Cruise. Or Tom Cruise. Yeah. I mean, pick. I'm not sure who would play you, too. But you're coming out of retirement for this because, like, we got to get.

44:52What is it? Armageddon. And we're like, it has to be these people, you know. Right. which was funny because those were like oil drillers weren't they yeah interesting setup but no they come out of retirement for that one last mission you know i'm getting too old for this it was a common thing they say um and here you are but you're coming out with super base i mean it's a different story like super base came from where they're obviously their postgres maxis were fans of super base and uh no paul koppelstone had on the show a few times and so we know about them. We know what they're up to. Obviously, PlanetScale was on the MySQL side, but why Superbase?

45:29Why come out and hook up with this ragtag group of ProScrash Maxis to build this thing? So I actually engaged with Koppel on a whim, you know, saying, like, so when I said, this problem needs to be solved, needs to be solved now. My first thought, I should start a company. Let me do a startup. I actually started talking to some looking for co-founders. I was even talking to my to Jita and my PlanetSkill co-founder. And I was kind of starting to engage this. then I thought you know like what am I trying to achieve this time like I'm not trying to maximize profitability what I want to achieve is give this project the best chance for it to succeed and I was thinking if I do it as a startup I'm bringing so much risk and so much distraction right because then I will have to make sure that I raise money I have to you know keep people happy and and instead like what if I found a place where I don't have to worry about these things where I don't have to worry about raising money where I don't have to worry about and even like if you're a you know seed stage startup it's also hard to hire people you know there are people who are really, really happy, you know, where they are, they are being very highly paid.

47:15How do you convince them to come and, you know, like toil here and take the risk to, you know, we had this struggle at PlanetScale, by the way, when we left Google and we thought, oh, we know so many engineers, so hiring is not going to be a problem. And then we start the company, nobody wants to join us. So I thought of that. I said, you know, like maybe there is value in not going all the way to a big company, but at least a company that can pay people well, still give them a good upside. And so I thought of, you know, I'll start talking to some people who are, you know, in the startup stage and see see where they are.

48:00And that's how I engaged with Koppel. And I was like pleasantly surprised to find out he's like almost a perfect fit for what I was looking for. And the biggest one is the open source part. Yeah.

48:21Even in YouTube, we kind of had to push hard to open source with tests. for me, the success of an open source project is adoption. Open source and adoption is true success. And that's exactly what Paul believed in, Koppel. So it was so perfect. And talking to him about all the other values, he was like, at that time, it was almost like a slam dunk obvious that this is a place where I should be building this. Nice. So it's not exactly like the movies because in the movies, he's, you know, he would have sent out his henchman to find you and you would have been like, Oh, I don't want to come back.

49:02Yeah. You would have been like fixing up some old boat or, you know, practicing Tai Chi and like, they would have found you and you wouldn't have wanted to, but you had to, to save the planet, you know, but in this case, you actually reached out. Like you were, you were, you were ready to solve this problem once and for all Postgres users. And so that, that does make sense. I I think that jives, Adam, with my impression of Paul and Supabase. Does that make sense to you? Yeah, I like the fact that it's, you know, Postgres native, open source. I mean, that's the roots that Paul shared here. He's like, I think he said, the board of directors will have to fire me or pry this role from my cold dead hand.

49:41One of those, something elaborate like that to express his love for open source and his love for Postgres, Postgres native. So how'd it go from there? So he hired you. He's given you a team now and he says, have this on my desk in six months or how's it work? I'm giving myself about three to six months to come up with an MVP. It may vary. The reason why it may vary is because of my, I don't want to compromise on the long-term plan. So if for the sake of delivery, I feel like I'm deviating too much from where I want to go, I would rather delay the delivery. But I don't think it will take us longer than three to six months to come up with an MVP.

50:31We have a very well-defined set of objectives to reach for the MVP. And I think we'll hit it all in about three to six months. and then iterate from there. The idea is that from there, it should only be iterations, no major changes. That's the reason why I want to make the right decisions today so that it becomes iterative from then on. So that is the oversimplified plan, but I'm pretty sure we'll have, there are about five big features that we want to launch in this MVP. So is Go still on the menu then? or does that not quite get you Postgres native enough? I'm not sure if you can write. Can you write Postgres extensions in Go or do you have to use the C Go or how does that work?

51:21So that's the part that we are debating about. I don't want to start a brainstorm here, but I can tell you what we are talking about. Sometimes it happens. Yeah, just let it happen. Yeah, so the one option we are looking at is C Go. Whether we can, like if you have an extension, like can we link to call you through CGO is one thought that we are having the other thought we are having is well AI is so good nowadays can we like translate this for you and run it as an extension within Vitesse is the other thing that we are debating so there's the other crazy idea which is translate leave go and do it in C directly so all cards are on the table gotcha the last one is the least liked one at this point but uh it doesn't matter no whatever whatever gets whatever is the right solution whatever gets the job done so that's fun it's gotta be fun to be back at square one to a certain extent with a technical problem in front of you now like a big gnarly technical problem that's gonna take three to six months for an mvp and much longer if it's successful just to be back at where you started, but in a different context, you had a different part of your life.

52:39Yeah. And the best part is I get to fix all the mistakes I made in the previous project. Oh, yeah. But what about the mistakes you're going to make this time? That's the problem. You know this, V2 is perfect always, right? That's right. You're not going to make any bad decisions this time around. Yeah, that's got to feel good because there's so many landmines that you just can avoid this time around. Yeah, yeah. that's awesome what's your team looking like who are you looking for you looking for hardcore postgres people or did you hire from the test there were some uh so i cannot name names yet because uh some of them are still in the pipeline but it's a pretty exciting pretty high caliber team some some are older uh with test contributors that uh yeah there's a diaspora you know of with as contributors.

53:33Some are from there. And some are actually people that were that have handled this type of scaling problem before. So for whom we test is an obvious thing. So it's a pretty high caliber team. I think we'll be announcing the team very soon. They're going to be kind of the founding team of this multigress project so we'll probably be announcing in maybe about a month or so but it's hiring is looking very good at this point i'm pretty optimistic what is implementation like in this new world is that still to be found out as you make these choices that have long-term permutations into maintainability etc like how I know how, for the most part, how Superbase works as a service.

54:29But if I wanted to use what you're calling multigress, Vitesse for Postgres, essentially, if I wanted to use that on my own outside of a Superbase context, what do you know about the future thus far to kind of showcase implementation details for end users? So in this, I should talk about something that we did in Vitesse which we are not going to do in Multigress. Vitesse actually is what you would categorize as one of the most flexible enterprise solutions you can ever think of. If you want to ask a question to Vitesse, I want to change this very specific behavior of Vitesse, there is probably a command line option for it.

55:20so that made Vitesse extremely powerful and flexible that's the reason why Slack could adopt it and completely deploy it using their rules GitHub could use a completely different approach and I believe Etsy has an even crazier approach and Vitesse works for all of them but the problem it created by solving these things is approachability if I came in and looked at Vitesse I wouldn't know like as a layperson who was just oh my MySQL is getting too big I want to use Vitesse it will take you a few months of learning how Vitesse works before you can start to use it confidently so I realized that's a problem and so what I want to do in the multigress is make it a lot more approachable.

56:16Actually, at the expense of even reducing those flexibilities. Because I think adaptability is more important, approachability is more important than flexibility. And if we add flexibilities, we want to hide them away from the user that they shouldn't have to find it until they need it. so that is that is kind of the approach we are going to use and what that means is that it should be easy for a user to just take a multigress and just deploy it in their environment and it should just work for them do you know how that will manifest inside a super base or is that more on the super base product team to decide like will that be invisible to super base customers Absolutely.

57:07Yeah. So the... Makes sense. The idea is what we are going to be building is a Kubernetes operator. So if you want to deploy it yourself without Kubernetes, you may have to do a few things for yourself. But if you just took Multigress and use the operator, you specify, you know, this is what I want. and then the entire cluster comes alive. And we plan to do that within Superbase also. So this operator will be deployed within Superbase. And all Superbase has to do is, you know, hey, bring up a cluster and we'll just spin it up for you. And they have to be operating at significant enough scale that they can act as a test ground for you, I would think.

57:58Or maybe they can't do that with their customers. But I'm just thinking like you had YouTube to build the test with And that was like awesome, right? Like you had a real scale database that had consistent users, et cetera. And you could build the system. I guess in that case, you built it incrementally over time as you figured it out. But building this in a vacuum, you got to have some sort of real scaled things to test against. Maybe these are some of your, your core team that you'll be announcing later that I'm sure they're going to come from scaled up companies. Yes, yes. So there is a philosophy in, so we had that luxury and that's the reason, I think that's the main reason why Vitesse succeeded, where others have failed, is because nothing that would not scale could be even written in Vitesse because the next day YouTube would go down.

58:52Right. Right. And we would so we have created a few outages due to those things. So if something was not going to scale, we would know right away. So we had that luxury. So nothing that went in with us, everything that went into with us had to work at scale. So that was that was one thing. And the advantage we have is we have those learnings. So we we know what not to do. Sure. But don't you want to test it as you go and make sure that you're doing it right? On the testing side, what we over time developed, that is something we had the luxury of not having to do in the early days at YouTube, is we had to develop really, really, really, really thorough tests.

59:36The reason was because at some point of time, we would be making changes in the Vitae source code. And we had to be confident that people are going to take this. Slack is going to take this and run it. GitHub is going to take this and run it. It's going to come back into planet scale. And there is no waiting until it goes live to find out what is going wrong. So we actually, in Vitesse, we had an extremely rigorous testing policy. Extremely strict with 100 % code coverage, performance tests, backward compatibility tests. so that's actually one of the it also makes it hard for an engineer to contribute because you change five lines of code, now you have to write all these tests to make sure that you won't break anybody but the confidence is people now have developed the trust that if a test releases code, I can just take it and run and it will not fail so I'm hoping to bring that same philosophy here which is to test thoroughly to the extent that we are confident that this will work.

1:00:53And we'll obviously still ease that into production. Could you actually bring the test suite over or at least parts of it from the test? I mean, because that's a pretty robust test suite. If you could port that somehow relatively easily. Anything we can copy from the test, we are going to. Yeah. Definitely, yeah. But there are some parts which will just copy. There's no reason to change anything there. So those parts will just copy. Yeah. Have you looked at deterministic simulation testing, similar to what Terso is doing? And what was the other database, Chair, that you had called out me? Tiger Beal.

1:01:30Tiger Beal, yeah. Have you looked into that? And is that translator? Is the test space? I need to look this up. Okay. But in VITES, we probably have the opposite, which is called the fuzzer. Is that the same thing? Uh, similar. Yeah. Similar. So we do, we do run the fuzzer and the fuzzer does not miss. As far as I know, uh, it, it misses nothing. From, from, I, I wasn't there when they implemented it at planet scale. It was, uh, someone called Vicent who did that, uh, test suite. He said that, um, uh, the fuzzer was so good that it found bugs in my SQL. That's good. So, so I have, pretty high confidence in that, but yeah, whatever it takes.

1:02:16Well, we have a couple past shows we can recommend for you as well that might give you some insights to just some of the behind the scenes, not exactly that and how to implement it, but more fodder for your requests. Yeah, yeah, definitely. Well, it's all very exciting. I assume the licensing is going to be similar to Vitesse or similar to what Superbase normally does. Is there any sort of gotchas in there in terms of the open source side of it? No, Apache is what we are planning to do. And yeah, the test was actually BST once upon a time until we joined the CNCF and we changed it to Apache. But yeah, it's going to be Apache.

1:02:55Does Multigrass make sense in the CNCF as well or no? It's an option. It's definitely an option. we even thought of as either a fork or could be a sub-project of Vitas but then I felt that that will restrict its freedom right now like starting it as an independent project these are very difficult decisions and I think once we make these decisions and bring it to a good shape, we could look at actually moving it back to CNCF as its own project. Yeah, I think you want the space to reinvent and rethink without feeling at all burdened by your past decisions with Vitesse. And I think obviously copy and paste the stuff that makes sense, but don't make it a fork where you're basically starting at this foundational, which you may end up wildly different in implementation or you might be the same, but at least give yourself room to come there organically, you know?

1:04:03Yeah. I can't like, uh, uh, that is something that was pretty obvious to me. Uh, although the fundamentals are the same. Uh, so you can, even if you don't copy code, you can copy ideas pretty easily. So those, those don't change. But, uh, when you get into the details. There's so many small things. And the thing is, if you, uh, uh, if you don't do them the Postgres way, uh, that will keep nagging you, you know, you say there is, there is this thing where, you know, I have written this, there's this if statement hanging there, which is there only to differentiate between Postgres and MySQL. Right.

1:04:41And so you don't want any of that. None of that. Yeah. That kills the joy part, right? It takes away the joy that you're trying to enjoy what you guys are building here. Well, it's very exciting. Obviously you're just getting started. So there's still a lot of question marks for us, Postgres fans. It's just a lot of waiting, seeing, you know, watching maybe the GitHub project as you put it out there and the announcements as the core team comes together, you know, you're get the, the post, the Vitesse Avengers, you know, get the whole team together. But what else, what else is on your mind or things that are important for folks to know before we let you go?

1:05:20The thing I feel is, I feel a bit anxious that there's not much activity in the open source project. But, you know, we may see cool, but we are paddling hard underneath, really, really hard. So I will be actually publishing a few blogs about some of the thoughts. There's one area which we didn't cover much of, which is the high availability and the consensus part. So actually, my initial blogs would be covering those. I feel like this is something, the database world kind of went a little bit astray with mounted storage, disaggregated. I feel like that needs to be brought back in. I feel that storage should be with the database because database are IOPS hungry and having your data local to your database is very important.

1:06:24And that story can be complete only if you have a good consensus story where your data will not be lost if you lose your node. So that is something that we want to solve really, really well in Postgres. so that people, because I have seen the good days of the database, where database goes screaming fast. Like Slack and GitHub, they run hundreds of terabytes of database size. They run millions of QPS, and their latency is like millisecond, one millisecond, two milliseconds. That's the kind of latency they get. And they can't tolerate any higher latency. And I want to bring those days back into Postgres.

1:07:11So that is kind of what I'm shooting for. So are those things that Vitesse tackled or did not tackle? High availability. Those are, yeah, those are like pretty, very core to Vitesse. Yeah, I thought so. So those parts we are going to bring into Postgres. Interesting. Adam, anything on your mind? Any other questions? I'm thinking about Neon, honestly. I'm thinking about, you know, just this kind of bigger picture. I'm curious if this shake up, this change in the database world, like for a while there, we had obviously PlanetScale leading, you know, massively scale MySQL, which was great for MySQL, but not so great for the Postgres folks like us.

1:07:52And then we've had Superbase, obviously. We've had Neon. Neon was acquired by Databricks. I don't know how that's going to shake out for a product that's usable by the public or if it's a Databricks thing. like this seems like a good time for Superbase to do this because there's change amongst the Postgres world. And I feel like this is the clincher really for Superbase to finally have this kind of feature set that wasn't available unless they built it. And why build it in a non-Postgres native way, in a non-open source way, given Paul Copplestone's way of thinking as a leader there. I'm just curious your thoughts on that Sugu is just the thought of like Neon, Postgres, Superbase this shakeup, you coming back out of retirement basically to avenge this scenario and shard for life with Multigress help us unpack this shakeup I suppose are you excited?

1:08:54Obviously you came back but how does Neon's change change the landscape for Postgres specifically to open the the floodgate for Superbase's mission with Multigress. Yeah, going back to why I started this project, right? The reason why I started this project was because I believed, I still believe actually, that there is no scalability solution for Postgres. Not Neon, not Aurora.

1:09:26Like I've been, I'm an advisor to Metronome. which is a Postgres shop, they have one of the largest Aurora instances and they are struggling. They have no way out beyond where they are looking at moving data out of their Postgres instance because they've hit the limit. And now they're saying, oh, we need to do something about this scalability thing. And that's the reason why I wanted to start this project. And one of the things I thought is with Superbase, if not just like, so this is a problem that is meant to solve it for the industry overall. In other words, Neon could use multigress if they wanted.

1:10:14If they hit the limit of a machine, you could deploy multigress on Neon and run it unless there was incompatibilities, for which you have to make changes. But even in those cases, the changes would be minimal. So that's what I came for. And for Superbase specifically, is that if Superbase is going in its trajectory, there are going to be users that are going to max out a single instance very, very quickly. As a matter of fact, I won't be surprised if some are already hitting those limits. and their way out is you could go to Aurora maybe and that will extend your runway by maybe at best 2x. I'd be surprised even if you got like a 2x runway.

1:11:09As soon as your QPS doubles, you pretty much are at your limit. So the only way out of this is a sharded solution and that is why i started this project i i said that you know like in my sequel if you hit your limits you could go to vtess but there is nothing like that in postgres and vtess for postgres at even mediocre level of functionality will allow these people to stay in postgres otherwise you have to find a way out of postgres once you hit that limit well after you accomplish the test for Postgres, maybe you can build the test for SQLite. No, I'm just kidding.

1:11:57You know, for your second after your next sabbatical, you know, the only thing that gets your back is Dr. Richard Hipp approaches you and says, Sugu, we need you. We need you to SQLite. That reminds me of I think airplane, was it? where there's a background scene with a movie poster which says Rocky 83 and a really, really old guy is standing there. Yeah. Airplane. You're going back in the day into the 80s to mention movies. I haven't seen Airplane for years. I mean, like, don't call me Shirley, okay? Exactly. Good stuff. Yeah, good stuff. Suga, thanks for coming back from retirement for this.

1:12:45I know that, I mean, considering what you just said, that there's no way out, that sharding is the only way. I mean, you're coming back at the right time. I think you're coming back to the right team with the right motives at the right time. And, you know, somewhat full disclosure, Jared and I are both angel investors in Superbase. So we kind of have, you know, this desire for our own upside, but like technologically, this is going to be amazing for Superbase to essentially be one of the only leading at scale Postgres flavored, Postgres for life, open source for life flavors out there to choose from.

1:13:21And so I'm super excited about that for you and for them and for Postgres because we need it. It's amazing. I am excited too. Get building, man. Get building. Get building. All right. Thanks, Sugu. Bye, Sugu. Thank you.

1:13:37well friends it was awesome talking to sugu diving deep into the test diving deep into what that means for the test for postgres aka multigress all the work is going into it and what's to come for us postgres maxis postgres for life but yes we are also in denver this weekend if you're in denver around denver want to hang out with us on friday or saturday for the live show learn more at changelog.com slash live. Big stuff is happening. Don't miss it. Come hang out. And it's also free to attend for Plus Plus members. It's better. You know what? It's better. That's why it's better. changelog.com slash Plus Plus.

1:14:17Big thank you to our friends at Code Rabbit. Check them out at coderabbit.ai. Our friends at Depot, depot.dev. And of course, Fly. Check them out, fly.io. That's it. The show's done. We'll see you in Denver.

1:14:41Thank you.

1:15:10Game on.