>>Hi everyone. And welcome to data citizens. Thank you for making the time to join me and the over 5,000 data citizens like you that are looking to become United by data. My name is Jim Cushman. I serve as the chief product officer at Collibra. I have the benefit of sharing with you, the product, vision, and strategy of Culebra. There's several sections to this presentation, and I can't wait to share them with you. The first is a story of how we're taking a business user and making it possible for him or her data, use data and gain. And if it and insight from that data, without relying on anyone in the organization to write code or do the work for them next I'll share with you how Collibra will make it possible to manage metadata at scales, into the billions of assets. And again, load this into our software without writing any code third, I will demonstrate to you the integration we have already achieved with our newest product release it's data quality that's powered by machine learning. >>Right? Finally, you're going to hear about how Colibra has become the most universally available solution in the market. Now, we all know that data is a critical asset that can make or break an organization. Yet organizations struggle to capture the power of their data and many remain afraid of how their data could be misused and or abused. We also observe that the understanding of and access to data remains in the hands of just a small few, three out of every four companies continue to struggle to use data, to drive meaningful insights, all forward looking companies, looking for an advantage, a differentiator that will set them apart from their peers and competitors. What if you could improve your organization's productivity by just 5%, even a modest 5% productivity improvement compounded over a five-year period will make your organization 28% more productive. This will leave you with an overwhelming advantage over your competition and uniting your data. >>Litter employees with data is the key to your success. And dare I say, sorry to unlock this potential for increased productivity, huge competitive advantage organizations need to enable self-service access to data for everyday to literate knowledge worker. Our ultimate goal at Cleaver has always been to enable this self-service for our customers to empower every knowledge worker to access the data they need when they need it. But with the peace of mind that your data is governed insecure. Just to imagine if you had a single integrated solution that could deliver a seamless governed, no code user experience of delivering the right data to the right person at the right time, just as simply as ordering a pair of shoes online would be quite a magic trick and one that would place you and your organization on the fast track for success. Let me introduce you to our character here. >>Cliff cliff is that business analyst. He doesn't write code. He doesn't know Julian or R or sequel, but is data literate. When cliff has presented with data of high quality and can actually help find that data of high-quality cliff knows what to do with it. Well, we're going to expose cliff to our software and see how he can find the best data to solve his problem of the day, which is customer churn. Cliff is going to go out and find this information is going to bring it back to him. And he's going to analyze it in his favorite BI reporting tool. Tableau, of course, that could be Looker, could be power BI or any other of your favorites, but let's go ahead and get started and see how cliff can do this without any help from anyone in the organization. So cliff is going to log into Cleaver and being a business user. >>The first thing he's going to do is look for a business term. He looks for customer churn rate. Now, when he brings back a churn rate, it shows him the definition of churn rate and various other things that have been attributed to it such as data domains like product and customer in order. Now, cliff says, okay, customer is really important. So let me click on that and see what makes up customer definition. Cliff will scroll through a customer and find out the various data concepts attributes that make up the definition of customer and cliff knows that customer identifier is a really important aspect to this. It helps link all the data together. And so cliff is going to want to make sure that whatever source he brings actually has customer identifier in it. And that it's of high quality cliff is also interested in things such as email address and credit activity and credit card. >>But he's now going to say, okay, what data sets actually have customer as a data domain in, and by the way, why I'm doing it, what else has product and order information? That's again, relevant to the concept of customer churn. Now, as he goes on, he can actually filter down because there's a lot of different results that could potentially come back. And again, customer identifier was very important to cliff. So cliff, further filters on customer identifier any further does it on customer churn rate as well. This results in two different datasets that are available to cliff for selection, which one to use? Well, he's first presented with some data quality information you can see for customer analytics. It has a data quality score of 76. You can see for sales data enrichment dataset. It has a data quality score of 68. Something that he can see right at the front of the box of things that he's looking for, but let's dig in deeper because the contents really matter. >>So we see again the score of 76, but we actually have the chance to find out that this is something that's actually certified. And this is something that has a check mark. And so he knows someone he trusts is actually certified. This is a dataset. You'll see that there's 91 columns that make up this data set. And rather than sifting through all of that information, cliff is going to go ahead and say, well, okay, customer identifier is very important to me. Let me search through and see if I can find what it's data quality scores very quickly. He finds that using a fuzzy search and brings back and sees, wow, that's a really high data quality score of 98. Well, what's the alternative? Well, the data set is only has 68, but how about, uh, the customer identifier and quickly, he discovers that the data quality for that is only 70. >>So all things being equal, customer analytics is the better data set for what cliff needs to achieve. But now he wants to look and say, other people have used this, what have they had to say about it? And you can see there are various reviews for different reviews from peers of his, in the organization that have given it five stars. So this is encourages cliffs, a confidence that this is great data set to use. Now cliff wants to look a little bit more detailed before he finally commits to using this dataset. Cliff has the opportunity to look at it in the broader set. What are the things can I learn about customer analytics, such as what else is it related to? Who else uses it? Where did it come from? Where does it go and what actually happens to it? And so within our graph of information, we're able to show you a diagram. >>You can see the customer analytics actually comes from the CRM cloud system. And from there you can inherit some wonderful information. We know exactly what CRM cloud is about as an overall system. It's related to other logical models. And here you're actually seeing that it's related to a policy policy about PII or personally identifiable information. This gets cliff almost the immediate knowledge that there's going to be some customer information in this PII information that he's not going to be able to see given his user role in the organization. But cliff says, Hey, that's okay. I actually don't need to see somebody's name and social security number to do my work. I can actually work with other information in the data file. That'll actually help me understand why our customers churning in, what can I actually do about it. If we dig in deeper, we can see what is personally identifiable information that actually could cause issues. >>And as we scroll down and take a little bit of a focus on what we call or what you'll see here is customer phone, because we'll show that to you a little bit later, but these show the various information that once cliff actually has it fulfilled and delivered to him, he will see that it's actually massed and or redacted from his use. Now cliff might drive in deeper and see more information. And he says, you know what? Another piece that's important to me in my analysis is something called is churned. This is basically suggesting that has a customer actually churned. It's an important flag, of course, because that's the analysis that he's performing cliff sees that the score is a mere 65. That's not exactly a great data quality score, but cliff has, is kind of in a hurry. His bosses is, has come back and said, we need to have this information so we can take action. >>So he's not going to wait around to see if they can go through some long day to quality project before he pursues, but he is going to come up and use it. The speed of thinking. He's going to create a suggestion, an issue. He's going to submit this as a work queue item that actually informs others that are responsible for the quality of data. That there's an opportunity for improvement to this dataset that is highly reviewed, but it may be, it has room for improvement as cliff is actually typing in his explanation that he'll pass along. We can also see that the data quality is made up of multiple components, such as integrity, duplication, accuracy, consistency, and conformity. Um, we see that we can submit this, uh, issue and pass it through. And this will go to somebody else who can actually work on this. >>And we'll show that to you a little bit later, but back to cliff, cliff says, okay, I'd like to, I'd like to work with this dataset. So he adds it to his data basket. And just like if he's shopping online, cliff wants that kind of ability to just say, I want to just click once and be done with it. Now it is data and there's some sensitivity about it. And again, there's an owner of this data who you need to get permission from. So cliff is going to provide information to the owner to say, here's why I need this data. And how long do I need this data for starting on a certain date and ending on a certain date and ultimately, what purpose am I going to have with this data? Now, there are other things that cliff can choose to run. This one is how do you want this day to deliver to you? >>Now, you'll see down below, there are three options. One is borrow the other's lease and others by what does that mean? Well, borrow is this idea of, I don't want to have the data that's currently in this CRM, uh, cloud database moved somewhere. I don't want it to be persistent anywhere else. I just want to borrow it very short term to use in my Tablo report and then poof be gone. Cause I don't want to create any problems in my organization. Now you also see lease. Lease is a situation where you actually do need to take possession of the data, but only for a time box period of time, you don't need it for an indefinite amount of time. And ultimately buy is your ability to take possession of the data and have it in perpetuity. So we're going to go forward with our bar use case and cliff is going to submit this and all the fun starts there. >>So cliff has actually submitted the order and the owner, Joanna is actually going to receive the request for the order. Joanna, uh, opens up her task, UCS there's work to perform. It says, oh, okay, here's this there's work for me to perform. Now, Joanna has the ability to automate this using incorporated workflow that we have in Colibra. But for this situation, she's going to manually review that. Cliff wants to borrow a specific data set for a certain period of time. And he actually wants to be using in a Tablo context. So she reviews. It makes an approval and submits it this in turn, flips it back to cliff who says, okay, what obligations did I just take on in order to work for this data? And he reviews each of these data sharing agreements that you, as an organization would set up and say, what am I, uh, what are my restrictions for using this data site? >>As cliff accepts his notices, he now has triggered the process of what we would call fulfillment or a service broker. And in this situation we're doing a virtualization, uh, access, uh, for the borrow use case. Cliff suggests Tablo is his preferred BI and reporting tool. And you can see the various options that are available from power BI Looker size on ThoughtSpot. There are others that can be added over time. And from there, cliff now will be alerted the minute this data is available to them. So now we're running out and doing a distributed query to get the information and you see it returns back for raw view. Now what's really interesting is you'll see, the customer phone has a bunch of X's in it. If you remember that's PII. So it's actually being massed. So cliff can't actually see the raw data. Now cliff also wants to look at it in a Tablo report and can see the visualization layer, but you also see an incorporation of something we call Collibra on the go. >>Not only do we bring the data to the report, but then we tell you the reader, how to interpret the report. It could be that there's someone else who wants to use the very same report that cliff helped create, but they don't understand exactly all the things that cliff went through. So now they have the ability to get a full interpretation of what was this data that was used, where did it come from? And how do I actually interpret some of the fields that I see on this report? Really a clever combination of bringing the data to you and showing you how to use it. Cliff can also see this as a registered asset within a Colibra. So the next shopper comes through might actually, instead of shopping for the dataset might actually shop for the report itself. And the report is connected with the data set he used. >>So now they have a full bill of materials to run a customer Shern report and schedule it anytime they want. So now we've turned cliff actually into a creator of data assets, and this is where intelligent, it gets more intelligence and that's really what we call data intelligence. So let's go back through that magic trick that we just did with cliff. So cliff went into the software, not knowing if the source of data that he was looking for for customer product sales was even available to him. He went in very quickly and searched and found his dataset, use facts and facets to filter down to exactly what was available. Compare to contrast the options that were there actually made an observation that there actually wasn't enough data quality around a certain thing was important to him, created an idea, or basically a suggestion for somebody to follow up on was able to put that into his shopping basket checkout and have it delivered to his front door. >>I mean, that's a bit of a magic trick, right? So, uh, cliff was successful in finding data that he wanted and having it, deliver it to him. And then in his preferred model, he was able to look at it into Tableau. All right. So let's talk about how we're going to make this vision a reality. So our first section here is about performance and scale, but it's also about codeless database registration. How did we get all that stuff into the data catalog and available for, uh, cliff to find? So allow us to introduce you to what we call the asset life cycle and some of the largest organizations in the world. They might have upwards of a billion data assets. These are columns and tables, reports, API, APIs, algorithms, et cetera. These are very high volume and quite technical and far more information than a business user like cliff might want to be engaged with those very same really large organizations may have upwards of say, 20 to 25 million that are critical data sources and data assets, things that they do need to highly curate and make available. >>But through that as a bit of a distillation, a lifecycle of different things you might want to do along that. And so we're going to share with you how you can actually automatically register these sources, deal with these very large volumes at speed and at scale, and actually make it available with just a level of information you need to govern and protect, but also make it available for opportunistic use cases, such as the one we presented with cliff. So as you recall, when cliff was actually trying to look for his dataset, he identified that the is churned, uh, data at your was of low quality. So he passed this over to Eliza, who's a data steward and she actually receives this work queue in a collaborative fashion. And she has to review, what is the request? If you recall, this was the request to improve the data quality for his churn. >>Now she needs to familiarize herself with what cliff was observing when he was doing his shopping experience. So she digs in and wants to look at the quality that he was observing and sure enough, as she goes down and it looks at his churn, she sees that it was a low 65% and now understands exactly what cliff was referring to. She says, aha, okay. I need to get help. I need to decide whether I have a data quality project to fix the data, or should I see if there's another data set in the organization that has better, uh, data for this. And so she creates a queue that can go over to one of her colleagues who really focuses on data quality. She submits this request and it goes over to, uh, her colleague, John who's really familiar with data quality. So John actually receives the request from Eliza and you'll see a task showing up in his queue. >>He opens up the request and finds out that Eliza's asking if there's another source out there that actually has good is churned, uh, data available. Now he actually knows quite a bit about the quality of information sturdiness. So he goes into the data quality console and does a quick look for a dataset that he's familiar with called customer product sales. He quickly scrolls down and finds out the one that's actually been published. That's the one he was looking for and he opens it up to find out more information. What data sets are, what columns are actually in there. And he goes down to find his churned is in fact, one of the attributes in there. It actually does have active rules that are associated with it to manage the quality. And so he says, well, let's look in more detail and find out what is the quality of this dataset? >>Oh, it's 86. This is a dramatic improvement over what we've seen before. So we can see again, it's trended quite nicely over time each day, it hasn't actually degraded in performance. So we actually responds back to realize and say, this data set, uh, is actually the data set that you want to bring in. It really will improve. And you'll see that he refers to the refined database within the CRM cloud solution. Once he actually submits this, it goes back to Eliza and she's able to continue her work. Now when Eliza actually brings this back open, she's able to very quickly go into the database registration process for her. She very quickly goes into the CRM cloud, selects the community, to which she wants to register this, uh, data set into the schemas community. And the CRM cloud is the system that she wants to load it in. >>And the refined is the database that John told her that she should bring in. After a quick description, she's able to click register. And this triggers that automatic codeless process of going out to the dataset and bringing back its metadata. Now metadata is great, but it's not the end all be all. There's a lot of other values that she really cares about as she's actually registering this dataset and synchronizing the metadata she's also then asked, would you like to bring in quality information? And so she'll go out and say, yes, of course, I want to enable the quality information from CRM refined. I also want to bring back lineage information to associate with this metadata. And I also want to select profiling and classification information. Now when she actually selects it, she can also say, how often do you want to synchronize this? This is a daily, weekly, monthly kind of update. >>That's part of the change data capture process. Again, all automated without the require of actually writing code. So she's actually run this process. Now, after this loads in, she can then open up this new registered, uh, dataset and actually look and see if it actually has achieved the problem that cliff set her out on, which was improved data quality. So looking into the data quality for the is churn capability shows her that she has fantastic quality. It's at a hundred, it's exactly what she was looking for. So she can with confidence actually, uh, suggest that it's done, but she did notice something and something that she wants to tell John, which is there's a couple of data quality checks that seem to be missing from this dataset. So again, in a collaborative fashion, she can pass that information, uh, for validity and completeness to say, you know what, check for NOLs and MPS and send that back. >>So she submits this onto John to work on. And John now has a work queue in his task force, but remember she's been working in this task forklift and because she actually has actually added a much better source for his churn information, she's going to update that test that was sent to her to notify cliff that the work has actually been done and that she actually has a really good data set in there. In fact, if you recall, it was 100% in terms of its data quality. So this will really make life a lot easier for cliff. Once he receives that data and processes, the churn report analysis next time. So let's talk about these audacious performance goals that we have in mind. Now today, we actually have really strong performance and amazing usability. Our customers continue to tell us how great our usability is, but they keep asking for more well, we've decided to present to you. >>Something you can start to bank on. This is the performance you can expect from us on the highly curated assets that are available for the business users, as well as the technical and lineage assets that are more available for the developer uses and for things that are more warehoused based, you'll see in Q1, uh, our Q2 of this year, we're making available 5 million curated assets. Now you might be out there saying, Hey, I'm already using the software and I've got over 20 million already. That's fair. We do. We have customers that are actually well over 20 million in terms of assets they're managing, but we wanted to present this to you with zero conditions, no limitations we wouldn't talk about, well, it depends, et cetera. This is without any conditions. That's what we can offer you without fail. And yes, it can go higher and higher. We're also talking about the speed with which you can ingest the data right now, we're ingesting somewhere around 50,000 to a hundred thousand records per and of course, yes, you've probably seen it go quite a bit faster, but we are assuring you that that's the case, but what's really impressive is right now, we can also, uh, help you manage 250 million technical assets and we can load it at a speed of 25 million for our, and you can see how over the next 18 months about every two quarters, we show you dramatic improvements, more than doubling of these. >>For most of them leading up to the end of 2022, we're actually handling over a billion technical lineage assets and we're loading at a hundred million per hour. That sets the mark for the industry. Earlier this year, we announced a recent acquisition Al DQ. LDQ brought to us machine learning based data quality. We're now able to introduce to you Collibra data quality, the first integrated approach to Al DQ and Culebra. We've got a demo to follow. I'm really excited to share it with you. Let's get started. So Eliza submitted a task for John to work on, remember to add checks for no and for empty. So John picks up this task very quickly and looks and sees what's what's the request. And from there says, ah, yes, we do have a quality check issue when we look at these churns. So he jumps over to the data quality console and says, I need to create a new data quality test. >>So cliff is able to go in, uh, to the solution and, uh, set up quick rules, automated rules. Uh, he could inherit rules from other things, but it starts with first identifying what is the data source that he needs to connect to, to perform this. And so he chooses the CRM refined data set that was most recently, uh, registered by Lysa. You'll see the same score of 86 was the quality score for the dataset. And you'll also see, there are four rules that are associated underneath this. Now there are various checks that, uh, that John can establish on this, but remember, this is a fairly easy request that he receives from Eliza. So he's going to go in and choose the actual field, uh, is churned. Uh, and from there identify quick rules of, uh, an empty check and that quickly sets up the rules for him. >>And also the null check equally fast. This one's established and analyzes all the data in there. And this sets up the baseline of data quality, uh, for this. Now this data, once it's captured then is periodically brought back to the catalog. So it's available to not only Eliza, but also to cliff next time he, uh, where to shop in the environment. As we look through the rules that were created through that very simple user experience, you can see the one for is empty and is no that we're set up. Now, these are various, uh, styles that can be set up either manually, or you can set them up through machine learning again, or you can inherit them. But the key is to track these, uh, rule creation in the metrics that are generated from these rules so that it can be brought back to the catalog and then used in meaningful context, by someone who's shopping and the confidence that this has neither empty nor no fields, at least most of them don't well now give a confidence as you go forward. >>And as you can see, those checks have now been entered in and you can see that it's a hundred percent quality score for the Knoll check. So with confidence now, John can actually respond back to Eliza and say, I've actually inserted them they're up and running. And, uh, you're in good status. So that was pretty amazing integration, right? And four months after our acquisition, we've already brought that level of integration between, uh, Colibra, uh, data intelligence, cloud, and data quality. Now it doesn't stop there. We have really impressive and high site set early next year. We're getting introduced a fully immersive experience where customers can work within Culebra and actually bring the data quality information all the way in as well as start to manipulate the rules and generate the machine learning rules. On top of it, all of that will be a deeply immersive experience. >>We also have something really clever coming, which we call continuous data profiling, where we bring the power of data quality all the way into the database. So it's continuously running and always making that data available for you. Now, I'd also like to share with you one of the reasons why we are the most universally available software solutions in data intelligence. We've already announced that we're available on AWS and Google cloud prior, but today we can announce to you in Q3, we're going to be, um, available on Microsoft Azure as well. Now it's not just these three cloud providers that were available on we've also become available on each of their marketplaces. So if you are buying our software, you can actually go out and achieve that same purchase from their marketplace and achieve your financial objectives as well. We're very excited about this. These are very important partners for, uh, for our, for us. >>Now, I'd also like to introduce you our system integrators, without them. There's no way we could actually achieve our objectives of growing so rapidly and dealing with the demand that you customers have had Accenture, Deloitte emphasis, and even others have been instrumental in making sure that we can serve your needs when you need them. Uh, and so it's been a big part of our growth and will be a continued part of our growth as well. And finally, I'd like to actually introduce you to our product showcases where we can go into absolute detail on many of the topics I talked about today, such as data governance with Arco or data privacy with Sergio or data quality with Brian and finally catalog with Peter. Again, I'd like to thank you all for joining us. Uh, and we really look forward to hearing your feedback. Thank you..

