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.  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.  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.  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, 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.  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.  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, 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.  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.   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.  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.  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.  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.  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.   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 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, 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 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.  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?  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.  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.


Alright, we'll take a look at one of the most important results in probability and statistics. This is something known as Chebyshev's theorem. Now, just as a caution, Chebyshev has a number of different spellings. It's mainly because it's a Russian name that's been transliterated into the Latin alphabet. And so, one common spelling, if you decide to look up more about this guy, you can spell it starting with a T, S, C, H, E, B, Chebyshev. Actually, some of the older spellings have a V at the end instead of an F, and some of them even start with an S, H, Chebyshev. And the most common modern spelling seems to be to use the spelling C, H, E, B, Y, C, H, E, V. But note that there are about four or five different variant spellings, depending on who's doing the writing. And Chebyshev's theorem says, given any probability distribution whatsoever, regardless of what the mean and standard deviation is, take any value of K greater than or equal to 1. You can take K less than 1, but it doesn't give you anything useful. The probability that the random variable is within K standard deviations of the mean is at least 1 minus 1 over K squared. Now, that's quite a mouthful to process, so let's see if we can do an example here to clarify what we're talking about. Pick a value, take any K greater than or equal to 1. Well, how about K equals 3? So then, I have my random variable X with some probability distribution. I don't know, I don't care, it doesn't make a difference, because Chebyshev's applies to any probability distribution. The probability that my random variable is within K equals 3 standard deviations of the mean is at least 1 minus 1 over 3 squared. That's 8 out of 9. Well, again, the example doesn't necessarily help us too much, so let's try and apply it to an actual situation. So imagine that I have some sort of test, and the test has a mean of 70 and a standard deviation of 5. If we calculate or find those using whatever means we have, and what can we say about the probability that a given test will have a score between, say, 60 and 80? Well, the first thing we note is that if I take K equals 2, Chebyshev's will tell us the probability that a score is within 2 standard deviations of the mean, that's 70 minus that's 60, and 2 standard deviations above the mean, that's 80. And Chebyshev's will tell me that the probability that I land in this interval is at least 1 minus 1 over 2 squared. That's 1 minus 1 quarter, 3 quarters, or 75%. And one of the things that this does is it allows us to make very, very general comparison with very little in the way of required foreknowledge. So, again, let's take our test of the mean of 70 standard deviation of 5, and suppose I find somebody who scores above a 90, or maybe somebody who scores below a 55. What can we say about such people? Beyond the obvious statements like, this person did really well and this person didn't do so well. And so what I might begin with is I might note that this score 90 with the mean 70 standard deviation of 5, this 90 is 4 standard deviations above the mean. Now, Chebyshev's tells us if we have K equals 4, then the probability that a score is within 4 standard deviations of the mean, 1 minus 1 over 4 squared works out to be 15 out of 16. So that tells us that at least 15 out of 16, the probability of a score being within 4 standard deviations of the mean is pretty high. So the probability of being outside that range is at most 116. Now, these are probabilities, so it's helpful to think about them from a frequentist viewpoint. Now, what this means is that a score of 90 or higher is very unusual. 15 out of 16, about 94% of the scores are within 4 standard deviations of the mean, which means they're going to be less than this score of 90. So just from the mean, standard deviation, an actual score, plus Chebyshev's, we have a remarkable conclusion. Most of the people who took the test, at least 94% of the people who take that test are going to score below this 90 value. So this person who scores a 90 is in a group that constitutes at most 6% of the test takers. Well, I can do the same sort of analysis for the person who scored 55. So in this case, we'll note that 55 is 3 standard deviations below the mean. So Chebyshev's tells me that the probability that I'm within 3 standard deviations of the mean, 1 minus 1 over 3 squared, that works out to be 8 9ths. And so the probability of being more than 3 standard deviations below the mean is at most 1 9th. If 8 9ths of the scores at least are within 3 standard deviations, then at most 1 9th is going to be outside of that 3 standard deviation interval. And the bad news for the person who scored the 55, most of those scores are actually above theirs. So again, if we look at the problem from a frequentist's viewpoint, this means that most of those who took the test 8 9ths, because they're within 3 standard deviations of the mean, they're going to be higher than the score of 55. So about 89% at least of those who took the test are going to have done better than this person who scored a 55. And again, we can consider this as another case again, keeping our test of the same mean, same standard deviation. What if I get somebody who scores higher than 80? So I'll note that 80 is 2 standard deviations above the mean, and by Chebyshev's probability of being within 2 standard deviations of the mean is going to be 1 minus 1 over 2 squared, about 75%. So again, taking our frequentist's viewpoint, at least 75% of the test scores will be within 2 standard deviations of the mean. So the probability that somebody is going to have a score higher than 80 is going to be at most 25%. Now, the thing to remember about Chebyshev's is that it applies to any probability distribution whatsoever. The only thing we know, the only thing we need to know is the mean and the standard deviation. If we know nothing else, we can still apply Chebyshev's. Now, a little bit later on, we'll start to look at more specific distributions, but Chebyshev's is a good fallback position. If you know nothing else, you can apply Chebyshev's. If you do know something else, you probably want to apply that because it'll give you more precise results.


