(upbeat music) >> From around the globe, it's theCUBE with digital coverage of Postgres vision 2021 brought to you by EDB. >> Hello everybody. Welcome back to Postgres Vision 21. My name is Dave Vellante and we're super excited to have Josh Berkus on. He's joining us, he's a leader in the Kubernetes community, extremely well-versed in containerized applications, application development, containerizing databases all things Open-source, CUBE alum, Josh Berkus welcome back to theCUBE. Great to see you again. >> Thank you. I'm glad to be here. >> Just recently, you're coming off KuberCon, we heard some of the themes from that event. There was a lot of focus on inclusion and diversity, which of course, you know, that's the Open-source ethos and a lot of discussion around designing security in, the whole conversation about shift left. That's great to see larger companies giving back, to obviously a lot of the pressure over the years on the big companies that there's a one-way street, they're actually giving back, making some investments. So we love to see that. And just Open-source continues to be the main spring of innovation. I got to say, I got to call-out and a recent Red Hat survey the state of the enterprise Open-source in 2021, 90% of technology leaders said that they're adopting Open-source and made a joke that the other 10% they're doing it they just don't know it. But so what were some of your takeaways from the event and some of the trends you're seeing but specifically as it relates to containers. >> So, I mean, you're right, one thing is this sort of return to security, the security topic again because we've had like a couple of things happen. One was, when we initially got, started doing containers or platform with Docker and with early Kubernetes and that sort of thing we got a lot of container image scan, right? So you have like Clare and Docker has a scanning thing and Amazon and Azure have their own scanning things. And people felt that was kind of good enough for a while but then we both had the solar winds hack. And the thing is like, in the meantime, we've gone from a stage where people were mostly using Kubernetes in dev to people using Kubernetes in production. And there's a lot of extra security issues and vulnerabilities that come up in an actual production environment that people just didn't necessarily think about before. And so now we're looking at adding more pieces to the security stack and making those more standard for everyone who uses Kubernetes. And I've had the chance to work with the StackRox folks since they became part of Red Hat. So it's been very exciting to look at the whole thing and look at things like container supply chain because the solar winds showed us obviously, it's not enough to necessarily just trust the vendor. You need to trust their whole supply chain. And it helps to be able to examine that supply chain. >> Yeah, it's very scary when you look at that you're absolutely right. Multiple components of malware coming into an organization through the supply chain cell forming, different signatures. And so it's great to see the community spending time on that and an emphasis on that. Now I got to cut right to the chase here, in 2018, you wrote a two-part blog series it's called Should I run Postgres in Kubernetes? Obviously it's highly relevant for this community. So I want to talk about your perspective, well, first of all, the thing I love about you is you're tactical and you can go deep, but at the same time, you can speak to a business audience. >> Thanks. >> You're welcome and thank you for writing this and communicating the way you do, but talk about when it makes sense and when it doesn't, I mean, that's kind of... My big three takeaways on the pros were simplify, simplify, simplify, especially if you're running application components and other services on Kubernetes but give us the update three years later, why should you, why shouldn't? >> You know let's actually, why don't we zoom out to an even bigger picture? Which is just honestly like every new platform that we've got, right? So when virtualization and VMware became a thing we had the same sort of decisions about when do I move my database to this, when AWS and the public cloud became a thing. I could have like, like if I had written that 12 years ago I could have written it about AWS and it would have had a lot of the same decision tree 'cause what it really sort of comes down to is the more commodifiable a particular database instance is the better candidate it is to move to an advanced infrastructure platform, and the most advanced, currently being Kubernetes. To the extent that you can describe this particular database, what it does, who needs to use it, what's in it in and a simple one pager then that's probably a really good candidate for hosting on Kubernetes. Whereas if you have a database where it's like, Hey, the entire company uses it and it's so complicated we can't describe it's inputs and outputs. That's possibly the last thing in your company that you're going to migrate to Kubernetes, because both in terms of there's less gain to be made there, because the real advantage of moving stuff to Kubernetes is your ability to automate things. The whole way I got into Kubernetes in the first place was I started out way down the line not using containers at all. I was just looking to solve the problem of how do we automate Postgres high availability. That's what I was looking for. And it started out with something I built using SaltStack called handy rep, that Casey and I built. And mostly that was a problem discovery exercise, we discovered what the hard problems were there. And then we moved from that, and then we moved from that to Docker because containers offered an encapsulation strategy because one of the problems you run into when automating high availability is the database actually down or not. And so the first thing that containers offered us was not packaging, what people usually talk about but instead of encapsulation, right, because it's a lot easier to determine is the container running or not, than is the database down or not? Because an actual Postgres database has multiple components and multiple processes that make it up. And some of those can be down without the others being down which can then make you think a database is down that's not actually shut down. And being able to put that in a container, it gives me more of a binary up or down. And then from there, I got into, okay, well but I need to automate a lot of other components. I need to automate the storage and everything else. And that led to Kubernetes. And so if you look at it in terms of deciding when you're going to migrate the database to Kubernetes you look at, can I take advantage of that automation? Is this something that my application workflow and my team organization allows me to do? And if the answer is yes, particularly, if you're in a company that's doing the full dev ops thing where you have a unified development and infra team that owns the entire stack then those people are going to be a really good candidate for moving that stack to Kubernetes. >> Got it. Okay, so let me ask you, in database especially in critical apps, your recovery's everything, when something goes wrong, you got to recover. So if I understand it correctly, just in reading and listening to you, if you've got Kubernetes expertise and you're building applications in that environment then the application components are in there. And am I inferring correctly that you're going to be able to automate and facilitate high quality recovery with certainty? >> Yeah, there's a bunch of infrastructure involved, and this is why, what enterprises do is they move things like the web front-end to Kubernetes first and is what they should do, right? That is absolutely the right order of things to do because the minute that you're looking at bringing databases in, you're now looking at your whole storage infrastructure. So that direct attack storage that was attached physically to one machine is not going to work once you've moved to a container-based cloud. You suddenly need a way to be able to attach that storage to any of the nodes in your cluster so that you can move the database around and you can have fail-over. But once you build those things up, you can't. I mean, some of the stuff that I've done, I work in the office of the CTO now at Red Hat. So I'm not in production support. So the only Postgres instance I'm supporting are ones for some Open-source projects we support like the Python project. And in those cases, it's not a high criticality database, but I'm not support, I'm not on call on the weekend. I want something where it doesn't require need to be on call in order for it to stay up. And so putting that on open shift with the Patroni fail-over driver was the answer for that. And it has failed over in the Red Hat IT team contacts me and says, "Hey, we need to move those servers. And then we'll just add a node to the cluster and delete the old node and it'll do the right thing." And I don't have to worry about it, which is really what you're going for there. >> The other thing I took away from your writing was that you suggested that a lot of the successes in areas where the Postgres databases were rather small and there were a lots of them. And so to the extent that you can automate that you're going to save yourself a lot of problems. Whereas in the flip side if you're running extremely large databases or there may be performance constraint that might be an area to be a little bit more circumspect. >> Yeah and that's absolutely true because like the other side of this, like I've worked with the dev ops people and the people who are on Heroku and that sort of thing that have one database per application, right. And those people are great candidates for migrating. But then I've also worked with the people who have a one big database for the company, where the database is three terabytes in size, it powers their reporting system and their customer's system and the web portal and everything else in one database. That's the one that's really going to be a hard call and that you might in fact, never physically migrate to Kubernetes because even if it's on Kubernetes you are going to mess with the hardware policy to give it its own dedicated machine. So in that case, what I would honestly tend to do is there's a feature in Kubernetes called service catalog that allows you to expose an external service within Kubernetes as if it were a Kubernetes service. And that's what I tend to do with those kinds of databases because it's, there's not a huge advantage in actually physically moving the database to a container. There's a bunch of steps involved and going via service catalog is a lot easier. >> But essentially you're you're speaking the same language in that example that you just gave. >> Yeah. >> Now, the other thing you pointed out at the time that you wrote this article is there's a lot of pre 1.0 kind of alpha in the Kubernetes stack and it might be prudent to if, not putting your HIPAA compliant, since it evolved. >> Yeah, if I was to update two things in the article I guess that would be one of them the other one I'll get to in a minute. So the first one is that, Kubernetes has progressed along that maturity timeline. Like we recently added the production readiness reviews as part of our feature review process. We've really improved tested adherence, so that we're not releasing with known broken tests, and a bunch of other things to make it more stable. But part of it depends on who I'm talking to because there's still degrees here. So if I'm talking to the context of the world of software then Kubernetes has reached the point of maturity that it is as stable as anything else. And if you use a release, you can assume that any sort of major issues have been worked out. The one difference with it and some other platforms people may have used is it's still young enough that backwards compatibility can be an issue. As in Kubernetes releases now three times a year, we've stepped down from four and within three releases you can find yourself needing to change API calls which means needing to refactor parts of your application. So if you compare that with some other things, like a JVM platform, when's the last time you had a major API change with a JVM platform. But you know the Kubernetes is only six years old, so that's part of that. The other thing is the question is I'm talking to the Postgres community, right? Which is within Postgres, people run the daily Postgres snapshot in production. I would not do that with Kubernetes, I would wait for release. So there's still kind of a difference there if people are coming from the Postgres community, right. Is we're used to this really extreme level of stability that we have with Postgres and Kubernetes as a much younger project isn't quite there yet. >> So that's a process, a change that you would have to be aware of if you want to take the benefits of containers with Postgres, you just have to really understand that and make that process part of your change management. >> The other thing I would say has changed is there are new opportunities in running your data warehouse, your big data databases on Kubernetes. A number of platforms, the one I'm most familiar with is Citus, because I worked with those folks that have taken advantage of Kubernetes as a deployment and management platform for their database, their big data database infrastructure, which makes sense because if you look at a lot of modern data analysis and data mining platforms that are built on top of Postgres part of how they do their work is they actually run a bunch of little Postgres instances that they federate together. And then Kubernetes becomes the tool that allows you to manage all of those little Postgres instances. So that's the sort of exception to the, should I migrate this really big database? That can be a yes, if you are migrating it to a big data platform that supports Kubernetes, then it can be a huge advantage. >> Obviously you've got the practitioner knowledge and you were working in the community. I'm wondering if you can share just thinking about sort of the motivation to move to a container environment if you're one of the Postgres folks in the audience could you share any, either anecdotal or other data on business impact, benchmarks that you've seen, some of the things that you've seen some positives there? >> If you actually look at my history when you talk about performance is one, right? And if you actually look at my history, I actually did, and for that matter of some of the folks from Percona and some of our other folks in the database field did a bunch of benchmarks of running Postgres in MySQL, on Kubernetes versus running it not on Kubernetes. And one of the advantages of containers over VMS is that there isn't any intrinsic, there's not any intrinsic sort of layer gap or virtualization that modifies your performance. In other words, if a container is using storage that's present on the node where the container is running it is using that storage through Linux. And therefore the performance is, with some caveats, performance is going to be identical to if you were running that on the host system. Now, where performance differences creep in is that you might not be able to use the same kind of storage. In that Kubernetes and containers systems in general are organized around the idea that no service is using a majority of the resources on the system, so again, if you're planning on user running a larger Postgres database that really needs all the RAM that a system has you're going to have to do a lot of tinkering with Kubernetes configuration to get the same performance, you would have a running it on a dedicated hardware now. >> Okay, but fundamentally you're saying that overhead is less with caveats, like you said, you just mentioned in the story, right? >> Yeah, well, the overhead is not any different from if you were running under the host system. So a really good example of that was, if you go back to on my lightning talking in, (indistinct) Austin, I think. I showed running a benchmark with Postgres on an AWS instance using EBS storage, both not in Kubernetes and in Kubernetes. And there was no perceptible performance difference between the two of them because it was all metered by how fast was EBS for me. >> Right, and I said less, but I should've been more specific less than say you would expect with virtualization. >> Right, and then it just comes down to a business decision, which is that if you're already on some sort of cloud storage or network storage, and again you have databases that can share hardware systems then you shouldn't really expect substantial performance differences by moving to Kubernetes. That's something that you can eliminate inside of words, but if you're going in the process going to be migrating from direct attached storage to network storage then you are going to see a performance difference but that's caused by the change in storage. Or if you're going to be moving from systems that are not shared to systems that aren't shared again you're going to see a difference from them, but it wouldn't be any different than if you did that without Kubernetes containers being involved. >> If you're using any world-class shared storage device from whatever name of big vendor, you're going to accommodate if you're racking and stacking your own flash drives or worse yet spinning disk drives that's in direct attached, that's maybe a different story, so, okay. That's good. Where would you advise people to get started with Postgres and Kubernetes? >> The nice thing is there are a number of advanced systems now, and advanced systems that are supported by the various Postgres vendors. And that can actually be a great place to get started because the systems are Open-source so you can try them out. This is, as far as I know, they're Open-source you can try them out but then if you decide you like them, you can get support. And so that would include Crunchy data. Enterprise DB has a system, and honestly, I have to admit less familiar with than the ones that Crunchy runs. StackRox is another one out of Europe that has their own system for running cloud native Postgres. And there's one I'm forgetting, and what a lot of these have to do with is taking advantage of the automation. 'Cause you can obviously can put Postgres and container play around, right? But your whole point of moving to Kubernetes in general is going to be take advantage of the automation, so you want to look at the various automation platforms and you can go ahead and do that and the one I'm most familiar with because I develop it as Patroni, is the component for automating Postgres. You do Patroni plus you do operators, it's another word that comes in here. But if you're looking at this as a business you're probably going to want something that supported or that at least there's a potential to buy support and a bunch of the different companies in the Postgres space package up these components for you into a platform. Like I know the Crunchy platform uses Patroni plus some proxy stuff, plus PG back rest plus a couple of other things to give you a sort of full automation platform for running Postgres on Kubernetes. >> Awesome, last question. Where are we in the whole container adoption, we started out kind of you've mentioned this stateless and now you're building stateful applications but still you look at the, we look at spending data with our data partners ETR and containers and container orchestration. It's it's right up there with RPA, with cloud, with AI just in terms of the attention and resource that's going in. So it's exploding. It feels like it's still early days. There's a lot of legs left, what do you see? >> Yeah, well, a lot of it is, I mean you're talking about migrating IT infrastructure, right? So where we are with Kubernetes is we have the early adopters, right? We have all the people who were at the point of building their new infrastructure when Kubernetes came out, right. And people who had major unsolved problems which is a big reason for adopting a new platform was just was no old platform for you. and so we sort of have those people and those people are already on Kubernetes and running their stuff there. And so now we're looking at the really long path of people who are not in one of those camps moving, right. And in a lot of cases, that's a matter of coinciding with other reasons why they have to look at an upgrade because even if, whether it's the gradual replacement of old applications by new ones, where you gradually all the legacy applications get offline and the new applications run in Kubernetes or sometimes it's a, "Hey we're waiting for replacement cycle." We're waiting for, we already had plans to move from on-prem to public cloud, and so we're going to move from on-prem to public cloud on Kubernetes, to make it part of the migration. And that'll be years. I still like, I have fingers into other areas, like I still know a lot of people in the nonprofit space and a lot of nonprofits just got around to adopting virtualization, right? Like they're not even at public cloud yet. I don't even talk to them about Kubernetes. There's this huge long tail in terms of adoption. The nice thing is we don't show any signs of stopping, is that one of the things that we kind of learned from earlier stuff particularly learned from our friends at OpenStack was to really really focus on the APIs, to look at who Kubernetes more as the hub of a system of an infrastructure idea with potentially unbounded growth. If you have a new concept that comes in like service mesh, service mesh is not a successor to Kubernetes. It's not an alternative to Kubernetes. It is a thing you layer on top of Kubernetes because we didn't make it exclusive. >> Right. Great, great example going back to OpenStack and thank you for bringing that in because there's lessons learned. And so Josh, we've got to leave it there. Thanks so much for coming back in theCUBE, great conversation, you're awesome. >> Okay, good to talk to you. >> All right, and thank you for watching everybody, keep it right there for more content from Postgres Vision 21. My name is Dave Vellante, you're watching theCUBE. (upbeat music)