(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)

>> At Vision '21, we've heard from business leaders, practitioners, developers, analysts, and the Postgres community. One thing's for sure, the next 10 years won't be like the last. And in my view, Vision '21 gave me greater confidence that the Postgres community will evolve as market forces shift. One certainty in that technology businesses that the tech will come and it will go. Open-source is the engine of software innovation and I'm excited to see how the community responds to the challenges ahead. Now, I want to encourage you to come back and check out the on-demand content that will be available immediately following the event. Dig in, share with colleagues, and engage with the community. It's really been our pleasure to cover Vision '21. And we look forward to seeing you at upcoming events, both physical and virtual. This is Dave Vellante for The Cube. Thanks for watching. Be well, and we'll see you next time.

(upbeat music) >> From around the globe, it's theCUBE! With digital coverage of Postgres Vision 2021, brought to you by EDB. >> Welcome back to Postgres Vision 21, where theCUBE is covering the innovations in open source trends in this new age of application development and how to leverage open source database technologies to create world-class platforms that are cost-effective and also scale. My name is Dave Vellante, and with me is Roberto Giordano, who is the End User Computing, Corporate, and Database Services Manager at Borsa Italiana, the Italian Stock Exchange. Roberto, great to have you. Thanks for coming on. >> Thanks Dave, and thanks to the interview friend for the invitation. >> Okay, and we're going to dig in to the great customer story here. First, Roberto, tell us a little bit more about Borsa Italiana and your role at the organization. >> Absolutely. Well, as you mentioned, Borsa is the Italian Stock Exchange. We used to be part of the London Stock Exchange, but last month we left that group, and we joined another group called Euronext, so we are now part of another group, I would say. And right now within Euronext, Euronext provide the biggest liquidity pool in Europe, just to mention something. And basically we provide the market infrastructure to our customers across Europe and the whole world. So probably if it happens for you to buy a little of, I don't know, Ferrari for instance, probably use our infrastructure. >> So I wonder if you could talk about the key drivers in the exchange business in Italy. I don't know how closely you follow what's going on in the United States, but it's crypto madness, there's the Reddit army driving up stocks that have big short positions, and of course the regulators have to look at that, and there's a big debate going on. Well, I don't know what's it like in Italy, but what are the key drivers that are really informing the priorities for your technology strategy? >> Well, you mentioned, for instance, the stereotypical cases that are a little bit of laterally to the global markets and also to our markets as a it professional running market infrastructure is our first the goal to provide an infrastructure that is reliable and be with the lowest possible latency. So we are very focused on performance and reliability just to mention the two main drivers within our systems. >> Well, and you have end-user computing in your title and we're going to get into the database discussion, but I presumably with with COVID you had to pivot and that that piece of your job was escalated in 2020, I would imagine. And you mentioned latency which is a key factor in obviously in database access but that must've been a big challenge last year. >> Well, it was really a challenge, but basically we move just within a weekend, the wall organization working remotely. And it has been like this since February, 2020. Think about the challenge of moving almost 1000 people that used to come to the office every day to start to work remotely. And as within my team of the end user computing this was really a challenge but it was a good one at the end. We, we, we succeeded and everything work. It's fine from our perspective, no news is is a good news, you know, because normally when something doesn't work, we are on newspapers. So if you didn't heard about us it means that everything worked out just fine. >> Yeah. It's amazing, Roberto. We both in the technology business that you'll be you're a practitioner observer, but I mean if you're in the tech business most companies actually pivoted quite well. You're have always been a digital business, different. I mean, if you're a Ferrari and making cars and you can't get semiconductors, but but most technology companies actually made the transition you know, quite amazingly, let's get into the, the case study a bit of it. I wonder if you could paint a picture of your organization's infrastructure and applications what it looks like and and particularly your database infrastructure what does that look like? >> Well, we are a multi-vendor shop. So we would like to pick the right technology for for the right service. This means that my database services teams currently manage several different technology where possible that plays a big role in, in, in our portfolio. And because we, we, we currently support both the open source, fully open source version of Postgres, but also the EDB distribution in particular we prefer to use EDB distribution where we did specific functionalities that just EDB provide. And we, when we need a first class level of support that EDB in recent year was able to provide to us. >> When you say full functioning, are you talking about things like acid compliance, two phase commits? I mean, all these enterprise capabilities, is that right? Or maybe you could be >> Just too much just to mention one, for instance we recently migrated our wire intrasite availability solution using the ADB fail-over manager. That is an additional component that just it'll be provide. >> Yeah. Okay. So, so par recovery obviously is, is and so that's a solution that you to get from the EDB distro as opposed to having to build it yourself with open source tooling. >> Yeah, correct. Well, basically sterically, we used to rely on OSTP clustering from, from, from that perspective. But over the years we found that even if it's a technology that works fine, it has been around for four decades. And so on. We faced some challenges internally because within my team we don't own also the operative system layers. So we want a solution that was 100% within our control and perimeter. So just few months ago we asked the EDB EDB folks if they can provide something. And after a couple of meetings also with their pre-sales engineers, we found the the right solution for us. So we launched long story short, just a quick proof of concept to a tissue test together, again using the ADB consultancy. And, and then we, beginning of this year, we, we went live with the first mission critical service using this brand new technology, well brand new technology for us. You know, it'd be created a few years ago >> And I do have some follow-up questions but I want to understand what catalyzed the, you know what was the motivation for going with an open source database? I mean, you're, you're a great example because you have your multi-vendor so you have experienced with all of it, the full spectrum. What was it about open source database generally EDB specifically that triggered the, the choice? >> Well thanks for the question. It is, this is one of the, or one of the questions that I always, like. I think what really drove us was the right combination between easy to use, so simplicity and also good value for money. So we like to pick the right database technology for the right kind of service slash budget that the survey says and, and the open source solution for a specific service. It, it, it's, it's our, you know, first, first, first choice. So we are not going to say a company that use just one technology. We like to take the best of breed that the market can offer. In some cases, the open source and Postgres in particular is, is our choice. How involved was >> The line of business in this both the decision and the implementation? Was it kind of invisible to them, or this was really more of a technology decision based on the your interpretation of the requirements I'm interested in who was involved and how you actually got it done? >> Well, I, I think this decision was transplant for, for, for, for the business at the end of the day don't really have that kind of visibility. You know, they just provide requirements in particular in terms of performance and rehabil area, the reliability. And so, so this this is something they are not really involved about. And obviously if they, if we are in opposition to save a little bit of money everybody's at the, even the business >> No. So what did you have to do? So that makes sense to me, I figured that was the case. Who would, who were the stakeholders on your team? I mean, what kind of technical resources did you require an implementation resources? What take us through what the project if you will look like, wh how did you do it? >> Well, it's a combination of database expertise. I got the pleasure to run a team that is paid by very, very senior, very, very skilled database services professional that are able to support more than one more than what the county and also are very open to innovation and changes. Plus obviously we need also the development teams the relevant development teams on board, when you when you run this kind of transformations and it looks like also, they liked the idea to use PostgreSQL for for this specific service I got in mind. So it, it, it was quite, quite easy, not be discussion. You know. >> What was the, what was the elapsed time from from when you said, okay, we're in, you know signed the agreement we're going here you made the decision to actually getting into production. >> Well, as I mentioned, we, we, we were on we're on services and application that are really focused on high availability and performance. So generally speaking, we are not a peak organization. Also we run a business that is highly regulated. So as you know, as you can imagine we are an organization that don't have a lot of appetite for risk, you know, so generally speaking in order to run this kind of transformation is a matter of several months, I will say six nine months to have something delivered in that space. >> Okay. Well, that's, I mean, that's reasonable. I mean, if you could do it inside of a year that's I think quite good especially in the highly regulated industry. And then you mentioned kind of the fail over the high availability Cape Cape capabilities. Were there other specific EDB tools that that you utilize to sort of address the objectives? >> Yeah, absolutely. We were in particular, we used Postgres enterprise, AKA Pam. Okay. And very recently we were involved within ADB about per se specifically developing one functionality that, that that we needed back in the day. I think together with Bart these are the free EDB specific tools that, that we, that that we use right now. >> And, and I'm, I'm interested in, I want to get to the business impact and I know it's early days for you but the real motivation was to save money and simplify. I would actually, I would imagine your developers were happy because they get to use modern tooling and open source. But, but really though if your industry is bottom line, right, I mean that's really what the, the business case was all about. But I wonder if you could add some color there in terms of the business impact that you expect. And then, I mean I don't know how much visibility you have now but anything you can share with us. >> Well, thinking about the EFM implementation that the business impact the, was that in case of a failure or the DBA team that a services team is it is able to provide a solution that is within our 100% within our perimeter. So this means that we are fully accountable for it. So in a nutshell, when you run a service, the less people the less teams you have to involve the more control you can deliver. And in some, again, very critical services that is a great value. >> Okay. So, and, and where do you want to take this? I mean, how do you see w what's your, if you're thinking about your Postgres and, and generally an EDB you know, roadmap, where do you want it to go? >> Well, I stay to, to trends within within the organization, the, the, the, the the first one is about migrating more existing services to open source solution for database is going to be, is going to be prosperous. And other trends that I see within my organization is about designing applications, not really to be, to to use PostgreSQL as the base, as it does a base layer. I think both trends are more or less surroundings at the same state right now. >> Yeah. A lot of the audience members at Postgres vision 21 is just like you they they're managing day-to-day infrastructure. They're there they're expert practitioners. What advice would you give to somebody that is thinking about, you know taking this journey, maybe if you had to do something over again maybe what would you do differently? How can you help your peers here? >> Well, I think in particular, if you are going to say a big organization that runs a highly regulated business in some cases, you are a little bit afraid of open source because there is this, I can say general consideration about the lack of enterprise level support. I would like to say that it is just about the past because they're around bunch of companies like EDB that are we're a hundred percent capable of providing enterprise level of support, even on, on, on even on the open source distribution of Paul's presser. Obviously Dan is you're going to go with their specific distribution. The level of support is going to be even more accurate but as we know, it could be currently is they across say main contributor of the pollsters community. And I think is, is that an insurance for every organization? >> Your advice is don't be afraid. >> Yeah. My advice is done is absolutely, don't be, don't be afraid. And if, if, if I can, if we can mention about also about, you know, the cloud called technologies this is also another, another topic where if possible I would like to suggest to not being afraid EDB as every every I would say organization within the it industry is really pushing for it. And I think for a very, for, for a lot of cases not all of them, but a lot of cases, there is a great value about the design services application to be cloud native or migrating existing application into the cloud. >> Okay. But, but being a highly regulated industry and being a, you know, very much aware of the the narrative around open source, et cetera, you, you must've had just a little piece of your mind saying, okay I have to manage this risk. So there's anything specifically you did with managing the risks that you would advise? Was it, was it or is it really just about good change management? >> I think it was mainly about a good change management when you got, you know the relevant stakeholders that you need on board and we are, everybody's going the same direction. That basically is about executing. >> Excellent. Well, Roberto, I really appreciate your time and your knowledge that you share with the audience. So thanks so much for coming on the cube. >> Thank you, Dave. It was a great pleasure. >> And thank you for watching the cubes continuous coverage of Postgres vision 21. We'll be right back. (upbeat music)