As we gather to celebrate our nation's independence day, we think about leadership and it's easy to think about General George Washington. He's depicted in many works of art such as Crossing the Delaware and Surviving the Winter at Valley Forge. Behind his singular leadership, General Washington had a superb team that provided multiple perspectives for him to consider. General Nathaniel Green had little military experience but planned and delivered a brilliant Southern campaign. General Henry Knox studied military history on his own and became a master strategist. And Baron de Stuben is often considered the Army's first teacher. He became the military's first Inspector General. It is hard to imagine what General Washington would have accomplished without his team. Lead well this week.


What's up everyone? It's your girl Kenzie here from Leighton Sports Cards. I'm ripping a few personal boxes here for Jeremy B We've got three of the brand new release 2021 Panini Daunriss Optic football hobby box All right, best of luck here Jeremy. Let's see me and get you. Let's see some more downtowns I haven't seen any QB Inc yet, right? I don't think I got QB downtowns, but no QB Inc Let me get this open my gosh Jaylen Phillips, holo Alvin Camara Dimple up there right on the top you can kind of see Leatherwood rookie There we go trace our man. We've got dominators ice to 15 Patrick Mahomes boom There you go Jeremy nice patty 15 of 15 triple jersey number Wow nice Jeremy. We'll mag that one for you Heck yeah Love the jersey number on her long to 199. Joe Montania Jacob Harris awkward at 299. Josh Jacobs Jake funk. We've got a Kaderious Tony to 25 on the Black Pandora auto Another beautiful hit here for you Jeremy Love the Black Pandora. It's hard to show. There we go Kaderious Tony to 25 You go we'll mag that one too I like the black on that card. It kind of makes it pop Trouba hovered we've gotten gold the champ is here Mike Evans. What is going on? Jeremy heating up That is five out of 10 Nice box Tommy Trembel. We've got Michael Carter grid iron kings That's in this box are not cooperating kind of gain. Well, we've got orange the 199 pat fryer moot rate of rookie Jamar Jefferson got awkward at 299 Kyler Murray Baker got Kaderious Tony rookie Richie Grant global refractor of Jamie Gillian Browns Shai Smith Chinalt junior on the uh Silver circles to 125 Calvin Joseph purple to 50 on the color match captain Kirk Cool color match Jalen waddle rookie got hollow ron-del moor reader rookie Nice one there carbons great Russo rookie Got a dyke coming up Kyle Pitts and Jeremy killing it with the parallels out of this box. Wow Five out of 25 That's nasty Those ones are hard Wow, that is sick Jalen darden we've got red the 99 Marcus Davenport What's up Isaac? About an hour and a half tops I would say about an hour Hope all as well. Elijah Mitchell. We've got blue to 179 Corey Davis. I would definitely get an order in um only live until three today Forest goes live at four. So he's got out of time to set up. We'll fuller the fifth on the hollow dolphins. Yeah, sure thing box two killed the first box there jeremy Very nice Elijah Mitchell. We've got Kaderious Tony orange to 199 Caleb Farley got aqua to 299 diamond brown Washington Davis smells rookie red to 99 chanel jr No aside, we've got blue to 179 Tylen Wallace Ravens Yeah, Joe Bynum. What's the first one? So rat we've got silver circles to 125 Devin white came to fluoride that code Purple to 50 Mike Davis Falcons Yeah plumbers, uh, I think they did a great job with the the amount of colors they put in this year's boxes You know, I definitely feel like they're more loaded than last year's hollow red to rookie paint Turner And not like in a bad way, you know, like it's not like they over print it. There's still only like One two three four five six seven eight nine ten 12 total colors, which I don't think it's crazy amount Orange to 199 jimmy g the only new color. I think this year was the ice that was out of 15 Frank Darby aqua to 299 g miss winston vick rick newson the second My girl got a wmba player the year again Candice Parker jamar j jamar j jamar j I've been a fan of her since she was at Tennessee We pay rated rookie to 40 a brevin jordan on the blue rated rookie auto texas Got mac jones rookie Barrett Tucker my house matty ice Curious to see how he does with the Coles this year. I think he's gonna have a good year Jamar chase rookie. We've got hollow devon whites saving Collins rookie Tommy brown. We've got legendary logos hollow matt stafford Desmond's patrick.  I don't know what you call that terrace marshal jr. And the rookies of tray lance Just a base that though nothing crazy on that. All right box three here. What's up six? Uh-oh Jay green anthony schwarz brevin jordan gifted rookies tray sermon what the little's get into now Sam ellinger, we've got red the 99 jamal williams got justin fields rookie and black pandora jj watt for the cardinals to 25 Nice one there 16 to 25 Black pandora sounds interesting When minors we've got rated rookie to 125 hollow auto kyle trask You know, jeremy solid one there. I like that like majority of them are on card too Except for like the inserts and like a couple um face rising suns joey b Got davante smith aqua two two ninety nine terry mclauren Slater silver circles to 125 justin jefferson kellen mons and hollow kurt warner Cardinals kylan hill we've got mythical short print joe montana. There you go jeremy This case hit short print on the montanya We'll mag that one for you j watt andre sisco michael carter retro series hollow jerry rice amazon stocks interesting Those are expensive aren't they take paint and turner orange the 199 url camble everything kind of dipped right now, huh? I don't really do stocks rondell more we've got rated rookie aqua to 299 lairie round tree the third mo su core moa anthony schwarz hollow rated rookie Good luck with that url camble 2 2 out well During the holidays Bashom red hot rookies hollow kyle pits I know what christmas is coming up and yeah Elijah mold and blueda 179 dj charg jr jacks got by oa aqua to 299 kevin buyer And last factor for you jeremy very well with your optic boxes Elijah more and a quinnon williams hollow Alrighty jeremy that will do it for your three boxes of optic congrats again on your hits. Thanks for hopping in and we'll get these right out to you