>> Ed Boyajian, the CEO of Enterprise DB. Ed, what are some of the more exciting things that people can expect from Postgres Vision 2021. Who should attend and why? >> Yeah, so really key things that we're going to be covering. Because of our focus on the enterprise, we're going to to talk a lot about how Postgres is used and deployed at scale in the enterprise. As we've seen, developers are playing such a prominent role now in the decision-making for technologies, especially database. So we're going to talk a lot about application development with Postgres. We're going to spend time. Of course, it's a technology conference. There's a lot coming on the horizon with Postgres and work that EDB is doing. So we're going to talk about emerging technologies and what's ahead. And then, you know, a lot of outsiders don't understand the nature and power of the Postgres community. And so we're going to put some cycles into sharing a little more depth and insight about what happens in the community and why that is powerful and what makes it great. >> Postgres Vision '21 is June 22nd and 23rd. Go to Enterprise DB.com and register. The Cube's going to be there. We hope you will be too. Ed, thanks for coming on the Cube and previewing the event. >> Thanks, Dave. >> And thank you, we'll see you at Vision '21.

(upbeat music) >> From around the globe, it's the CUBE with digital coverage of Postgres Vision 2021. Brought to you by EDB. >> Hello everyone, this is Dave Vellante for the CUBE. We're covering Postgres Vision 2021, the Virtual CUBE edition. Welcome to our conversation with the CEO, Ed Boyajian, the CEO of Enterprise DB. And we're going to talk about what's happening in open source and database and the future of tech. Ed, Welcome. >> Hi Dave, good to be here. >> Hey, several years ago at Postgres Vision event you put forth the premise that the industry was approaching a threshold moment, and digital transformation was the linchpin of that shift. Now, Ed, while you were correct, and I have no doubt the audience agreed, most people went back to their offices after that event and they returned to their hyper-focus of their day-to-day jobs. Yeah, maybe a few accelerated their digital initiatives but generally, pre COVID, we moved at a pretty incremental pace and then the big bang hit. And if you weren't digital business, you were out of business. So, that single event created the most rapid change that we've ever seen in the tech industry by far, nothing really compares. So, the question is, why is Postgres specifically and EDB generally the right fit for this new world? >> Yeah, I think, look a couple of things are happening Dave. You know, right along the bigger picture of digital transformation, we are seeing the database market in transformation. And, and I think the things that are driving that shift are the things that are resulting the success of Postgres and the success of EDB. I think first and foremost, we're seeing a dramatic re-platforming. And just like we saw in the world of Linux where I was at, Red Hat during that shift where people were moving from Unix-based systems to X86 systems, we're seeing that similar re-platforming happening whether that's from traditional infrastructures to cloud-based infrastructures or container-based infrastructures, it's a great opportunity for databases to be changed out. Postgres wins in that context because it's so easily deployed anywhere. I think the second thing that's changing is we're seeing a broad expansion of developers across the enterprise. They don't just live in IT anymore. And I think as developers take on more power and control, they're just defining the agenda. And it's another place where Postgres shines. It's been a priority of EDB's to make Postgres easier and that's coming to life. And I think the last stack overflow developer survey suggested that, I think they survey 65,000 developers, the second most loved and the second most used database by developers is Postgres. And so I think there again, Postgres shines in a moment of change. And then I think the third is kind of obvious. It's always an elephant in the room, no pun intended, but it's this relentless nagging burden of the expenses of the incumbent proprietary databases and the need. And we especially saw this in COVID. To start to change that, more dramatically change that economic equation, here again, Postgres shines. >> You know, I want to ask you, I'm going to jump ahead to the future for a second, because you're talking about the re-platforming and with your Red Hat shops I kind of want to pick your brain on this because you're right. You saw that with Red Hat and you're kind of seeing it again when you think about open shift and where it's going, my question is related to re-platforming around new types of workloads, new processing models at the edge, I mean, you've seen an explosion of processing power GPU's, NPUs, accelerators, DSPs and it appears that there this is happening at a very low cost. I'm inferring that you're saying Postgres can take advantage of that trend as well, that that broader re-platforming trend to the edge, is that correct? >> It is. And, and I think, you know this is the this has been one of the I think the most interesting things with Postgres. Now I've been here almost 13 years. So if you put that in some perspective, I've watched and participated in leading transformation in the category. You know, we've been squarely focused on Postgres so we've got 300 engineers who worry about making Postgres better. And as you look across that landscape a time, not only as Postgres gotten more performance and more scalable, it's also proven to be the right database choice in the world of not just legacy migrations but new application development. And I think that stack overflow developer survey is a good indicator of how developers feel about Postgres, but, you know over that timeframe, I think if you went back to 2008 when I joined EDB, Postgres was was considered a really good general purpose database. And today I think Postgres is a great general purpose database. General purpose isn't sexy in the market, broadly speaking but Postgres capabilities across workloads in every area is really robust. And let me just spend a second on it. We look at our customer base as deploying and what we think of as systems of record, which are the traditional ERP type apps, you know where there's a single source of truth. You might think of ERP apps there. We look at our customers deploying and systems of engagement, and those are apps that you might think of in the context of social media style apps or websites that are backed by a database. And the third area is systems of analytics where you would typically think of data warehouse style applications, interestingly, Postgres performs well. And our customers report using us across that whole landscape of application areas. And I think that is one of Postgres' hidden superpowers, is that ability to reach into each area of requirement on the workload side. >> Yeah. And as I was alluding to before. That, that itself is evolving as you now inject AI into the equation AI inferencing. And it's just a very exciting times ahead. There's no, there's no database, you know 20 years ago it was kind of boring. Now it's just exploding. I want to come back to that, the notion of of Postgres that maybe talk about other database models. I mean, you've mentioned that you've evolved from this, you know, system of record. You can take a system engagement on structured data, et cetera, Jason it's-. So how should we think about Postgres in relation to other databases and specifically other business models of companies that provide database services? Why is Postgres attractive? Where is it winning? >> Yeah, I think a couple of places. So, I mean, for first and foremost, Postgres, you know at its core, Postgres is a SQL relational database a trend in asset compliance, equal relational database. And that is inherently a strength of Postgres but it's also a multi-model database. Which means we handle a lot of other, you know database requirements, whether that's geospatial or, or JSON for documents or, or time series, things like that. And, so Postgres extensibility is one of its inherent strengths. And that's kind of been built in from the beginning of Postgres. So not surprisingly people use Postgres across a number of workloads because at the end of the day, there's still value in having a database that's able to do more. There are a lot of important specialty databases and I think they will remain important specialty databases, but Postgres thrives in its ability to crossover in that way. And I think that is, you know one of the different key differentiators in in how we've seen the market and the business develop. And, and that's the breadth of of workloads that Postgres succeeds in. But, but our growth if you kind of ventured it across vectors we see growth happening, you know, in a few dimensions. First, we see growth happening in new applications. About half of our customers have come to us today for new, new Postgres users are deploying us on new applications. The others are our second area migrating away from some existing legacy incumbent. Often Oracle, not always. The third area of growth we see is in cloud where we're Postgres is deployed very prolifically both in the traditional cloud platforms like EC2, but then again also in the database as a service environment and then the fourth area growth we're seeing now is around container deployment, Kubernetes deployment. >> Well, you mean Oracle's prominent because it's just, it's, it's, it's a big install base and it's expensive and people, you know they got to look at that. I mean, It's funny. I do a lot of TCO work and mostly, you know usually TCO is about labor costs when it comes to Oracle it's about license costs and maintenance costs. And so to the extent that you can reduce that at least for a portion of your state, you're going to, you're going to drop right to the bottom line. But, but, I want to ask you about the kind of that spectrum that you think about the prevailing models for database you've got on the one hand, you've got the right tool for the right job approach. You know, it might be 10 or 12 data stores in the cloud. On the other hand, you've got kind of a converged approach. You know, Oracle is going that direction, clearly Postgres, with its open source innovation, is going that direction. And it seems to me yet that at scale that's a more, the latter is the more cost-effective model. How do you think about that? >> Well, you know, I think at the end of the day you kind of have to look at it. I mean, the, the business side of my brain looks at that as an addressable market question, right? And you heard me talk about three broad categories of workloads and, you know, people define workloads in different buckets, but that's how we do it. But if you look at just a system of record in the system of engagement market I think that's what would be traditionally viewed as the database market. And there that's, you know, let's just say for the sake of arguments, a 45 to $50 billion market. The third, the systems of analysis that market's an $18 billion market. And, and, you know, as we talk about that so all in it's still between 60 and $70 billion market. And I think what happens, there's so much heat and light poured on the valuation multiples of some of the specialty players that the market gets confused. But the reality is our customers don't get confused. I mean, if you look at those specialty players take that $48 billion market. I mean, add up Mongo, Reds, Cockroach, Neo, all of those. I mean, hugely valued companies all unicorn companies, but combined they add up to a billion bucks. Don't get me wrong, that's important revenue and meaningful in the workloads they support, but it's not, it doesn't define the full transformation of this category. Look at the systems of analysis again, another great, great market example. I mean, if you add up the consolidation of the Hadoop vendors, add in there, snowflake you're still talking to, you know $1.5 billion in revenue in an $18 billion market. So while those are all important technologies the question is in this transformation move did the database market fully transformed yet. And my view is, no, it didn't, we're in the first maybe second inning of a $65 billion transformation. And I think this is where Postgres will ultimately shine. I think this is how Postgres wins, because at the end of the day, the, the nature of the workloads fits with Postgres and the future tech that we're building in Postgres will serve that broader set of needs. I think more effectively. >> Well, and I love these tam expansion discussions because I think you're right on. And I think it comes back to the data and we all we all talk about the data growth, the data exposure and we see the IDC numbers. Well, you ain't seen nothing yet. And so at data by its very nature is distributed. That's why I get so excited about these new platform models. And I want to tie it back to developers and open source because to me, that is the linchpin of innovation in the next decade. It has been, I would even say for the last decade we've seen it, but it's gaining momentum. So, so in thinking about innovation and specifically Postgres in open source, you know, what can you share with us in terms of how we should think about your advantage and again where people are glomming, leaning in to that advantage? >> Yeah. So, I mean, I think, I think you bring up a really important topic for us as a company, Postgres, we think is an incredibly powerful community and, and when you step away from it, again, I, now you remember, I told you, I'd been at, I was at Red Hat before now here at EDB. And there's a common thread that runs through those two experiences. In, in both experiences the companies are attached and prominent alongside a strong, independent open-source community. And I think the notion of an independent community is really important to understand around Postgres. There are hundreds and thousands of people contributing to Postgres. Now EDB plays a big role in that about, you know approaching a third of the contributions in the last release, released 13 of Postgres came from EDB. Now you might look at that and say, gee, that sounds like a lot, but if you step away from it, you know at about 30% of those contributions, most of the contributions come from a universe around EDB and that's inherently healthy for the community's ability to innovate and accelerate. And I think that while we play a strong role there you can imagine that having, and there are other great companies that are contributing to Postgres. I think having those companies participating and contributing gets the best the best ideas to the front in innovation. So I think the inherent nature Postgres community makes it strong and healthy. I mean, and then contrast that to some of the other prominent high value open-source companies. Companies and the communities are intimately intertwined. They're one in the same. They're actually not independent open source communities. And I think that they're therein lies one of, one of the inherent weaknesses in those. But, Postgres thrives because, you know we bring all those ideas from EDB. We bring a commercial contingent with us and all the things we hope, we emphasize and focus on, in growth and Postgres. Whether that's in the areas of scalability, manageability, all hot topics, of course security, all of those areas. And then, you know, performance as always. All of those areas are informed to us by enterprise customers deploying Postgres at scale. And I think that's the heart of what makes a successful independent project. >> Common editorial powers of, of that ecosystem. They, they they're they're multiplicative as opposed to the, the resources of one. I want to talk about Postgres Vision 2021 sort of set up that a little bit. The theme this year is 'The Future is You'. What do you mean by that? >> So, if you think about what we just said, posts, the category is in Tran-, the database categories in transformation. And we know that many of our people are interested in Postgres are early in their journey. They're early in their experience. And so we want to focus this year's Postgres Vision on them. That we understand, as a company who's been committed to Postgres, as long as we have. And with the understanding we have of the technology and best practices, we want to share that view, those insights with, with those who are coming to Postgres. Some for the first time, some who are experienced. >> Postgres Vision 21 is June 22nd and 23rd go to enterprisedb.com and register. The CUBE's going to be there. We hope you will be too. Ed, thanks for coming to the CUBE and previewing the event. >> Thanks, Dave. >> And thank you. We'll see you at Vision 21. (upbeat music)