>> For years, the database market was steady, and steadily boring. As virtualization went mainstream, organizations began to rethink their database strategies and ask questions like, "should I run Postgres and VMware?" Now implicit in that question was another drill down question. In other words, can VMware itself handle my critical applications and is PostGres the right solution to optimize my infrastructure estate. Now history has shown that was both a safe and good bet for organizations looking to leverage open source innovation and lower their costs. At the same time, new workloads were emerging that were pushing the boundaries of existing relational database technologies, that were designed primarily for transactional workloads. So-called systems of engagement and systems of analytics we're growing at rates much faster than traditional OLTP workloads. Once again, people ask the question, should I think about running these new workloads on Postgres? Now the answer came from the community response that saw the need to extend the open source platform to handle these emerging workloads. The database market suddenly got really interesting as these new applications emerged. Multiple data sources were combined and analyzed to interpret sentiment from social media and get consumers to buy something before they moved to another website, triangulate data to fight fraud, predict weather patterns, and short drug provenance, and dozens of other use cases. Then when cloud went mainstream, similar questions were asked about Postgres. And once again, the open source community responded to accommodate and extend the platform for the cloud. And now Kubernetes is all the rage. When should I run Postgres and Kubernetes, similar theme right? Open source, community, innovation, lowering license costs, minimizing lock-in, maximizing optionality, avoiding too much database sprawl, confidence to support new workloads. These are the factors that customers tell us they use generally to choose a database, and PostGrest specifically. In reality, it's usually pretty obvious what the right strategic fit is for a platform, but buyers want to make sure they have headroom for innovation. They do want to push the envelope on new data types while at the same time managing their risks. And that's where Postgres and the Postgres community in my view has thrived. It's become the ideal solution for what I call the fat middle of workloads, that are increasingly diverse but require a cost effective and stable approach that can scale. These are some of the themes we heard in the morning keynotes from Suzette Kent, former federal CIO who laid down her knowledge on transformation, leadership, and technology modernization. And then EDB CEO Ed Boyajian gave his annual keynote address and talked about the power of data. Data, as we know is growing at a mind-bending exponential rate. It'll make the 2010s look meager by comparison. My big takeaway from his talk really were around using technology to extract value more quickly. I think this is going to become the new new metric in the industry, which basically is every industry is a data-oriented platform now. Yes, software is eating the world, data is eating software. In other words, the new KPI is how long does it take to go from idea to monetization. That is are going to become critical in my opinion, over this next decade. Ed made what I thought was a critical point, and that is you really can't easily define the future. Industries are transforming right before our eyes. And his premise was that you have to pick a data platform that can evolve in unpredictable times. Now, as I pointed out earlier, the Postgres community has stepped up to changing environments for decades. And that really was a point Boyajian hit on pretty hard. Replatforming is happening and he made a convincing argument that Postgres and EDB will be part of that future, with a significant investment in advancing Postgres with hundreds of engineers on the task. He talked about three growth vectors. First, growth in new workloads. He made the claim that around 50% of new EDB customers are deploying new applications. Second, he talked about legacy migrations as another driver, and third was cloud, both traditional compute in the cloud, but also managed services and DBaaS, database as a service. Of course, he also talked about, and there's been a lot of discussion at Vision 2021 about Kubernetes and developers. Big push there. Let me give you my thoughts on that. First, the Kubernetes community is really focused on security and has made a lot of progress in the past 24 months. I think the second point there is developers, they want simplification, and Kubernetes brings that to a greater degree. And it's maturing with more production-ready capabilities. It just some basic, blocking and tackling, like not releasing with an unstable code, (laughs) but it's still early days and the community has some work to do on things like backwards compatibility, for example. And the release cadence of Kubernetes, it's still pretty frequent, which means you got to update scripts and APIs and the like. Remember, Postgres practitioners, they're used to very high levels of stability. So you got to be a little bit careful there. You got to go experiment because you want to take advantage of containers and benefits within Postgres, but you got to make sure you have the right change management in place and you got the resources to be on top of that. The bottom line is Kubernetes is still a toddler, but it's growing up fast. And I have no doubt it will become a staple of the Postgres stack. I'll end where I started, and that's the market. It's gone from stayed and uninteresting years ago to one that one of the most dynamic sectors of IT infrastructure software. And Ed Boyajian talked about the total available market, the TAM, and the valuations that we're seeing today. The market's enormous. I mean, if you just think about traditional database, it's probably 60 to $70 billion, but when you add in all the data and data clouds and decentralized data architectures and eventually edge computing, the market is potentially hundreds of billions of dollars in value for data platforms. So the last thing I'll say about Vision 21 is there's some great content here that spans both the business discussion and also deep practitioner material. And it's useful, has very useful how to's that both educate and inspire. So sit back and enjoy the show. This is Dave Vellante, and you're watching The Cube's continuous coverage of Postgres Vision 21 brought to you by EDB. Thanks for watching.