Okay, I love you sweet glasses What's your patriotic message Brandon? Oh nice. That's good. It's what the founders did, right? And fought wars I'm a lover not a fighter Independence Day. It's all about the wars Sorry for the delay Thank you play-by-play from Lauren on the grilling efforts good. So you got burgers coming, too Okay, but last year I mean not to put any pressure, but you did have a heat thermometer Or a meat thermometer. I think I'm gonna skip that this summer. I think you should too much work I just actually bought a new one because we really needed it. We did we did ribs the other night and should have had one it didn't But let him sit on top there for a while. They'll be nice and nice and sharp and you got it. You know Yeah How'd that good you guys recovered from camping? No pressure.  No pressure As always cheers. That's how Brandon does it It's not afraid, right Kyle? It's tasty. I must say it's uh Nice and calm Which is good It's it's good for us another day Which by the way Kevin and Brianna great party great party delicious food amazing Okay question of the day. I ask this every year on july 4th because it is simply incredible It speaks to the uh, divine nature of the united states of america Two gentlemen helped found this country meaning they sacrificed a hell of a lot to make this country exist they helped write the declaration of independence and did a lot of other things So which two presidents died on july 4th? You probably already know this because I asked the same question last year But do you know pause because i'm about to tell you the answer Thomas jefferson and john adams i believe in 1825 Died on july 4th within hours of each other these two guys fought So hard to found this country to write the declaration of independence to lead the country through the infancy stages of Oh a cookie. Thank you And it just it's cookie time. It just speaks to the uh How blessed we are to be americans and I think it speaks to how blessed we are to be americans because It's what are the chances what are the chances that those two presidents those two Friends at the end of their life died on the same day within hours of each other Hundreds of mile tj tj in virginia and john adams in massachusetts. I mean, what are the chances? I digress I digress


