 Good afternoon. Okay, this is a little bit of a new way of doing things for us. We've never done a live event. We've always been pre-recorded, or at least virtually, obviously. Today, this is the future of Postgres Roundtable. Those who are watching, I hope you enjoy. Our speakers today are Haike Linning. Oh, I'm going to let you pronounce your own name, Haike, but just give me a moment. Dennis Lucier, Kevin Jernigan, Ry Walker, and Karthik. I'll let you handle that, too. One at a time. Haike, why don't you introduce yourself? Hey, my name is Haike Linning. I've been working on Postgres for different companies for almost 20 years now, and now I'm a co-founder of Neon. Hey, Haike, are you also a committer? Committer, yes. Yeah, okay. So you're a PostgreSQL.org Committer. Dennis, how about you? Just unmuting myself. Sure. I'm Dennis Lucier. I'm the CTO and co-founder of VGH. Also been in the Postgres community for around 20 years. 2004 OpenSCG in 2010, and then worked with Kevin for a while at AWS, and now doing my own thing again. All right, Kevin? Yeah, so Kevin Jernigan. I'm currently on the product team for Google Cloud's LODB service. Been in the database world about 36 years. Started way back in the deep dark past at a small company called Oracle, and moved on from Oracle and did a bunch of startups, and then went back to Oracle and then went to AWS to work on Aurora Postgres, and now I'm here still working on Postgres. So I've been in the database world for a long time, been paying attention to Postgres, I guess, for about eight or nine years. So that's just my background there. So Kevin, how does it feel to not work for a legacy database company? Well, it's funny you ask this, you know, when I started Oracle, we weren't legacy. We were trying to disrupt IBM and we had 800 employees. So, you know, very different animal than Oracle today. So, but my second time at Oracle, yeah, we had 80,000 people and then bought Sun and then had 120,000. So that was definitely legacy. It's fun and interesting. It's really, you know, about what customers are excited about, right? In my experience, customers are really excited about Postgres for lots of functional and capability reasons, but also openness reasons. They aren't locked in the way they feel like they are, not just with Oracle, but with, you know, a SQL server and IBM even. So, you know, that's just both at AWS and now at Google. That's been, you know, the fun part of this is not having to worry about customers being mad about, you know, the licensing terms. So that's a good thing. All right. Rai, why don't you introduce yourself? Sure. Yeah. I'm Rai Walker, founder of CoreDB. I'm a software developer, serial entrepreneur. I founded a company called Astronomer in 2015 and exited via secondary sales during the pandemic. I've been a Postgres user for 15 plus years. I was an early Rails and Heroku user. CoreDB is a new Postgres company, building a dev-centric managed cloud for Postgres. Focused really on capturing new use cases for Postgres. So, you know, our kind of our mission is to collapse the modern data stack sprawl into a unified platform. Hey, Karthik, before you introduce yourself, you need to turn your camera 90 degrees or 45 degrees. Whatever it is, make sure it makes your head at the top instead of the left. I didn't realize it didn't turn. Really sorry about that. Really sorry. That would be for help. We've always known Yugabyte to be a little bit, you know, to the left. So, all right, go ahead and introduce yourself. All right. Is this better? All right. Hey guys, I'm Karthik. I'm now sitting the right way up. But anyways, I think by way of quick intro, I'm one of the co-founders on the CTO at Yugabyte. My background, I've been in distributed databases specifically over 15 years now. And, you know, it involved with Postgres for about six or seven years now. Like, my journey into distributed databases started at Facebook, where we had to figure out how to do distributed databases back in 2007. And there were no real open source databases that did it. I mean, Postgres was still there, but it wasn't distributed. And we had too much of data to deal with. And we ended up building an open sourcing. What is now Apache Cassandra? We didn't, we had no idea that it would take off or open source databases would be a thing or all of that stuff. Anyways, we followed it up with building HBase or critical set of features into HBase. And at the time, we were at Facebook, you run what you build policies. So, we were also the Dbass team running these databases at a pretty massive load. We're talking, you know, hundreds of petabytes of data, thousands of servers across multiple data centers. And we kind of saw firsthand the evolution of the cloud, like into nearby and far away regions, what you call zones and regions right now, nearby and far away data centers called zones and regions now and, you know, and so on and so forth from there. And, you know, powered a lot of the highly available and scalable systems inside Facebook. So, we were a part of that journey, you know, worked with the folks that built RocksDB and so on and so forth. So, been in, you know, overall distributed databases after that worked at Nutanix on distributed data as a storage layer. And, you know, here we are building a relational database or Postgres specifically and making it distributed, you know, for the world of cloud native applications, you know, zero downtime, highly scalable or scale as you need kind of applications. All right. Well, I'm JD. Everyone on the stream knows me, but I'm the founder of United States PostgresQL as well as the founder of Postgres Conference and of Command Prompt, which is the oldest of the Independence Postgres companies. With that, let's go ahead and move forward. You know, we've got a lot to talk about, not a lot of time. Let's start with a simple one. Where is Postgres today? Right, you know, a lot of us have been in Postgres, you know, a lot of people in this call have been in Postgres for at least a decade. Dennis and I have been in the Postgres for over 20 years. I've been in Postgres since 1997. So, we've seen the evolution of where it is, was, is, where we think it might be going. Obviously, it's open source, you never know. Let's start, Haiki, if it's all right, let's start with you on that question. So, when I started working on Postgres, it was a very different beast and there were a lot of competition from MySQL and, you know, proprietary databases around. So, you kind of had to explain like, okay, you know, what is Postgres and why would I use Postgres? Like, why not just go with MySQL or why not go with Oracle? But that has really changed over the years. Like, I'm not sure where exactly it happened. But one year, sometime ago, I just realized that I don't really get that question anymore. Like, people know what Postgres is. And in fact, become the default choice. So, nowadays, people just start with Postgres and if they have some specific niches or needs, they might go to others. But people, amplifiers and developers are choosing Postgres by default, not because of some particular good properties of Postgres, which as a developer that actually scares me a little bit because, you know, it might make us complacent and just stay still if no one is kind of pushing and you don't, if you don't need to justify your existence anymore. But I think that has been the big change over the years. Dennis? Yeah, I definitely see the same thing. In fact, I've seen the steady progression, right? So, in the early days of Enterprise DB back in 2004, to convince customers that Postgres was a valid thing to use in place of Oracle was really hard to sell. And MySQL was, you know, kind of 10 times more popular by volume of that time. But very, very steadily, year after year as Postgres has matured and the other ones have, you know, MySQL is acquired by Son and then Oracle, etc. It's just, it's emerged as the database of choice. And now we talk about like different use cases and what Postgres can do and what it can take on rather than is Postgres ready for the Enterprise. It is, it is riding high in its premiere ship right now. And yet it's not, it's not complacent either. So I think it's great. How about Ryan? Yes. Yeah, I mean, I'm really excited to see like two things. Number one, as everyone said, you know, it's the de facto OSS database now. But I'm really interested and excited about all the creativity that's emerging from like new use cases, extensions, you know, I mean, even things like columnar tables, which, you know, have been around as extensions for a long time are not very widely adopted. But I think, I think things, you know, that the creativity is happening now will help really push Postgres users to be a little bit more daring with it. And that's exciting to me. How about you, Kevin? Yeah, so as I said before, I've been involved with Postgres for about eight years. When I was leaving Oracle for AWS, this would have been 2015. Um, to work on Postgres, I didn't know what project it is going to be working on Postgres. My manager, you know, when I was leaving, wondered why I was going to go work on Postgres, because in his words, he said something along the lines of well, nobody's working on that anymore. So why would you go work on a project for Postgres? And I had already, of course, done some basic research and I knew the opposite was true. Maybe this is mid, you know, 2015, eight years ago. And we've certainly all seen the opposite of that since then. There's been lots of investment by lots of people personally and by companies in improving Postgres. And I think we might be talking about this a little later, but the license of Postgres certainly encourages that in my opinion. All the forks you see out there, yeah, sure, they're forks that can run off and do whatever they want with it and not contribute back. But inevitably, a lot of that work does make it back in the mainline. And I think that's, you know, I think people forget how important the license decision that was made way back in the beginning of time for Postgres, how much that's just accelerated this perception of Postgres being, you know, a great place to move your enterprise database workloads. And Karthik? Yeah, so I will maybe double down on one of the points that Kevin just said, which is about the license and then add a few others. But like, I would say like my perspective is more from, you know, one of the forks or somebody trying to do something radically different from Postgres, but yet wanting to be a part of Postgres, like I'd say that's our perspective as Yugobyte. We actually started the company and the project in 2016 and, you know, it is pretty recent, right, compared to a number of, like, you know, compared to Postgres itself, right? And we went through this elaborate, you know, investigation and, you know, like a phase of figuring out make our project like Yugobyte DB as a project to be and weighing in users, you know, investors, you know, like, you know, our own people inside, et cetera, et cetera. And, you know, we spent a year and a half at it. And, you know, what we arrived at is the best way to do it is just keep all open just like Postgres. So, so anyway, so that that decision still stands at 2016. We're still happy with that decision. So anyway, so I think that is pretty crucial in order for Postgres to succeed in order to have succeeded and to have gotten where it is here. So, to total, like, yeah, totally love that, totally love that open spirit, which will foster even more innovation. And to address the fact that, you know, where is Postgres headed? What are the use cases that we're, you know, Postgres can take on? I think in our own way, we are trying to do something of that kind also. So, and I think what I have been blown away by is the absolute extensibility of Postgres, both, both from like community embraces and brings in new ideas that are radical and lets people, like, you know, thrive and, you know, contribute and innovate, but also as code and as modules, how it really lets people extend and push the boundary and so on. So, yeah, it's been fantastic all around. You know, we're like, you know, we kind of bet the company, so to speak, on Postgres back in, you know, 2015, 16 is when we made the decision. And, you know, it's gratifying to see even from then to now over the last, say, 8 to 10 years, it's amazing to see how much Postgres has become the default, right? And so that's absolutely amazing in the set of capabilities that it already has. And so, yeah. You know, it's interesting, we've had multiple people bring up the license and Haike, you brought up a fear of complacency. So, the license thing I think is important to talk about a little bit. There's actually a history of failure of companies who have taken the license and then closed their product. I mean, just traditionally speaking, so, you know, if you have concerns like Kevin, you said, you know, hopefully they give back, well, that's absolutely correct. I mean, hopefully they do give back. And I think that there's, if not a business case, there's definitely an ethical case for it. But more importantly, if you look at every single product that has closed itself based on Postgres, almost all of them are, have either gone back to open source, no longer exist, or exist only on legacy customers. Some simple cases people may not know. The current iteration of Ingrid, or not Ingrid, of Informix, is based on the original Postgres, not PostgresFuel.org, but the original Postgres. And they, and that came from a company that forked Postgres, became a Lustra, IBM hit a ceiling with their current code base, bought a Lustra and merged into what they now have as Informix. Nobody uses it anymore, except for legacy customers. Teradata, Natesa, all of these things, it's not that they don't exist, it's just that they're no longer in the mind's eye. And even one of our, you know, one of our closest partners who has supported us for a very long time, VMware, you know, the Green Plum, it was originally closed source, and they realized they just couldn't keep up with the velocity of which Postgres gets developed. And now Green Plum is open source as well, and is trying to get to code parity with the current version of Postgres. So if you're thinking about building on Postgres, specifically, I'm not talking about extensions or external apps, but if you're going to try and reinvent the platform, you know, the kernel, the Postgres kernel, the Linux of databases, I think you're just headed for failure. You're just, eventually you're going to have to reopen it, or Postgres, by its very nature, is going to surpass you. If you keep your stuff open source, that's a different discussion because you allow yourself to build out your own ecosystem. Hikey, one of the things I want to address with you is complacency, and I'd like to get everyone else's thoughts on this first, but Hikey first, because you brought it up. Wouldn't you say that one of the ways we don't get complacent, because Postgres QL is notoriously conservative in its development model, and for good reason, right? You don't want your data, if you're putting your data in a database, you don't want that data to disappear, okay? That's why you put it in a database. But I would argue that a lot of the forks, a lot of the trial and errors that have been out there, continue to push Postgres QL forward. I think Neon's a perfect example of that. What are your thoughts there? Yeah, I totally agree. Commenting on the license, first of all, I want to actually challenge, like you said that these forks have gone and been failures. I'm not sure if it's a failure, if a project is live for 10 years, and there are users for that, that's just because you don't take over the world doesn't mean it's a failure. So it seems like Greenplan, whatever forks there are, and these advanced server are still around and has a user base. So I wouldn't call them failures as such. But going to the extensibility point, I think you're right, these forks are showing, they're demonstrating what is possible also to the core Postgres and that you're right, it does help to keep the Postgres community from being complacent. The license is important, it's what allows these forks, although there are different licenses that would allow that. It's not just the license though, it's also kind of the mindset like the Postgres community is very open to these forks. They don't affect the Postgres community very much, like if someone takes the codes and forks and goes with it, it doesn't affect the rest of the community, but also everyone has kind of made peace with that a long time ago. These things happen, forks happen, forks come and go, sometimes good things fall out of them, sometimes they go and nothing happens, but that's life. And everyone is welcome to the Postgres community to contribute. We have something to contribute. It's an interesting story with you mentioned Greenplan, before we founded Neon, I was working for VMware and I joined VMware, it was people till back then when they announced that they were open sourcing Greenplan and I was there to help them to align with the rest of the Postgres community and catch up with the more recent releases. Turns out it was a lot of work, but they, by the time I left, they had, I think they had left almost cut off to the latest version that was at the time, I haven't followed the development since, but it does reduce the maintenance overhead with the closer you stick to Postgres, the core Postgres. And that is often, you know, that shows the viability of these forks often, like what is the latest version you're on? If you are, you know, five versions behind, it's a pretty hard fork, but then there are other forks like Postgres Excel, that periodically refresh and keep up, I don't know what version they're on at the moment, but there is a difference between a fork that is a pretty thin fork and a massive fork that's never going to come back. I think you're right, she was based on, you know, Postgres something and you mentioned Nethisa. All right, Dennis. Actually, Dennis, I apologize, let me interrupt your high key. You stopped recording for some reason. Dennis, go ahead. I can see them, so I hope I'm recording them. But yeah, so I think this strength of the extension model and the innovations that people are able to do there, and there's a lot of companies doing that and featuring that and then trying to make just as few changes in the core as they have to and planning on open sourcing them and focusing on making hooks, so more and more things can be done in extensions. This is a very powerful model that people are doing and works in kind of an iterative process and some forks are doing this like our upsets, like I say, was Oracle Compatibility University, but the community doesn't really want that anyway, right? So it's a very kind of a fork and running parallel with things that are complementary to the community, but the core isn't really looking for, I think, is a wonderful model and I think there are several examples of it. And companies working together to kind of get those hooks in and then doing their own implementations of increasing amount of functionality. You can do extensions based on those hooks. So I'm pretty happy with the state of the world there and how it's evolving. And it's not a perfect system, but it does work and has people both working together and being competitors at the same time. And I think it's pretty impressive. Roy, you might have some interesting words on the extension front. Yeah, yeah. I think that on the extension front, it was pretty shocking to me when I started taking a closer look at Postgres last year that extensions have been around for like 10 years and I hadn't heard of them really. I used to say I accessed databases primarily through a framework's ORM and that just turns it into a really dumb back end that you don't really have to think too much about. But I think that that's a big advantage for it. As far as like rooms where Postgres I think has room for improvement, I think the biggest Achilles heel for me right now is that it's not quite cloud native, that horizontal scaling is complicated or it's available through commercial solutions. I'd love to see a world where the default attitude is that we can treat Postgres clusters as cattle, not pets. There's a big leap from here to there, but that was my biggest thing when I stepped into it. I was like, oh, this is like, it's just, you could just tell compared to the new DBs, it's just not quite on a parity level. And I know that the path to get there is complicated, but I think it's definitely a worthwhile thing. Can you expand on cattle versus pets? Yeah, yeah, yeah. I mean, the idea is that, you know, like I'm a big Kubernetes person, so the idea is we should be able to just like kill a, you know, you should be able to have a chaos monkey, for example, in your cluster just randomly killing stuff and nobody sees anything bad happen. And you could imagine if you have a bunch of post, of traditional Postgres clusters and you're just turning them off, most people will feel that, you know. Maybe not, you know, depends on how you set it up, but it's, you know, just the idea of the default installation is not resilient to that sort of thing. It requires a lot of extra work or for commercial solutions. Does that make sense? It does. I think it limits the scope of where PostgreSQL is deployed. I mean, by far the majority of people don't need or want what was just described. I mean, you're talking about 14-1000 per se. I see it as, even as an initial user, let's say I'm going to Heroku to sign up for a Postgres database, I can buy it and I can buy like a read replica, you know, if I want that sort of stability. But it's not like, I would rather just have two, like, you know, two clusters working together. If one of them dies, that's okay. All the work is over here and then it'll come back and now it's splitting again. So that's the idea around, you know, cloud native is that you just, you create, you create redundancy by default rather than like as an exceptional thing. Carlson, what are your thoughts? That's what do redundancy and scale out and availability. But I'll tell you an interesting journey, right? Like for us, like I can say that for you, we would actually have built a 100% on top of Postgres if we could have. And I think honestly, and I think we still would if we could. The reality is like, you know, it introduces a level of complexity that, you know, as a, like, and, you know, it comes down to the philosophy of Postgres. And, you know, like, I think it's the right thing the way things happen. But Postgres stands for something and it has, you know, it is powering mission critical workloads and you don't want to touch that core. And there's a certain class of segment of use cases right now that Postgres is addressing. And the way I would say is, you know, we're trying to think about what would it, what would need to happen to Postgres in order to do specifically what you said, right, which is how can you, you know, have redundancy by default, scalability on demand and availability all above everything else, right? And so like, like, for example, when we try to do it through the extensions framework or various frameworks, it just gets hard because, you know, what do you do, for example, with the system catalog or how do you deal with the NITDP process or how do you deal with, you know, sharding and replication or a variety of different things, right? So, so from that perspective, what we said was we will stay very close to Postgres. We would, we would be as open source as Postgres. And if and when the time comes that, you know, Postgres is trying to align in this direction, well, we try to play a bigger part in it, right, like, and so on and so forth. So, so for that part, I think the, I think it really gets at the core of the of the system, like it's something that, you know, really as a community, as Postgres, we should all be in the same boat to take on, as opposed to, you know, are we still in a state in the world where there are a vast majority of applications that are happier with traditional databases, single node databases, and don't quite need the availability or scalability or the cloud native by default aspect that you talked about, right? I think it really comes down to that. Our thesis at YogaBite is at some point, this is is critical enough is big enough for us to build a commercial company on to build a project for, but, you know, it depends on what we view as a, you know, combined set of combined truth axiomatically in the Postgres community, right? So, yeah, I'd say, yeah, when you drill down on that, it comes down to core architectural things, right? And how much do we want to destabilize in the current Postgres would be the question because you can always build things on top. But without changing the core, it's just only so far you can go. Yeah. Kevin? So many things to say, so little time. Just real quickly, there are some, there is a category of forks that are doing quite well, and have been for a while, the managed Postgres is in the cloud, whether it's Aurora and LEDB, which make, you know, significant changes, or even RDS for Postgres, Cloud SQL for Postgres and Google Cloud and, and, you know, Azure's version, they all are technically forks, but those companies have made commitments to merge their forks back and keep them close to the main line as close as they can. And they're clearly building very viable businesses, arguably the biggest fleet of Postgres out there is probably currently AWS RDS for Postgres. Oh yeah, that's not arguable. Yeah. And so that's just the truth. The point is, those are viable forks, but those are also very big companies that are supporting them and building markets and whole infrastructures around them. But you know, I hear you're saying, JD, there's probably more examples of forks that haven't gone anywhere. Just the Postgres website forks page will let you troll through some history. Next thing, you know, I think we were talking about is the Postgres community too conservative in some ways. I've seen some of that in the sense that, you know, like I said, I got involved about eight years ago, and, you know, there's been talks in the time I've been paying attention, lots of talks about, well, we need to do something about building real undo, redo undo instead of copying a full row every time I want to update a column. And I don't know how far that work is gone, but that's hard work. It's hard dangerous scary work to do in the core. And so I think that's just a category of things where the community has a hard time getting people to work on the hard stuff. You know, when's the transaction ID going to be more than 32 bits, right? That kind of problem. And, you know, I have a long list of other things that I look at them like Postgres needs to be better at these things to really compete at the high end with Oracle and SQL server. And the one thing I'll just throw out there is scale up. Why do we, you know, why does Postgres focus a lot on sharding and replication and all that? Well, because it hasn't focused on scaling up better on bigger machines. You know, lots of workloads would just do fine on a 64 CPU box, except Postgres kind of tops out at somewhere around 16. And there's known fixes to those problems, which you can find in both Aurora and LEDB in various ways, but they aren't in the community. And so that's just some points of, you know, I think about when I think about the community has lots of strengths. But one major weakness is it's a community and not a, you know, benign dictatorship run by one business. So you can't commit a bunch of people to do some hard work unless they really want to. And so that's an interesting question. I don't, JD. I mean, there are people working on scaling up. So I'm not sure I buy that. These clustering and sharding solutions, they actually tend to come from outside the core and you're right. That's because, you know, if Postgres could scale up on a single note more, that wouldn't be so necessary. But Postgres has actually improved year by year on those things. I have a couple of points of view also. I think Kevin, like to your point, like, I think you are correct that the, you know, the cloud providers, which are who are pretty big are, you know, making very viable businesses. And it's absolutely true. And, but I'm actually with Haike on this one that, you know, Postgres forks, I mean, it's not just Yugobite, even non-Yugobite ready. If you look at, you know, Netiza or some of these other companies that, you know, terror data, they have been great solutions at those points in time, like at what the technology demanded of that point in time, right? And technology demands a cloud native solution at this point in time. And hence, the cloud providers are opportunistically the right place to do it, right? So, I think there is a place for Postgres forks, Postgres outlives it all because of its longevity, because of its openness. And that's a great thing. But like, I just want to point out that, you know, there have been extremely successful forks and it is more should be viewed in a, as a point in time, because every company, every market, every space has a natural curve, right? Like when it rises, it stays on top, and then it perhaps changes. And it is not the technology necessarily always that determines the demise, right? It's about the ability to adapt, the ability to change and so on and so forth. It is one of the things we're talking about with the Postgres community also. But that aside, right? Like it's just like, just want to just want to say that, like I'm with Haike on this one. So, and yeah, and I hold on one second, guys. All right, Haike, you're actually recording now, which is great. Yes. Is it good? Hello? Car is interestingly enough. Yeah, it's much better. Go ahead and mute your microphone, though. Kevin, you know, it's interesting, one of the things you say to scale up, and you know, weren't you said one of the downsides or negative parts of being a community and not a company dictatorship? As someone who has built massive software within Postgres and on Postgres and about Postgres, the idea that there's a benevolent dictator or even a non-benevolent dictator, let's say, or a corporate, right, that drives a business forward and drives a particular point of view in terms of their technology, there is no question that that allows a market penetration and a build out of clients, right? I mean, let's be honest, as much as we all love open source, proprietary software is by far the most deployed. And that's because proprietary software is driven by a particular point of view. That being said, Google is welcome to submit as many patches as they like to postgresql.org and work within that ecosystem to build out a better database. So if a company, any company, Google, Amazon, it doesn't matter who it is, if they want to influence the direction, it's, I'm going to oversimplify here, because you're all going to roll your eyes at me, all you have to do is contribute. Now, I, as everyone laughs, I am fully aware, as you know, that contributing to postgresql.org is not a low lift. It is not a, I'm just picking up a five pound dumbbell and running with it. It is a huge, phenomenal financial time and money sink for the hope of acceptance. Okay, so I'm not taking away from that. But the point is, right now, if we find a problem with Oracle, say they're in comprehensive way that they handle, say, null, for example, we can't just submit a patch. Nor, even if we don't want to submit a patch, we can't just download it and fix it for our own installation. Because let's be honest, AlloyDB, GCP, RDS, Aurora, and whatever Microsoft is doing today, all they did was download it and fix it for their own installation. Right, same with Yugabyte, right? Yugabyte built out their platform, but you are all driving a particular point of view for the clients or ecosystem that you're trying to build. And that's because it's open source. All right, I'm going to start a new baseline here. Post business frequently considered the most seasoned and stable of databases. Now, I wouldn't say databases, I'd say open source databases. I think that most people would agree that even Microsoft SQL at this point is about it. I mean, outside of its unfortunate choice of operating system, it's rock solid. What do you guys think? Dennis, let's start with you. You've been around as long as I have, actually a little longer based on your hair, but why don't you help me out here? What do you think about the stability of open source databases? Well, I mean, there's the strength. The strength is that it's adopting new features in a very systematic way and making sure the core team is really supporting that feature and that there's enough people interested in maintaining that feature over time. It's very frustrating for companies to submit something and then see it go backwards for a couple of years, and then they increment just pieces of it so that it's built stably and consistently in the product. But that's, you know, the frustration of that is also the strength of that too, right? So it's like, and it's managed to keep together a core that fosters, you know, everybody staying together and wanting to, you know, to the degree that you're forking and running in parallel. It gives business models different ways to go, but it's a real strong core to build on, and it nicely supports different business models around doing that, and everybody wants to keep up with core Postgres because as much as it doesn't move as fast as we want, it keeps moving very fast, so you have to keep up with it if you're innovating on top of it. So it's, you know, it is what it is, a better system, and Postgres has really survived the test of time and really out survives any individual company that's working on it. People come and go within the community and work for several of the companies and things like that. Really just a testament to the stability and robustness of the core and that the fact that they move they move slow and it sort of prevents missteps and they're not going down some paths that people are trying to innovate on and I love the, you know, as I said, extension model and doing hooks on it so that you can people can kind of innovate in consistent ways. So I'm happy with the state of the state and I think it moves, I think overall it moves at the right speed, right? I would love to be, everybody would love for it to be faster, but everybody needs it to be a rock solid core that they can build, you know, solutions on and the companies all here are doing that in related and different ways. Haike, you want to follow up on that? You know, we talked about the speed of the lump and then there's the saying that the ultimate stable product is the one that's dead. So you need to strike a balance between how quickly you move into any particular direction and how stable it is. That said, I'm afraid that's also a little bit of a coping mechanism that we keep telling ourselves that, you know, we value the stability and that's why we don't do, you know, accept new features as fast as we would. Another reason for that is that the push this core team, the community, the community are just very short staffed and very busy. So that limits in how much we can just digest, like if someone comes up with a large patch that requires work, that's a tough pill to swallow as a committer, like I don't necessarily want to take on the responsibility of maintaining like a 10,000 by patch that the company submits. But the bigger problem with another problem with, you know, accepting large new features is that all of the new features we accept, they need to play nicely with all the other existing features and that's always, like that's a big reason why we do something is the way we do. For example, upgrade, it works kind of funnily in Postgres and anyone who's coming from another database goes like, well, why are you doing that? So in Postgres, you need the way PgUpgrade works is that you need to have the old and the new binaries around and then we do this, we are to dump the catalogs and restore the catalogs, swap files under the hood and now you're up and running. The way most databases do this is that the new binary can read the old format. But if we did that, that would kind of tie the hands of the developers. And currently we have a lot more freedom to change the catalogs and it's a lot less maintenance overhead, even though it's a bit more effort to the users. So someone could argue that, hey, there's like a million users of Postgres and only 20 developers actively, so shouldn't we value the user's time more than the developer's time? But in practice, when you're developing it, that's the decision that gets made. Well, I think that that's actually, the PgUpgrade is a perfect example. And thankfully now, obviously we have logical replication, which can take a lot of that pain away. But I was speaking with Theo Schlosschenegel years ago about this problem and he was like, look, all you got to do is X. And what he basically said was you can install the new version on top of the old version, the new version would detect, it was an old version catalog, and they would migrate it as things was accessed. Now, that's certainly true. I mean, all we have to do is X. But who's going to maintain that? And in a situation like that, I think that there is a benefit to the larger corporations coming in. You know, when you have Amazon, who's now the fourth largest contributor to Postgres, and as other companies hopefully continue to contribute, we get more committers, we get more known respected hackers through reputation of quality, and we'll be able to maintain those types of things. But if you're saying to yourself, all you have to do is X, unless you're going to put up the million dollars in engineer time to support that, it's not that simple. And I think a lot of people forget that, especially who are what, you know, if you make it easier for the user, well, of course, that'd be great. But we need hands, bodies, brains, right? Where are you at on this? Because you've got to, you're not really working directly with the core here. You're working more on the extension, you know, external ecosystem here. You would, I would think have an interesting viewpoint. Yeah, and I think, you know, I'm just coming off an experience of building the Apache Airflow open source, let's call it ecosystem, you know, we basically raised $300 million. We ended up having, let's say, 25 of the top 40 committers. And I think that's like an anti-pattern in my opinion, even though, you know, the leadership of our company was excited to try to see how much of the core we could control. Like, I think, you know, I'm really impressed by how balanced Postgres feels. And I actually kind of like the idea that the core team is small, focused and slow, you know, and allow the community to do the, you know, and they're focused on those hard things. And I've known that inside of an open source project, the hard things are so incredibly hard compared to the products that we build, you know, commercial products. And so I think keeping the core team focused on that inner hard part is important. You know, we employed the developers who did that core work at Astronomer, and it would never have gotten done if we didn't pay people to do it. But the community kind of worked on the edge, you know, and that's where I see extensions in the Postgres ecosystem now. In Airflow, we put it all into one big repo, you know, and we had, you know, 1500 contributors to it, which is very different. You know, I think that there's definitely some thing like the fact that we do development core development in Postgres is on a mailing list. It's just like really bizarre to me, you know, coming to the community. And, you know, I know it's really political to pick a platform now that's such a big community. Like, I don't know, like, I think GitHub has lost some cred, you know, GitLab is a weird decision. So it's really hard, you know, it's just hard to pick a technology platform anyway for this sort of stuff for an open source project. But, you know, I just think, like I said, I'm pretty impressed by how it's structured right now. And I think it's evolved to a really good state. And, but, you know, like, it's just unusual in the sense that, like you guys were talking about earlier, like there are like forks in most open source communities are considered like an attack on the core. And here I don't think it's that way because it's thrown to such a state that, I mean, it's been done 50 times now. I mean, how many core, how many forks have happened? And, you know, it starts to roll off your back, I guess, eventually. And it's nice. So it's interesting you bring up the mailing list thing. The mailing list is demonstrably a barrier to contribution at this point. But there's a history there that a lot of people don't know. The reason that Postgresfield.org is so centrally focused on controlling their development process is that many, many, many, many moons ago, they went all in on a $15 million investment funded company called Great Bridge. And this company was going to build the next great enterprise database. And the next great enterprise database was Postgres. Heike's going to laugh at this. 7.1. We couldn't even run 24.7 and 7.1. We had no, I mean, the vacuum was a blocking operation the whole bit. And in fact, Great Bridge is not only the reason why Postgres is the way that it is, it's the reason why my company is the way that it is command prompt, in that all the bad decisions that Great Bridge made in a very short period of time put them out of business, I think it was like an 18 months or less, which opened the door for command prompt to enter the market where it's at and taught the Postgresfield.org community the leadership at that time a very hard lesson, which is when you rely on other platforms. And this is everyone on this call recognizes this. I mean, there's no code.google.com anymore, for example. And this is why they won't move to GitHub. Fundamentally, GitHub can go away tomorrow. Fundamentally, GitHub, Microsoft can say, you know what, everybody has to pay $5 a month to goose revenue for GitHub. And it basically just eliminates in the culture of Postgresfield.org the ability to use GitHub. It just does. And through the years Postgresfield.org has tried various things. They used to run a thing called PG Foundry, which was kind of like a source forward slash GitHub at the time. They played with the idea of a ticket tracker. Nothing is quite fitting the culture. So core development, core contribution still happens like it's 1993 on CompuServe via an email address. That's just the way it is. On the other hand, let's talk about the bonus to that. If you develop a project on Slack and Slack shuts down tomorrow, you lose everything. It's gone. With the mailing list, you have we have the canonical archives that can be searched since the beginning of the project. You can find the relationship from whatever was developed in 2002 all the way up to 2023. So there's it's not all bad. But I agree with you. I mean, for especially for developers, they're used to doing things, let's say after 2008. It's a little bit of a weird thing to be what do you mean? I mean, I'm on a mailing list. I mean, mailing lists are for receiving notices from next door, not for communicating with developers, right? It's just it's just different. All right. So this next question, this is my favorite question in this whole thing. And I ask that hopefully each and each guest here has one. I mean, there's lots of things. But what's the one thing in your craw in your job that makes your suit taste bad? What is the one place Postgres can improve? Karthik? For me, it would have to, I mean, selfishly from a Yigabyte perspective, it would be, you know, allowing more fundamental hooks to be able to do stuff in the system catalog site, like, you know, the, like as opposed to user tables, because at the end, when you're building always available shared nothing systems, doesn't matter which piece of data goes offline, any of it is all of it, right? So, but specifically on Postgres, I would say connection management. So like the like lambda applications, new connections being spawned the time it takes, like those type of things, right? Like, and so yeah, I do know PG Bouncer bunch of stuff exists. Those are always hard to use. There's a Clujie. Yeah. So anyway, that'd be the one thing that I'd say we're doing work to integrate that to make it native. But our problem is we are a distributed system. So not only is it a PG Bouncer, but it's also across a set of nodes. And so it is more complexity. So we're natively trying to integrate this into the database. But yeah, I'd say that that's, that's one of the areas. I mean, yeah, I have a few others, but yeah, you said one thing. So the number one, Kevin, up to you. Yeah, so I'll try to get to the point quickly, but I'll start with customers who have been driving us to make Postgres easier to use and easier to manage. And so in LEDB, we built a bunch of ML driven capabilities for that. Things like adaptive vacuum and adaptive memory management and an index advisor. These are all ML driven things. But taking a big step back from that, what I think would help Postgres is to build more better observability into the core engine, which would then enable lots of AI driven models for two things, one for better app development, make it easier to use Postgres, let it happen to know about all the sharp edges, and two, better management of cattle versus pets. If you have more better metrics coming out of Postgres, you can build better models and automate more of the hard things that right now are hard to automate. And right? Yeah, I just think to me, looking at Postgres competitively against the new DB is like, it's, it's a, it's, I'm gonna go right back to a really hard one, cloud nativeness, you know, and I get that it doesn't seem like it should necessarily have to be a default, but the competitors, you know, I think the competitors of the future, not my sequel, not the stuff from the past, but the competitors of the future are gonna have that and will have that. And that's, it'll become a bigger, I think Achilles heel over time. If we, if it's not addressed sometime, you know, in the next decade, let's say. Dennis? Yeah, yeah, I would say, I mean, there's a lot of opportunity in this area and a lot of things that are right, but in the area of like worldwide Postgres conferences and stuff like that, I think there's a lot of, you know, sort of differences of opinion of, you know, commercial versus community, how the US does it versus how Europe is going to do it, whoever. And I think we can, as a group, do better in the coming decade to everybody has the same interests in mind and Postgres and respecting each other's differences, etc. So I think that we can do, I think that we're doing well with that. And I think in the coming decade, even better. All right, Hike, I left you last because you and I have the most particular insight to this and yourself as a committer. What is it? What's the number? What's the one thing? I agree with what Karting said about the connection management. That's what I had in mind. Vacuum, XID, wrap around those things we talked about. But I'm going to pick something that hasn't been mentioned, which is doing more with OLAP, having a column store and being having a better executor for OLAP kind of queries. I think that's something where Postgres is a little bit falling behind at the moment, even though we're doing well with all the people who are close. Okay. Well, let's see here. We've got a little bit more to go. A lot of this is, this whole podcast is about the future of Postgres. And there's a couple of things. There's the postgresql.org, which is a little bit difficult to speak to because it's driven organically. And now we're starting to see large corporations contribute on a level that we never have before. So it's going to be interesting to see where postgresql.org goes in five years, 10 years. Frankly, at 10 years, I'm hoping I'm retired. So good luck to it. But the a more interesting thing to me, I mean, we've talked about cloud native. This has come up a couple of times. And for those who don't know, there is a cloud native project. One of the leads on it is Gabrielle out of Italy. And you can run Postgres with Kubernetes. I mean, it's not the simplest thing, but then again, neither is Kubernetes. So you kind of get what you deploy with. But I think, you know, this is the ecosystem. So where do we see the ecosystem going? Because for example, in Neon, which has its own interest in play, if I recall correctly, a lot of the stuff that you're building, Haikey, is based on Rust, correctly, correct? Yeah, Rust is exciting. I like the language a lot. Coming from a C background, it feels like a breath of fresh air. But at the same time, it feels really familiar. And then, you know, we have, you know, Karthik, you've got, you've been doing this for a while now, but you're distributed SQL. And Dennis, that's what you're doing, right? Is the distributed SQL, but differently than Karthik. Karthik's got an integrated fork that's open source, you write, and you decided to go the Band-Aid route. Leveraging what you can do in extensions and making incremental updates to the core, etc. So to do conflict resolution and stuff like that, and building on some of the things that were in the original BDR from Enterprise DB, and that were in PG Logical, but the core never really adopted because it involves multiple instances communicating with each other or wherever. So it's like there, we are approaching probably less, with less core work than, than what, than what Yoga Byte is doing. But I wouldn't go so far as to call it a Band-Aid, but a strategic use of extension. Hey, I didn't say it. Jenny said it. Well, for those in the audience, you have to understand we all know each other. This is not, you know, this is not some generic, you know, panel of people that decided that were pulled together by marketing folks. We all know each other. Hey, Kevin, talk to me a little about, you know, because alloy DB, I mean, it's, it's not new, but I would call it in terms of the forks of the cloud. It's probably the youngest of the large deployment providers. How do you see it fitting in with the ecosystem? And most importantly, you already had a Postgres offering, like Google Cloud Postgres, which is essentially the Google RDS, as I understand it. But now you came out with alloy DB, and alloy DB seems outside the fact that it's hosted or managed. It seems like it might compete a bit more with, for example, with Neon, with Hikey or Aurora would be another example. Can you talk to us a little bit about that? Sure. So yeah, you're right, alloy DB for Postgres is relatively new. It went GA last December only and was announced last May. So yeah, it's been a public thing only for a little more in a year. Obviously, we were working on it before that. But yeah, it was first to, you know, reveal to the public 14 months ago, or 13. And so, yeah, the conceptually to really high level, the most direct comparison is Aurora Postgres, where alloy DB separates compute from storage and then teaches the storage a whole bunch of intelligence about Postgres wall records and Postgres block formats, which allows us to then reduce the amount of work the compute side has to do running the Postgres engine. The work that's reduced or eliminated is writing dirty pages. I mean, that's the same. It's basically the same core benefit as Aurora Postgres, right? Does the same thing. You have a storage layer that takes log records and applies them to pages asynchronously and independently of the workload. And so that reduces the amount of work the amount of CPU literally that a right heavy workload has to consume on that head note on the database note. That's, you know, at a really high level, that's what alloy DB does. But we did a bunch more work than that. In alloy DB, I think I mentioned before to make it scale higher, especially on larger SMPs, you know, bigger, bigger servers, or bigger instances. And then did a bunch of automation to automatically manage memory. So for example, the Postgres buffer cash is not static and I would be it goes up and down dynamically based upon the workload. And so we moved memory around between different memory structures. And vacuum, we basically give more or less resources to vacuum based on the workload to try to get back him to keep up as best it can. Again, this is all automatic. And then the index advisor is something we recently launched, which does more of the same. It looks at your workload, suggest indexes that you might want to add. You can have it run in full autopilot mode and add them itself if you want. But the, you know, we're seeing all we're doing all that kind of stuff in terms of taking Postgres and trying to make it better for the cloud. We aren't directly doing the kinds of things you see in neon or yoga bite or others where we're not trying to distribute the right workload. Right. It's still very much single right note and a bunch of read notes as much, you know, not as much as you want, but you can go pretty high in the number of read notes and the size and all that. So you can scale out the read workload that scale up the right workload. So, you know, that's, that's what we've been focused on. I think what you'll see to go back to an earlier topic, but it's kind of germane to the question at hand here, I think you'll see us making more contributions back into the core of Postgres. As you mentioned, JD, it's not like you can just do a pull request, throw some code in and watch it, watch it show up in the next major release. You know, it might take a couple major version cycles just to get stuff in. Because I mean, it makes sense. We're going to propose core changes. You know, our people have to be trusted by the core people, the core group that looks at those changes. And, you know, again, throwing code over the wall, who's this guy and how can I trust their code? It takes a while, and it should take a while. That's the other side of the coin of being conservative about changes. That's why Postgres is so stable and trusted is because it doesn't do wild, crazy stuff on short notice and break things and, you know, lose data. So I mean, I think that's really why customers are one of the things they're learning about Postgres is that it is stable and that's a good thing. Yes, there's some things they'd like to see improved. But let's be careful. I think that's what they are saying. But yeah, Neon architecture is actually most similar to LADBs. We also don't spread the virtual workload. So it is the same separation of computer storage as in Aurora and Cloud LADB. That seems to be a common pattern. There's now three implementations for Postgres. One of them is open source. So I'd like to hear your perspective on exactly what kind of changes would help your life for LADB from that separation of computer storage. I do actually wonder if there's something in core that would help that. We know the troubles we ran into while doing that, but I'm sure we're overriding to the same issues and I'm sure you're also running into the same problems. And also, Kevin, as you're embarking on the journey of scaling out writes as well, like we take off like about roundabout middle of where allowing Neon start go all the way to the Spanner, the fully right scalable variant. The interface would be next to the interface. Yeah, I mean, of course, you probably know there's a Postgres interface in Spanner, which we're continuing to expand. So part of the answer, if you really want to scale a Postgres workload is we steer you towards Spanner at the moment, because Spanner really does have kind of unlimited scalability for writes. But on that point, Spanner is not true Postgres though, right? It has only like, you can't do everything in Postgres. No, like you can't do that. Yeah, we're trying to trade that balance where you're able to do everything yet scale. But I thought that's what you mentioned about alloy, but anyway, maybe wrong. Yeah, no, well, we aren't directly working on scaling out writes and alloy to be at the moment. I mean, most workloads don't need it. That's what we see. Customers bring us workloads that don't need, you know, 64 CPUs for the right traffic. They might need more reads, but reads are easy to scale with replicas, right? And so what they need is a system that will stay up and running, despite failures of all kinds. So they need good HA, they need a good SLA, right? They need very low RPO and RTO. Sometimes they need zero for some of those, those are harder to build, but yeah. So that's, you know, kind of what we're focused on. Now, to hike this question, I just remember in the early days of these projects where you have to figure out how many different types of wall records there are and make sure you handle them all. And that's just that by itself is like a big complicated Harry S project. And, you know, I'd love to see the community not add 17 more types if they can avoid that. But, but, you know, more, you know, that there's also the challenge of Postgres writes to files. And all these systems turn it into block storage underneath. And so conversion from files to blocks and back can add inefficiencies. I know there's work in the Postgres core about making it easier to plug in different storage systems. And so work in those areas, I think would help everybody who's trying to do the separation of compute from storage thing. It will probably help people like you have to wait as well. All right. Hey, where are you on this? What, you know, where's your goal with the ecosystem? Well, you know, to me coming in, it's just clear to me that there's a challenge in the sense that like, I love what I love the idea of automatic dynamic memory management that you just talked about, Kevin, that would be really cool to have access to because we're building a new cloud and we're like, okay, how do you can, how are we going to configure these instances? You know, with some percentage of RAM, you know, I love, you know, it's like the users just start with because the core is so small, this is the downside of the small core, right? Is there's just so much to, if you actually want to look directly at Postgres for a minute and not just use a managed service, it's a lot. You know, it's I think self-hosted users, you know, go through a lot of pain. They don't really, if they're a developer, they really don't want to learn about the insides of the configuration in Postgres. So I don't know. I think, I think, you know, we're trying to join up with like the Cloud Data PG project or, you know, we want, I think there needs to be another wrapper project around the core that makes cloud nativeness or just like defaults, better defaults, more accessible. So that's really where I am right now is, I think we need a, you know, extensions are an outer ring. I think we need like an inner ring of standardization that would be maintained by the non-core teams because it's, again, they've got enough to do with the core, but it's not good enough for me, you know, because, or even for Kevin, you know, like they had to build this thing on how to deal with memory in a smart way rather than a very static, old-fashioned way. Dennis, how about you? Where are you at? Right. Well, I like the, you know, I think of it like there's the extensions that come on and then there's the forks that are kind of proprietary. They're doing some cool things. Some of that is very, they're leveraging things in their back-end platform and how they do containers and things. So there are some things that are hard to do in a generic way, like dynamically changing memories, depending what environment you're in. It's like, it doesn't really work that way and trying to do that across operating system platforms. So there are some areas that are, that are, you know, for a, for a hosted provider, a cloud platform provider that can take advantage of some of the features of their things like it's a, it's a natural thing to do. I, I think of it, you know, for, for cloud-native storage, right? And I think Hakey makes this too. It's about enhancing the, you know, the hooks that, that people as they're developing these different systems, he's like, we all have this common hook, right? That's really helpful to everybody. It's sort of developed in an open way. And I think you see that kind of stuff happening in, in logical replication, you see it happening in, in blockstores, you see it happening for being able to put it, do more in extensions for a different file system. So there's, there's, there's a lot of these group areas. And I do agree, we could sort of do better at maybe structuring those, but there's, there's group areas that companies are really interested in cooperating on so that they, they can keep adding value without diverging more and more from postgres. So, and I like that, I like that system. As I see it in some of these things, we can do better with that, but that's, that is, that is working. And I said there are groups doing these different things and, but doing that in perhaps a little more formal way, perhaps a little more open way can happen. But it is, it is happening some and it will, will happen more across several areas of the product that people are specializing in in their company. Some of the big companies are specializing in everything, but you know, that's, that's what, that's what they can do. All right, Hikey, you're up. What's the question again? That's such a good question. I don't, I don't even remember what the, the question was. Since this is about the ecosystem, right? This is primary, the future of the postgres ecosystem. Where do you, Hikey, where do you see the ecosystem moving? Where does Neon have its play? That type of thing. So, Neon, at Neon, we want to be the best hosting provider for Postgres and, and the separation of compute and storage. That architecture is at the core of that, that enables, you know, serverless stuff. Getting for, you know, for me personally, getting the stuff that we need, which means some kind of an API for, to be able to plug that, that storage, that matters a lot to me. But other stuff that, that I ran into, or, you know, all of that stuff about connection management, we talked about needing PG bonds or being able to expand the memory size, like all of that resonates with me. I think those are, I wish we would have a better answer to those things. And it shouldn't be impossible if you look at other databases. It's not, it's not an unsolvable problem. Other databases do a better job at managing memory. In a way, I think the hardware development has actually kind of relieved the pressure on that a little bit, like machines are just so much bigger now that we can, you don't need to track the memory as carefully as we did before. So I think we're actually getting away with a lot more of that in Postgres than we used to. But still, I wish we had a better answer to those things. For the extensibility, like we talked about extension points and then companies, you know, if you could just have this little hook there, then we could plug our own thing in there. That's always a little bit tricky for the community. Like from a community point of view, you don't just want to give the ability to link into whatever random data structures, because what does that mean to the maintainability? Like if you need to support that any random piece of the code can be replaced, like that, that's not really workable. So when the API interfaces, I think Citus did a great job with their column store work. They started with the foreign data wrapper, but then they worked on the table AM API to be able to replace the heap with an extension. But that wasn't just a little hook somewhere, it was a really designed API. Like what exactly does it mean to replace the table access method? So that's always the hard part with providing for this extensibility in Postgres. Like what exactly should the extension point look like so that it makes sense for not just one random use case, but hopefully multiple use cases and in a way that we can keep supporting without changing that. All right, Karthik, 30 seconds and then we've got to wrap this up. What do you got for us? So on the community side, like I think from a yoga by perspective, our aim is to make us a viable solution for mission critical applications that are cloud native. So we were talking about Oracle SQL Server DB2, these databases that are already running mission critical applications. And the gap between these type of databases and Postgres on one side, as well as where the world is headed with cloud native on the other side. So we're bridging that gap on both sides. So that's really our focus. Obviously cloud native, we talked about how there's a need for inherent resilience, inherent application, whether it be system catalog, user tables, whatever it is. But like I think this question is on ecosystem, so I'll focus on that. There's two parts to the ecosystem. As I see it, there's co-parts in the ecosystem of Postgres, this core features of Postgres in its ecosystem. And there are truly ecosystem enablers which extend the capability of Postgres. Like I think connection management is an example. But I would say like, you know, I'm with Kevin on the memory management stuff. Like we've had to do it as well. We had to do quite a bit of work to deal with, like even things like index advisor or a number of other things, right? Like these type of projects, like for example, audit logging and trailing or, you know, observability, like even PG stats statement, which is so fundamental to Postgres is actually technically a part of the ecosystem, right? It's not core Postgres. So these parts of the ecosystem, I think should, I think I'm just going to say what I feel about it. Subsumed into Postgres, core or core plus one doesn't matter as Rai put it, doesn't matter which ring it is, but it should start getting more and more subsumed and integrated. And like that is something that we are doing ourselves, like for each of the pieces, like, you know, each of these pieces and more, right? And there's more needed in those areas. Like it's not just, for example, observability from a point of view of you can tell what's going on, but also from a point of view of correlation and figuring out, did the workload change, for example, or is it something internal to Postgres or a feature that's missing or so on and so forth? So I'd say that's that. But in terms of the wider ecosystem, I think Postgres is in a really good situation, like all of us talking here, all of us are doing something to extend the ecosystem in some way. And this is just going to keep growing, which means there's going to be a growing body of work to support that. As a lot of people have said, it's not easy. It's not the wild west. And I'll close with saying, JD, you said we just need to do X, right? Like, well, all of us are here just to read what you have written. That's it. There's nothing else. I mean, you can't do that. But, you know, it turns out it's an incredibly hard problem. So just doing X has to be done very thoughtfully. So I totally, totally empathize with like, you know, I've been a part of many communities like Cassandra H base here, a lot of different communities and can totally appreciate that it's not an easy problem maintaining stability while innovating, because it's very easy to say, give me features really fast and all and make it really stable. It's very easy to say that, but it doesn't quite, not the correct way. All right. I have one thing to add. And then I will close us out. Carson, Kevin, and unfortunately, Hikies having connection issues, but Hikie, the three of you seem like you've got some of this that could happen that can maybe push that back to the core. There's no reason for Alloy or Yugabhite or Neon to have three separate implementations of dynamic memory allocation. I mean, obviously it benefits you individually because you've already built it, but it does seem like if you guys got together and said, all right, this isn't particularly unique. Now we have three, four, five, six different implementations. Why don't we build one? It might benefit everyone. All right. Dennis, Kevin, Rye, Karthik, Hikie, I apologize. I'm sorry you're having connection issues. Thank you so much for your time. This has been fantastic.