>> Narrator: From around the globe. It's theCUBE with digital coverage of Postgres vision 2021 brought to you by EDB. >> Welcome back to Postgres Vision 21. My name is Dave Vellante. We're thrilled to welcome Carl Olofsen to theCUBE. Carl is a research vice president at IDC focused on data management. The long-time database analyst is the technologist and market observer. Carl, good to see you again. >> Thanks Dave. Glad to be here. >> All right. Let's let's get into it. Let's talk about, let's go right to the, to the source the open source database space. You know, how, what changes have you seen over the last couple of years in that marketplace? >> Well, this is a dynamic area and it's continuing to evolve. When we first saw the initial open source products like mysQl and PostgreSQL on the early days they were very limited in terms of functionality. They were espoused largely by sort of true believers. You know, people who said everything should be open source. And we saw that mainly they were being used for what I would call rather prosaic database applications. But as time has gone by they both of these products improve. Now there's one key difference, of course, which is a mySQL is company owned open source. So the IP belongs to Oracle corporation. Whereas PostgreSQL is community open source, which means that the IP belongs to the PostgreSQL community. And that can have a big difference in terms of things like licensing and so forth, which really matters now that we're coming into the cloud space because as open-source products moving into the cloud space the revenue model is based on subscriptions. And of course they are always based on subscription to open source cause you don't charge for the license. So what you charge for its support, but in the cloud what you can do is you can set up a database service, excuse me, a database service and then you charge for that service. And if it's open source or it's not open source that actually doesn't matter to the user. If you see what that I mean because they still are paying a subscription fee for a service and they get the service. The main difference between the two types is that if you're a commercial provider of PostgreSQL like enterprise DB, you don't have control over where it goes and you don't have control over the IP and how people use it in different ways. Whereas Oracle owns mySQL so they have a lot more control and they can do things to it on their own. They don't have to consult the community. Now there's also, non-relational open source including MongoDB. And as you may be aware, MongoDB has changed their license. So that it's not possible for third party to offer Mongo DB as a complete managed database service without paying a license fee to MongoDB for that. And that's because they own the IP too. And we're going to see a lot more of this sort of thing. I have conversations with open source all the time and they are getting a little concerned that it has become possible for somebody to simply take their technology, make a lot of money off that. And no money goes back to the community. No money goes back to the IRS. It's a company it's just stays with the supplier. So I think, you know it'll be interesting to see how all this is over time. >> So you're suggesting that the Postgres model then is, is I guess I'll use the word cleaner. And so that feels like it's a it's a benefit or is it a two-edged sword kind of thing? I mean, you were saying before, you know a company controls the IP so they could do things without having to go to the community. So maybe they can do things faster. But at the other hand like you said, you get handcuffed. You think you're going to be able to get a, you know a managed service, but then all of a sudden you're not and the rules change midstream saying it, am I correct? That Postgres, the model is cleaner for the customer? >> Well, you know, I mean, a lot of my friends who are in the open source community don't even consider company owned open source to be true open source because the IP is controlled by a company, not by a community. >> Dave: Right >> So from that perspective certainly Postgres SQL is considered, I don't know if you want to use the word cleaner or more pure or something along those lines, but also because of that the nature of community open source it can be used in many different ways. And so we see Postgres popping up all over the place sometimes partially and sometimes altogether, in other words, a service, a cloud service, we'll take a piece of Postgres and stick it on top of their own technology and offer it. And the reason they do that is they know there are a lot of developers out there who already know how to code for Postgres. So they are immediately first-class users of the service that they're offering. >> So, talk a little bit more about what you're seeing. You just mentioned a lot of different use cases. That's interesting. I didn't realize that was, that was happening. The, what are you seeing in terms of adoption in let's say the last 18, 24 months specific to Postgres? >> Yeah, we're seeing a fair amount of adoption in especially in the middle market. And of course there is rapid adoption in the tech sector. Now, why would that be? Well it's because they have armies of technologists. Who know how to program this stuff. You know, when you, you know, a lot of them will use PostgreSQL without a contract without a support contract, they'll just support themselves. And they can do that because they have the technicians who are capable of doing it. Most regular businesses can't do that. They don't have the staff so they need that support contract. And so that's where a company like enterpriseDB comes. I mentioned them only because they're the leading supplier Postgres to all their other suppliers. >> I was talking to Josh Burgers, red hat and he was, you know, he had just come off a Cubacon and he was explaining kind of what's happening in that community. Big focus of course on security and the whole, you know, so-called shift left. We were having a good discussion about, you know when does it make sense to use, you know Postgres in a container environment should you use Postgres and Kubernetes and he sort of suggested that things have rapidly evolved. There's still, you know, considerations but what are you seeing in terms of the adoption of microservices architectures containers, generally Kubernetes how has that affected the use of things like postsgres? >> So those are all different things or need to be kind of custody. >> Pick your favorite. >> They're related then. So microservices, the microservice concept is that you take an application break it up into little pieces and each one becomes a microservice that's invoked through an API. And then you have this whole structure API system that you use to drive the application and they run. They typically, they run in containers usually Kubernetes govern containers but the reason you do this and this is basically a efficiency because especially in the cloud, you want only to pay for what you use. So when you're running a microservice based application. Applications have lots of little pieces when something needs to be done, microservice fires up it does the thing that needs to be done. It goes away. You only pay for that fraction of a second that the microservice is running. Whereas in a conventional application you load this big heavyweight application. It does stop. It sets some weights with things and does more stuff and sits and waits for things. And you pay for compute for that entire period. So it's much more cost effective to use a microservices application. The thing is that microservice, the concept of microservices is based on the idea that the code is stateless but database code isn't stateless cause it has its attraction to the database which is the ultimate kind of like stateful environment right? So it's a tricky business. Most database technologies that are claimed to be container-based actually run in containers the way they run in servers. In other words, they're not microservice-based they do run in containers. And the reason they're doing that is for portability so that you can deploy them anywhere and you can move them around. But you know deploying a microservice based database is, well, it's it's a big technical project. I mean, that is hard to do. >> Right and so talk about, I mean again we're talking to Josh it was clear that that Kubernetes has evolved, you know quite rapidly at the same time there were cautions. In other words, he would say I think suggested things like, you know, there were known at one point, there were known, you know flaws and known bugs that ship the code that's been been remediated or moderated in terms of that practice but still there's there's considerations just in terms of the frequency of updates. I think he gave the example of when was the last time you know, JVM got, you know, overhauled. And so what kind of considerations should customers think about when considering them, they want the Kubernetes they want the flexibility and the agility but at the same time, if they're going to put it production, they've got to be careful, right? >> Yeah, I think you need to make sure you're using you're using functions that are well-established, you know you wouldn't want to put something into production that's new. They say, oh, here's a new, here's a new operation. Let's try that. And then, you know, you get in trouble. So you want to deal conservative that way you know, Kubernetes is open-source so and the updates and the testing and all that follows a rather slow formal process, you know from the time that the submission comes in to the time that it goes out, whereas you mentioned JVMs JV, but it was owned by Oracle. And so JVMs are managed like products. Now there's a whole sort of legal thing I don't want to get into it as to whether it's legal. They claim it's not libero third parties to build JVMs without paying a licensing. I don't want to talk about that, but it's based on a very state that has a very stable base, you know whereas this area of Kubernetes and govern containers is still rapidly evolving but this is like any technology, right? I mean, when you, if you're going to commit your enterprise to functions that run on an emerging technology then you are accepting some risk. You know, that there's no question about it. >> So we talked about the cloud earlier and the whole trend toward managed services. I mean, how does that specifically apply to Postgres? You can kind of imagine like a sidecar, a little bit of Postgres mixed in with, you know, other services. So what do you see and what do you, what's your telescope say in terms of the the Postgres adoption cloud? How do you see that progressing? >> I think there's a lot of potential. There's a lot of potential there. I think we are nowhere near the option that it should be able to achieve. I say that because for one thing, even though we analyze the future at IDC, that doesn't mean we actually know the future. So I can't say what its adoption will be but I can say that there's a lot of potential there. There's a tremendous number of Postgres developers out there. So there's a huge potential for adoption. And especially in cloud adoption, the main thing that would help that is independent. And I know that enterpriseDB has one independent a managed cloud service. So I think they do. >> Yeah I think so. >> But you know, why do I say that? I say that because alternatives these days there are some small companies that maybe they'll survive and maybe they won't, but that, you know, do you want to get involved with them or the cloud platform providers, but if you use their Postgres you're locked into that cloud platform. You know, if you use Amazon, go press on RDS, right? You're not, you become quickly locked in because you're starting using all the AWS tools that surround it to build and manage your application. And then you can't move. If you see what I mean. >> Dave: Yeah . >> They have have an RDS labor Aurora, and this is actually one of the things that it's really just a thin layer of Postgres interaction code underneath Aurora is their own product. so that's an even deeper level of commitment. >> So what has to happen for, so obviously cloud, you know, big trend. So the Postgres community then adopts the code base for the cloud. Obviously EDB has, you know hundreds of developers contributing to that, but so what does that mean to be able to run in the cloud? Is that making it cloud native? Is that extensions? Is it, you know, what technically has to occur and what has occurred and how mature is it? >> Well, so smaller user organizations are able to migrate fairly quickly cloud because most of their applications are you know, commercially purchased. They're like factories applications. When they move to the cloud, they get the SAS one and often the SAS equivalent runs on Postgres. So that's just fine. Larger enterprises are a real mess. If you've ever been in a large enterprise data center you know what I'm talking about? It's just, there's just servers and storage everywhere. There's, all these applications, databases connections. They are not moving to the cloud anytime soon. But what they are doing is setting up things like private cloud environments and applying in there. And this is a place where if you're thinking about moving to something like a Postgres you know most of these enterprises use the big commercial databases. Oracle SQLserver DB two and so forth. If you're thinking of moving from that to a a PostgreSQL development say, then the smart thing to do would be first to do all your work in the private cloud where you'd have complete control over the environment. It also makes sense still to have a commercial support contract from a vendor that you trust, because I've said this again, unless you are, you know, Cisco or somebody, you know, some super tech company that's got all the technicians you need to do the work. You really don't want to take on that level of risk. If you see that, I mean. Another advantage to working with a supplier, a support supplier, especially if you have a close, intimate relationship is they will speed your security patches on a regular basis which is really important these days, because data security is as you know, a growing concern all over the place. >> So let's stay on the skillsets for a minute. Where do you see the gaps within enterprises? What kind of expertise you mentioned, you know support contracts, what are the types of things that a customer should look for in terms of the the expertise to apply to supporting Postgres databases? >> Well, obviously you want them to do the basics that any software company does, right? You want them to provide you with regular updates and binary form that you can load and, you know test and run. You want to have the you know, 24 hour hotline you know, telephone support, all that kind of thing. I think it's also important to have a solid ability on the part of the vendor that you're working with to provide you with advice and counseling as you, especially, if you're migrating from another technology, help your people convert from what they were using to what they're going to be using. So those are all aspects that I would look for in a vendor for supporting a product like PostgreSQL. >> When you think about the migration to the cloud, you know of course Amazon talks a lot about cloud migration. They have a lot of tooling associated with that. >> Carl: Right. >> But when you step back and look at it it did to a point earlier, I mean a lot of the hardcore mission, critical stuff isn't going to move it, hasn't moved, but a lot of the fat middle, you know, is, are good candidates for it. >> Carl: Right. >> How do you think about that? And how do you look at that? I mean, obviously Oracle is trying to shove everything into OCI and they're, you know, they're all in because they realized that could make a lot of money doing that. But what do you, what are the sort of parameters that we should think about when considering that kind of migration, moving a legacy database into the cloud? >> Well, it has to be done piecemeal. You're not going to be able to do it all at once. You know, if you have hundreds of applications, you're not just you don't even want to, you know, it's a good time to take you into it. And what you've got running, ask yourself are these applications really serving the business interests today and will they in the future or is this a good time to maybe consider something else? Even if you have a packaged application, there might be one that is more aligned with your future goals. So it's important to do that. Look at your data integration, try to simplify it. You know, most data integration that most companies has done piecemeal project by project. They don't reference each other. So you have this chaos of ETL jobs and transformation rules and things like that that are just, you know, even difficult to manage. Now, just forget about any kind of migration or transformation considerations, just trying to run it now is becoming increasingly difficult. You know, maybe you want to change your strategy for doing data integration. Maybe you want to consolidate you want to put more data in one database. I'm not an advocate of the idea that you can put all application data in one database by the way, we know from bitter experience that doesn't work, but we can be rational about the kinds of databases that we use and how they sit together. >> Well, I mean, you've been following this for a long time and you saw the sort of rise and fall of the big data meme. And you know, this idea that you can shove everything into a single place, have a single version of the truth. It's like, it's just never seemed to happen. >> Carl: Right. >> So, you know, Postgres has been around a long time. It's evolved. I mean, I remember when, you know, VMware's ascendancy and people are like, okay, should I, you know should I virtualize my Postgres database is your, you know similar conversations that we were having earlier about Kubernetes. You've seen the move to the cloud. We're going to have this conversation about the edge at some point in time. So what's your outlook for Postgres, the Postgres community and, you know database market overall? >> Well, I really think the future for database growth is in the cloud. That's what all the data we're looking at and the case that's what our recent surveys indicate. As I said before, the rate of change depends on the size of the enterprise. Smaller advices are moving rapidly, large enterprises much more slowly and cautiously for the very simple reason that it's a very complex proposition. And also in some cases, they're wondering if they can move certain data or will they be violating your some sort of regulatory constraint or contractual issue. So they need to deal with those things too. That's why the private cloud is the perfect place to get started and get technology all lined up storing your data center is still under your control no legal issues there, but you can start, you know converting your applications to micro-service architected applications running in containers. You can start replacing your database servers with ones that can run in a container environment and maybe in the future, maybe hope that in the future, some of those will actually also be able to run as microservices. I don't think it's impossible but it just involves programming the database server in a very different way than we've done in the past. But you do those things. You can do those things under your own control over time in your own dataset. And then you reach a point where you want to take the elements of your application environment and say, what pieces of this, can I move to the cloud without creating disruption and issues regarding things like data egress and latency from cloud to data center and that kind of thing. And prepare for that. And then you're doing the step wise and then you start converting in a stepwise manner. I think ultimately it just makes so much sense to be in the cloud that the cloud vendors have economies of scale. They can deploy large numbers of servers and storage systems to satisfy the needs of large numbers of customers and create, you know great considerable savings. Some of which of course becomes their profit which is what's due to them. And some of that comes back to the users. So that's what I expect. We're going to see. And oh gosh, I would say that starting from about three years from now the larger enterprises start making their move and then you'll really start to see changes in the numbers in terms of cloud and cloud revenue. >> Great stuff, Carl, thank you for that. So any cool research you're working on lately, how you're spending your your work time, anything you want to plug? >> Well, working a lot on just as these questions, you know cloud migration is a hot topic, another which is really sort of off the subject. And what we've been talking about is graph database which I've been doing a fair amount of research into. I think that's going to be really important in the coming years and really, you know working with my colleagues in a project called the future of intelligence which looks at all the different related elements not just database, data integration but artificial intelligence, data communications and so on and so forth and how they come together to create a more intelligent enterprise. And that's a major initiative that I see. It's one of the, we call the future of initiatives. >> Great, Carls, thanks so much for coming back to theCUBE. It's great to have you, man. I appreciate it. >> Well, I enjoyed it. Now I have to do it again sometime. >> All right you got it. All right thank you everybody for watching theCUBEs. Continuous coverage of Postgres vision 21. This is Dave Vellante keep it right there. (upbeat music)