So once you have equations, you have inequalities. So far, we've solved linear inequalities by finding critical points and evaluating test points. We solved quadratic inequalities by finding critical points and evaluating test points. We solved root inequalities by finding critical points and evaluating test points. We solved rational inequalities by finding critical points and evaluating test points. This suggests that we'll solve absolute value inequalities in the same way, and in fact we will. At least for now. Because of the geometric meaning of absolute value, we have another way of solving them. So let's start off by solving this absolute value inequality in exactly the same way we've solved all other inequalities. First we'll solve our absolute value equation, and so that's 8x minus 5 equals 3, or 8x minus 5 equals negative 3, solving that gives us our critical values. Again, like a good human being or a good math student, we recognize the inequality. So let's graph our inequality. Since the inequality allows for equality and the critical values solve the equation, then we can include the critical values in our solution. And now we'll test a point in each of the three intervals. In the first interval we'll test x equals 0, and this is true, so we'll include this first interval. Now we have this middle interval, and we have to check something in this interval, how about 3 fourths, and our inequality is false, so we have to exclude this interval. And finally in our last interval we can test x equals 1 million, and this is true, so we should include this interval. So here's our graphical solution. We can rewrite our solution in interval notation.


Hi, everyone. I'm Vishwa, and I'm a software engineer at StackRocs. Thank you for coming to our talk. So, if you haven't heard of StackRocs, we're a startup headquartered in Mountain View, California, and our mission is to make it possible for you to deploy your applications into Kubernetes clusters securely. To help you do that, we've built an industry-first Kubernetes-native security platform. But today, I'll be talking to you about KubeLinter, an open-source tool that we recently released. Now, KubeLinter was born out of a realization that we had over the journey of working, of building out our product. Namely, that Kubernetes YAML files are hard. They have so many knobs and dials, and it can be hard just to get your app running and your containers talking to each other. But even once you get there, that doesn't mean you're done. Kubernetes defaults are geared towards making it easy to get up and running, and not towards security or production readiness. Now, while this makes sense from the point of view of lowering the barrier to adoption, it does mean that if you're not careful, you could be placing your sensitive systems at risk. So, just because you got your app running doesn't mean that it's ready to run in production. Enter KubeLinter, our answer to this problem. KubeLinter is an open-source tool to run static checks against Kubernetes YAML files and Helm charts. So, what does that mean? How does KubeLinter fit into the Kubernetes security picture? Well, let's say you have a cluster with a bunch of applications running on it. Now, our commercial product would run on this cluster alongside your applications and do security checks on it for you, and it could audit your configurations and tell you, for example, that a certain app was running as privileged when it shouldn't be or that another app was missing a required label. But the key insight that we're trying to leverage with KubeLinter is that the applications that are actually deployed into many people's Kubernetes clusters, especially as organizations mature in their Kubernetes journey, are actually checked into a source control system in a repository like GitHub or Bitbucket or GitLab and then deployed using a CI CD system. This means that the Helm charts and YAML files that are stored in an organization's GitHub repository represents what will later become an application that they see in their Kubernetes cluster. This means that we can run many of the same checks that we run on live applications in the cluster on these configurations of applications before they're even deployed, thereby shifting security left, and this is where KubeLinter comes into the picture. That's a quick overview of what KubeLinter does. Now I'm going to switch tracks to a demo, but before I do that, I just wanted to give you a high-level overview of what you're going to be seeing in the demo, so I'll be showing you first and foremost how to run KubeLinter, how to use it to remediate violations that it finds, how to ignore specific violations as required, which you may need to in some cases, how to configure your custom checks, how to lint Helm charts and not just the Kubernetes YAML files, and how to integrate KubeLinter into a CI system. All right, so let's get started with our demo. So just to have us set up that we can test on, I have three YAML files here which I'm going to try KubeLinter out on. They're all open on the window on my right, so you can see there's a main deployment.yaml which contains a deployment. There's a main-service.yaml which contains a service, and then there's an unmaintained-deployment.yaml which contains another deployment. Now I want to run KubeLinter on these files. How do I do it? Well, I have KubeLinter installed already, so the way I invoke it is I run KubeLinter space lint, and then I pass in a list of files or a list of directories. In this case, I just want to lint the current directory, so I'm just going to do KubeLinter lint dot and hit run. And there it is. You can see, yikes, we found nine lint errors. And I should mention here that we haven't passed in any specific config. As you can see, we've just called KubeLinter lint without any arguments. So what's being run now are the default checks that KubeLinter runs if you don't specify anything. You can see that for each error that it finds, it prints out a line, and that line tells you what file the error is in. It tells you what object the error is in. So in this case, we know it's a deployment in namespace production, and the deployment's name is main. It tells you an error message. So in this case, it's telling you that the container engine X in this deployment does not have a read only root file system. And most importantly, it also tells you how to remediate. So it says to remediate, you just need to set read only root file system to true in your container security context. So I'm going to try doing that. So let me copy that key. And then when I paste this here and set this to true, I save the file. And now when I run KubeLinter lint again, you can see that I only found eight lint errors this time and the read only root file system violation is gone. Now the next violation here is container engine X is privileged. Well, let's say in this case that I actually do want to run this container as privileged. So I can't, I don't know what to do about this right now, but I'll come back to it. Let me work down the list. So we see a few more violations here. We're seeing that in still in main deployment, the container doesn't have a CPU request or a limit set in both cases. They're unset and it tells you set your container CPU requests and limits. And so we're going to do that. So here we've set the memory limits, but we're also going to set the CPU limits. And here we're going to set the CPU request to let's say for now 100 millicores. The next violation that it's found is in the service in main-service.yml and it's saying that there's no pods found that match the service labels. So we can see here the remediation is to make sure your services selector correctly matches the labels on one of your deployments. And you can see here that the selector says app main within whereas the deployment spots are labeled with app main without any. So this is probably just a typo. And we have flagged it ahead of time, which is great. Now I fix it. I save the file. And then now that I fixed a bunch of linterros, let me rerun kube-linter to see if I made progress. And yes, I have now we only have five linterros left and all the ones in main-service are gone. And everything in main-dash deployment is gone except the privilege check. Now we see in the un-maintained deployment that there's an environment variable aws-secret key and kube-linter tells you don't use raw secrets in an environment variable instead either mount it as a file or use a secret key ref. But let's say in this case you this is an un-maintained deployment and to fix this is a more is more involved than you currently have the time for. And since the deployment is not maintained anyway, you just want to ignore these checks for this deployment. Well, kube-linter has a way to let you do that. So the way you can do that is you can add an annotation to your object, which has a key of this form, which is kube-linter.io-ignore-all. And the value is an explanation of why you're ignoring kube-linter checks for this deployment. So in this case, you would probably just say this deployment is not maintained. And now when I run kube-linter again, you can see that all the violations that we were finding for the un-maintained deployment have disappeared. Now we're left with this last one, which I promised we'd come back to, which is that this container is running privileged. And in this case, we don't want to ignore all violations because this is a deployment that I actually care about and I want to make sure that other checks are run against it. But I do want to ignore just the privileged check. Well, the way you do that in kube-linter is you pass in an annotation very similar to the other one where you do kube-linter.io-ignore- and then you copy the name of the check, which in this case is privileged-container. And again, the value should be an explanation of why this container needs to run as privileged. So in this case, I'm going to say this deployment needs privileges because it accesses the kernel so that people know why you've ignored this rule. And now when I run kube-linter, no linter is found. That's exactly what you want to see. That does feel a bit anti-climactic though. I'm going to give this the celebration that it deserves. Now the next thing I want to talk to you about is how you would configure custom checks. So far we've looked at using kube-linter with only the built-in checks. Well, the way you do that is you pass in a config file and here is our example config file, which lets you configure any number of custom checks. And let's say that the check that I want to configure is that I want to make sure that all objects that I create have an annotation called team, which tells you which team owns this specific object so that if something goes wrong, we know who is to blame or who needs to be contacted. And the way I figure out how to do that is I go to kube-linter's documentation and I look over the list of check templates and we have a check template for required annotation. And what this does is it flags objects which don't carry at least one annotation which match the provided patterns. And it takes in two parameters. It takes in the key and it takes in the value of the required annotation. And you can use this to create your custom checks. So let's give it a name. In this case, it's going to be required annotation team. And we need to pass it a template key. So in this case, we know the key is required annotation and you need to pass in a bunch of parameters. So in this case, the only thing I care about is the key of the annotation. And so the parameter is called key as you can see here. And I'm going to set it to team. And I'm going to add a remediation to my check. So say add the team annotation. And now when I run kubelinter, I want to pass it this config file. So here you go. Let me open the YAML files as well. And I run it and well, sad, no applause anymore. And in this case, we see that the main service dot YAML is failing our new check because it's missing this required annotation. And to remediate, we can add a team annotation. So let's do that. I go here and I say annotations team. And I know this is owned by the same team. So I just say main. And now I run kubelinter again and we did it. So here we saw an example of how we configure a custom check with kubelinter. kubelinter also comes in with a bunch of built-in checks. So you don't always need to write your custom checks. Not all the built-in checks are enabled by default, but you can find the full list in our documentation and you can add whichever ones you want to your config and we're adding to these all the time. The next thing I wanted to demonstrate to you is how kubelinter works with Helm charts. Here, if I look at the repository of all Helm charts that are in the GitHub slash Helm slash charts repo, I can take a random one. So let's say I want to run kubelinter on telegraph. So just to see, prove that it's a Helm chart, you can see that it has a chart.yaml, values.yaml and templates. And now when I run kubelinter, lint and point it to telegraph, you can see that it renders the Helm files on its own and finds violations just like it did on the raw Kubernetes YAML files. The next thing I wanted to demonstrate is how kubelinter can be integrated into a CI system. So here I have a pull request in a repository that I own where I've checked in the same YAML files that you were just looking at and I have a GitHub action that runs kubelinter against this repo and you can see that it's failing and you're able to see the exact same output that you were able to see when you run it locally and because in this case it had violations, in this case it found 13 lint errors, it is exited with exit code one and it's failed the build and so you know on your PR that you need to do something to your YAMLs before you can merge them. So I hope that gave you an overview of how kubelinter works. So if you're interested in trying it out, like I said, it's free and open source and you can find it on our GitHub. Please do try it out, let us know what you think and if it works well for you, do consider giving it a star on GitHub. We look forward to hearing from you and if you have more questions or want to chat with us, visit and you're at KubeCon, visit the StackRocks booth in the Platinum Hall to learn more about kubelinter and about StackRocks. Thank you so much for listening and have a wonderful day.