(upbeat music) >> From around the globe, it's theCUBE! With digital coverage of Postgres Vision 2021, brought to you by EDB. >> Welcome back to Postgres Vision 21, where theCUBE is covering the innovations in open source trends in this new age of application development and how to leverage open source database technologies to create world-class platforms that are cost-effective and also scale. My name is Dave Vellante, and with me is Roberto Giordano, who is the End User Computing, Corporate, and Database Services Manager at Borsa Italiana, the Italian Stock Exchange. Roberto, great to have you. Thanks for coming on. >> Thanks Dave, and thanks to the interview friend for the invitation. >> Okay, and we're going to dig in to the great customer story here. First, Roberto, tell us a little bit more about Borsa Italiana and your role at the organization. >> Absolutely. Well, as you mentioned, Borsa is the Italian Stock Exchange. We used to be part of the London Stock Exchange, but last month we left that group, and we joined another group called Euronext, so we are now part of another group, I would say. And right now within Euronext, Euronext provide the biggest liquidity pool in Europe, just to mention something. And basically we provide the market infrastructure to our customers across Europe and the whole world. So probably if it happens for you to buy a little of, I don't know, Ferrari for instance, probably use our infrastructure. >> So I wonder if you could talk about the key drivers in the exchange business in Italy. I don't know how closely you follow what's going on in the United States, but it's crypto madness, there's the Reddit army driving up stocks that have big short positions, and of course the regulators have to look at that, and there's a big debate going on. Well, I don't know what's it like in Italy, but what are the key drivers that are really informing the priorities for your technology strategy? >> Well, you mentioned, for instance, the stereotypical cases that are a little bit of laterally to the global markets and also to our markets as a it professional running market infrastructure is our first the goal to provide an infrastructure that is reliable and be with the lowest possible latency. So we are very focused on performance and reliability just to mention the two main drivers within our systems. >> Well, and you have end-user computing in your title and we're going to get into the database discussion, but I presumably with with COVID you had to pivot and that that piece of your job was escalated in 2020, I would imagine. And you mentioned latency which is a key factor in obviously in database access but that must've been a big challenge last year. >> Well, it was really a challenge, but basically we move just within a weekend, the wall organization working remotely. And it has been like this since February, 2020. Think about the challenge of moving almost 1000 people that used to come to the office every day to start to work remotely. And as within my team of the end user computing this was really a challenge but it was a good one at the end. We, we, we succeeded and everything work. It's fine from our perspective, no news is is a good news, you know, because normally when something doesn't work, we are on newspapers. So if you didn't heard about us it means that everything worked out just fine. >> Yeah. It's amazing, Roberto. We both in the technology business that you'll be you're a practitioner observer, but I mean if you're in the tech business most companies actually pivoted quite well. You're have always been a digital business, different. I mean, if you're a Ferrari and making cars and you can't get semiconductors, but but most technology companies actually made the transition you know, quite amazingly, let's get into the, the case study a bit of it. I wonder if you could paint a picture of your organization's infrastructure and applications what it looks like and and particularly your database infrastructure what does that look like? >> Well, we are a multi-vendor shop. So we would like to pick the right technology for for the right service. This means that my database services teams currently manage several different technology where possible that plays a big role in, in, in our portfolio. And because we, we, we currently support both the open source, fully open source version of PostgreSQL, but also the EDB distribution in particular we prefer to use DDB distribution where we did specific functionalities that just EDB provide. And we, when we need a first class level of support that ADB in in recent year was able to provide to us. >> When you say full functioning, are you talking about things like acid compliance, two phase commits? I mean, all these enterprise capabilities, is that right? Or maybe you could be >> Just too much just to mention one, for instance we recently migrated our wire intrasite availability solution using the ADB fail-over manager. That is an additional component that just it'll be provide. >> Yeah. Okay. So, so par recovery obviously is, is and so that's a solution that you to get from the EDB distro as opposed to having to build it yourself with open source tooling. >> Yeah, correct. Well, basically sterically, we used to rely on OSTP clustering from, from, from that perspective. But over the years we found that even if it's a technology that works fine, it has been around for four decades. And so on. We faced some challenges internally because within my team we don't own also the operative system layers. So we want a solution that was 100% within our control and perimeter. So just few months ago we asked the EDB EDB folks if they can provide something. And after a couple of meetings also with their pre-sales engineers, we found the the right solution for us. So we launched long story short, just a quick proof of concept to a tissue test together, again using the ADB consultancy. And, and then we, beginning of this year, we, we went live with the first mission critical service using this brand new technology, well brand new technology for us. You know, it'd be created a few years ago >> And I do have some follow-up questions but I want to understand what catalyzed the, you know what was the motivation for going with an open source database? I mean, you're, you're a great example because you have your multi-vendor so you have experienced with all of it, the full spectrum. What was it about open source database generally EDB specifically that triggered the, the choice? >> Well thanks for the question. It is, this is one of the, or one of the questions that I always, like. I think what really drove us was the right combination between easy to use, so simplicity and also good value for money. So we like to pick the right database technology for the right kind of service slash budget that the survey says and, and the open source solution for a specific service. It, it, it's, it's our, you know, first, first, first choice. So we are not going to say a company that use just one technology. We like to take the best of breed that the market can offer. In some cases, the open source and Pasquesi in particular is, is our choice. How involved was >> The line of business in this both the decision and the implementation? Was it kind of invisible to them, or this was really more of a technology decision based on the your interpretation of the requirements I'm interested in who was involved and how you actually got it done? >> Well, I, I think this decision was transplant for, for, for, for the business at the end of the day don't really have that kind of visibility. You know, they just provide requirements in particular in terms of performance and rehabil area, the reliability. And so, so this this is something they are not really involved about. And obviously if they, if we are in opposition to save a little bit of money everybody's at the, even the business >> No. So what did you have to do? So that makes sense to me, I figured that was the case. Who would, who were the stakeholders on your team? I mean, what kind of technical resources did you require an implementation resources? What take us through what the project if you will look like, wh how did you do it? >> Well, it's a combination of database expertise. I got the pleasure to run a team that is paid by very, very senior, very, very skilled database services professional that are able to support more than one more than what the county and also are very open to innovation and changes. Plus obviously we need also the development teams the relevant development teams on board, when you when you run this kind of transformations and it looks like also, they liked the idea to use PostgreSQL for for this specific service I got in mind. So it, it, it was quite, quite easy, not be discussion. You know. >> What was the, what was the elapsed time from from when you said, okay, we're in, you know signed the agreement we're going here you made the decision to actually getting into production. >> Well, as I mentioned, we, we, we were on we're on services and application that are really focused on high availability and performance. So generally speaking, we are not a peak organization. Also we run a business that is highly regulated. So as you know, as you can imagine we are an organization that don't have a lot of appetite for risk, you know, so generally speaking in order to run this kind of transformation is a matter of several months, I will say six nine months to have something delivered in that space. >> Okay. Well, that's, I mean, that's reasonable. I mean, if you could do it inside of a year that's I think quite good especially in the highly regulated industry. And then you mentioned kind of the fail over the high availability Cape Cape capabilities. Were there other specific EDB tools that that you utilize to sort of address the objectives? >> Yeah, absolutely. We were in particular, we used Postgres enterprise, AKA Pam. Okay. And very recently we were involved within ADB about per se specifically developing one functionality that, that that we needed back in the day. I think together with Bart these are the free EDB specific tools that, that we, that that we use right now. >> And, and I'm, I'm interested in, I want to get to the business impact and I know it's early days for you but the real motivation was to save money and simplify. I would actually, I would imagine your developers were happy because they get to use modern tooling and open source. But, but really though if your industry is bottom line, right, I mean that's really what the, the business case was all about. But I wonder if you could add some color there in terms of the business impact that you expect. And then, I mean I don't know how much visibility you have now but anything you can share with us. >> Well, thinking about the EFM implementation that the business impact the, was that in case of a failure or the DBA team that a services team is it is able to provide a solution that is within our 100% within our perimeter. So this means that we are fully accountable for it. So in a nutshell, when you run a service, the less people the less teams you have to involve the more control you can deliver. And in some, again, very critical services that is a great value. >> Okay. So, and, and where do you want to take this? I mean, how do you see w what's your, if you're thinking about your Postgres and, and generally an EDB you know, roadmap, where do you want it to go? >> Well, I stay to, to trends within within the organization, the, the, the, the the first one is about migrating more existing services to open source solution for database is going to be, is going to be prosperous. And other trends that I see within my organization is about designing applications, not really to be, to to use PostgreSQL as the base, as it does a base layer. I think both trends are more or less surroundings at the same state right now. >> Yeah. A lot of the audience members at Postgres vision 21 is just like you they they're managing day-to-day infrastructure. They're there they're expert practitioners. What advice would you give to somebody that is thinking about, you know taking this journey, maybe if you had to do something over again maybe what would you do differently? How can you help your peers here? >> Well, I think in particular, if you are going to say a big organization that runs a highly regulated business in some cases, you are a little bit afraid of open source because there is this, I can say general consideration about the lack of enterprise level support. I would like to say that it is just about the past because they're around bunch of companies like EDB that are we're a hundred percent capable of providing enterprise level of support, even on, on, on even on the open source distribution of Paul's presser. Obviously Dan is you're going to go with their specific distribution. The level of support is going to be even more accurate but as we know, it could be currently is they across say main contributor of the pollsters community. And I think is, is that an insurance for every organization? >> Your advice is don't be afraid. >> Yeah. My advice is done is absolutely, don't be, don't be afraid. And if, if, if I can, if we can mention about also about, you know, the cloud called technologies this is also another, another topic where if possible I would like to suggest to not being afraid EDB as every every I would say organization within the it industry is really pushing for it. And I think for a very, for, for a lot of cases not all of them, but a lot of cases, there is a great value about the design services application to be cloud native or migrating existing application into the cloud. >> Okay. But, but being a highly regulated industry and being a, you know, very much aware of the the narrative around open source, et cetera, you, you must've had just a little piece of your mind saying, okay I have to manage this risk. So there's anything specifically you did with managing the risks that you would advise? Was it, was it or is it really just about good change management? >> I think it was mainly about a good change management when you got, you know the relevant stakeholders that you need on board and we are, everybody's going the same direction. That basically is about executing. >> Excellent. Well, Roberto, I really appreciate your time and your knowledge that you share with the audience. So thanks so much for coming on the cube. >> Thank you, Dave. It was a great pleasure. >> And thank you for watching the cubes continuous coverage of Postgres vision 21. We'll be right back. (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)

>>Ed. Biology in 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 um key things that we're going to be covering were because of our focus on the enterprise. We're gonna we're gonna 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 Ebs 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 gonna put some cycles into sharing a little more depth than 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 dot com and register the cube is gonna be there. We hope you will be too. Ed, thanks for coming on the Cuban previewing the event. >>Thanks Dave. >>Thank you. We'll see you at Vision 21.

>>From around the globe, it's the Cube with digital coverage of postgres Vision 2021 brought to you by >>enterprise DB. Hello everyone. This is Dave Volonte for the cube we're covering Postgres Vision 2021. The virtual cube edition. Welcome to our conversation with the Ceo Ed Boyajian is here is the Ceo of enterprise DB and we're gonna talk about what's happening in open source and database in the future of tech. Ed welcome. >>Hi Dave, Good to be here. >>Hey, several years ago, at a, at a Postgres Vision event, you put forth the premise that the industry was approaching a threshold moment, a digital transformation was the linchpin of that shift now. Ed Well 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. Maybe a few accelerated their digital initiatives, but generally pre Covid, we moved in a pretty incremental pace and then the big bang hit. And if you were digital business, you are 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 e d B generally the right fit for this new world? >>Yeah, I think, look, a couple of things are happening gave 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 B D B I think first and foremost we're seeing a dramatic re platform ng. And just like we saw in the world of Lennox where I was at red hat during that shift where people are moving from UNIX based systems to x 86 systems. We're seeing that similar re platform in 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 so they don't just live in I. T. Anymore. And I think as developers take on more power and control their defining the agenda and it's another place where Postgres shines, it's been a priority of the dBS to make postgres easier. Uh and that's coming to life. And I think the last Stack Overflow Developer Survey suggested that I think they survey 65 developers, the second most loved and the second most used database by developers, Postgres. And so I think there again Postgres shines in a moment of change. Uh 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 gonna jump ahead to the future for a second because you're talking about the re platform NG and with your red hat chops, I kind of want to pick your brain on this because you're right, you saw it with red hat and you're kind of seeing it again when you think about open shift and where it's going my my question is related to replant forming around new types of workloads, new processing models at the edge. I mean you're seeing an explosion of processing power, GPU SNP us accelerators, dSPs and it appears that this is happening at a very low cost. I'm referring that you're saying Postgres can take advantage of that trend as well that that broader re platform ng trend to the edge, is that correct? >>It is. And I think you know this is, this has been one of the, I think the most interesting things with posters now I've been here almost 13 years. So if you put that in some perspective, I've watched Uh 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 of time, not only as Postgres gotten more performant 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 time frame I think if you went back to 2008 when I joined E D. B, post chris was considered a really good general purpose database. And today I think post chris 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. Let me just spend a second on it. We look at our customer base is deploying in what we think of as systems of record, which are the traditional er, P type apps, uh you know where there's a single source of truth you might think of the RP apps there. We look at our customers deploying in 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 in the third area 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. >>And as always alluding to before that that itself is evolving as you now inject ai into the equation ai influencing 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 post grass and maybe talk about other database models. Uh, I mean you mentioned that you've evolved from this, you know, system of record. You can take a system engagement on structured data etcetera. Jason. It's so how should we think about post grass 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 first and foremost Postgres, you know, at his core, post chris is a sequel, relational databases in acid 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, um, you know, database requirements, whether that's geospatial or or Jason, uh, for documents or time series, things like that. And so Postgres extensive bility 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 the number of workloads because at the end of the day there's still value in having a database is 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 cross cross over in that way. Um and I think that is, you know, one of the different key differentiators in how we've seen the market in the business development 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 that come to us today for new uh new postgres users are deploying us on new applications. The others are our second area migrating away from some existing legacy in companies often oracle. Not always. Um The third area of growth we see is in cloud, where Postgres is deployed very prolifically, both in the traditional cloud platforms, Uh like EC two, but then then again also uh in the database as a service environment. And then the fourth area growth we're seeing now is around uh container deployment, kubernetes deployment. >>Well, you may Oracle's prominent because it's just it's a big installed base and it's expensive and people, >>you >>know, they got a look at them. 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 gonna you're gonna drop right to the bottom line. But but but but I want to ask you about that 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. It might be 10 or 12 data stores in the cloud. On the other hand, you've got, you know, kind of a converged approach. Oracle's going that direction clearly. Postgres with its open source innovation is going that direction. And it seems to me that at scale that's a more the latter is a 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 business side of my brain looks at that as an addressable market question. Right? And you've heard me talk about three broad categories of workloads and you know, people define workloads in different bucket, 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. Uh and there that's you know, let's just say for the sake of arguments of $45-$50 billion $18 billion dollar market. 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 red is cockroach neo, all of those. I mean hugely valued companies. All unicorn companies. But combined to 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. Um Snowflake, you're still talking you know a billion five in revenue and an $18 billion market. So while those are all important technologies, the question is in this transformation move to the database market fully transform you. And my view is no it didn't were 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 nature of the workloads fits with postgres and the future tech that we're building in post schools 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 talk about the data growth, the data explosion, we see the I. D. C. Numbers and you ain't seen nothing yet. And so data by its very nature is distributed. That's why I get so excited about these new platform models and and I want to tie it back to developers and open source because to me that is the linchpin of innovation um 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 and specifically Postgres and an open source, you know, what can you share with us in terms of how we should think about your advantage, and again, what, 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, uh and when you step away from it again, I remember I told you I was at red hat before, now here at E D B, and there's a common thread that runs through those two experiences 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. E D B plays a big role in that. About approaching a third of the contributions. In the last release released, 13 of Postgres came from E D B. You might look at that and say gee, that sounds like a lot, but if you step away from it, you know, about 30% of those contributions, Most of the contributions come from a universe around D D. B. 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. And then contrast that to some of the other prominent high value open source companies, the companies and the communities are intimately intertwined. They're one and the same. They're actually not independent open source communities. And I think that therein lies one of the, one of the inherent weaknesses in those but postgres to rise because you know, we bring all those ideas from the DB, we bring a commercial contingent with us 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 post chris at scale. And I think that's the heart of what makes a successful independent project. >>Yeah. The combinatorial powers of of that ecosystem. Uh they their their multiplication, I've as opposed to 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 post the category is in transit database categories and transformation. And we know that many of our people are interested in. Postgres are early in their journey, their early in their experience. And so we want to focus this year's postcards vision on them that we understand as a company has been committed to postgres as long as we have and with the understanding we have the technology and best practices, we want to share that view those insights uh, 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 enterprise db dot com and register the cube is going to be there. We hope you will be too. Ed, thanks for coming to the Cuban previewing the event. >>Thanks Dave. >>Thank you. We'll see you at Vision 21 >>mm mm.