 Developers have become the new king makers in the world of digital and cloud. The rise of containers and microservices has accelerated the transition to cloud native applications. A lot of people will talk about application architecture, the related paradigms and the benefits they bring for the process of writing and delivering new apps. But a major challenge continues to be the how and the what when it comes to accessing, processing and getting insights from the massive amounts of data that we have to deal with in today's world. And with me are two experts from the data management world who will share with us how they think about the best techniques and practices based on what they see at large organizations who are working with data and developing so-called data-driven apps. Please welcome Maria Colgan and Gerald Venzel, two distinguished product managers from Oracle. Folks, welcome, thanks so much for coming on. Thanks for having us. Thank you very much for having us. Okay, let's start with you. So, we throw around this term data-driven, data-driven applications. What is it we really talking about there? So data-driven applications are applications that work on a diverse set of data. So anything from spatial to sensor data, document data, as well as your usual transaction processing data. And what they're going to do is they'll generate value from that data in very different ways to a traditional application. So for example, they may use machine learning to be able to do product recommendations in the middle of a transaction. Or we could use graph to be able to identify an influencer within a community so we can target them with a specific promotion. It could also use spatial data to be able to help find the nearest stores to a particular customer. And because these apps are deployed on multiple platforms, everything from mobile devices as well as standard browsers, they need a data platform that's going to be both secure, reliable, and scalable. Well, so when you think about how the workloads are shifting, and we're not talking about, it's not any more a world of just your ERP or your HCM or your CRM, kind of the traditional operational systems. It really are seeing an explosion of these new data-oriented apps. You're seeing modeling in the cloud. You're going to see more and more inferencing, inferencing at the edge. But Maria, maybe you could talk a little bit about sort of the benefits that customers are seeing from developing these types of applications. So why should people care about data-driven apps? Oh, for sure, there's massive benefits to them. I mean, probably the most obvious one for any business, regardless of the industry, is that they not only allow you to understand what your customers are up to, but they allow you to be able to anticipate those customers' needs. So that helps businesses maintain that competitive edge and retain their customers. But it also helps them make data-driven decisions in real time based on actual data, rather than on somebody's gut feeling or basing those decisions on historical data. So for example, you can do real-time price adjustments on products based on demand and so forth, that kind of thing. So it really changes the way people do business today. So Gerald, you think about the narrative in the industry. Everybody wants to be a platform player. Oh, your customers, they're becoming software companies, they're becoming platform players. Everybody wants to be like, name a company that has a huge trillion dollar market cap or whatever, and those are data-driven companies. And so it would seem to me that data-driven applications, there's nobody who, no company really shouldn't be data-driven, do you buy that? Yeah, absolutely. I mean, data-driven in the much of the whole industry is data-driven, right? It's like we all have information technologies about processing data and deriving information out of it. But when it comes to app development, I think there is a big push to kind of like, we have to do machine learning in our applications, we have to get insights from data. And when you actually look back a bit or take a step back, you see that there's of course many different kinds of applications out there as well, that's not to be forgotten, right? So there's a usual front-end user interfaces where really the application all it does is just entering some piece of information that's stored somewhere or perhaps a microservice that's not attached to a data tier at all, but just receives a REST call and send off a REST call. So I think it's not necessarily so important for every developer to kind of go on a bandwagon that they have to be data-driven, but I think it's equally important for those applications and those developers, the build applications that drive the business, that make business critical decisions. As Maria mentioned before, those guys should take really a close look into what data-driven apps means and what the data tier can actually give to them because what we see also happening a lot is that a lot of the things that are well known and out there just ready to use are being re-implemented in the applications. And for those applications, they essentially just end up spending more time writing codes that would be already there and then have to maintain and debug the code as well rather than just going to market faster. Gerald, can you talk to the prevailing approaches that developers take to build data-driven applications? What are the ones that you see? Let's dig into that a little bit more and maybe differentiate the different approaches and talk about that. Yeah, absolutely. I think right now the industry is like in two camps. It's like sort of a religious war going on that you see often happening with different architectures and so forth going on. So we have single-purpose databases or data management technologies, which are technologies that are, as the name suggests, built around a single purpose. So it's like, you know, typically example would be your ordinary key value store, right? The key value store, all it does is it allows you to store and retrieve a piece of data, whatever that may be, really, really fast, but it doesn't really go beyond that. And then the other side of the house or the other camp would be multimodal databases, multimodal data management technologies. Those are technologies that allow you to store different types of data, different formats of data in the same technology and the same system alongside. And, you know, when you look at the geographics out there of what we have from technologies, pretty much any relational database or any database really has evolved into such a multimodal database, whether that's MySQL that allows you to store JSON alongside relational or even a MongoDB that allows you to, or gives you native graph support since a while now as well alongside their JSON support. Well, it's clearly a trend in the industry. We've talked about this a lot in theCUBE and we know where Oracle stands on this. I mean, you just mentioned MySQL, but Oracle databases have been extending, you mentioned JSON, we've got Blockchain now in there, you're infusing ML and AI into the database, graph database capabilities on and on and on. We talked a lot about, we compared that to Amazon, which is kind of the right tool, the right job approach. So maybe you could talk about, you know, for your point of view, the benefits for developers of using that converged database, if I can use that word approach, being able to store multiple data formats. Why do you feel like that's a better approach? Yeah, I think on a high level, it comes down to complexity or actually avoiding additional complexity, right? So not every use case that you have necessarily warrants to have yet another data management technology or yet the special build technology for managing the data, right? It's like many use cases that we see out there, happily want to just store a piece of JSON document, a piece of JSON in a database and then perhaps retrieve it again afterwards or write some simple queries over it. And you really don't have to get a new database technology or no SQL database into the mix if you already have some to just fulfill that exact use case. You could just happily store that information as well in the database you already have. And what it really comes down to is the learning curve for developers. So it's like, as you use the same technology to store other types of data, you don't have to learn a new technology. You don't have to associate yourself with new and learn new drivers. You don't have to find new frameworks and you don't have to know how to necessarily operate or best model your data for the database. You can essentially just reuse your knowledge of the technology as well as the libraries and code you have already built in-house, perhaps in another application, perhaps framework that you use against the same technology because it is still the same technology. So kind of all comes down again to avoiding complexity and not fragmenting the many different technologies we have if you were to look at the different data formats that are out there today. It's like, you would end up with many different databases just to store them if you were to fully religiously follow the single purpose best built technology for every use case paradigm, right? And then you would just end up having to manage many different databases, more than actually focusing on your app and getting value to your business or to your user. Okay, so I get that and I buy that, by the way. I mean, especially if you're a larger organization and you've got all these projects going on, but before we go back to Maria, Gerald, I want to push on that a little bit because the counter to that argument would be in the analogy, and I wonder if you, I'd love for you to knock this analogy off the blocks. The counter would be, okay, Oracle's the Swiss Army Knife and it's got all in one, but sometimes I need that specialized long screwdriver and I go into my toolbox and I grab that, it's better than the screwdriver in my Swiss Army Knife. Why are you the Swiss Army Knife of databases or are you the all in one, have that best of breed screwdriver for me? How do you think about that? Yeah, that's a fantastic question, right? And I think it's first of all, you have to separate between Oracle, the company that has actually multiple data management technologies and databases out there as you said before, right? And Oracle Database. And I think Oracle Database is definitely a Swiss Army Knife that has many capabilities of since the last 40 years, you know, that we've seen objects support coming that's still in the Oracle Database today. We have seen XML coming that's still in the Oracle Database, graph spatial, et cetera. So you have many different ways of managing your data and then on top of that going into the conversion, not only do we allow you to store the different data model in there, but we actually allow you also to apply all the security policies and so forth on top of it, something Maria can talk more about the mission of Chrome Converged Database. I would also argue though, that for some aspects, we do actually have to or are the screwdriver that you talked about as well. So especially in the relational world, people get very quickly hung up on this idea that if you only do rows and columns, well, that's kind of what you put down on disk. And that was never true. It's the relational model is actually a logical model. What's being put down on disk is blocks that align themselves nice with block storage and that always has been. So that allows you to actually model and process the data differently. And one common example, or one good example that we have what we introduced a couple of years ago was when column databases were very strong and the competition came with like, yeah, we have in-memory column of stores now there's so much better. And we were like, well, orienting the data row based or column based really doesn't matter in the sense that we store them as blocks on disks. And so we introduced the in-memory technology which gives you an in-memory column representation of your data as well alongside the relational. So there is an example where you go like, well, actually, you know, if you have this use case of a column analytics that all in memory, I would argue Oracle Database is also that screwdriver you want to go down to and gives you that capability because not only gives you representation in columnar, but also which many people and forget all the analytic power on top of SQL. It's one thing to store your data column it's a completely different story to actually be able to run analytics on top of that and having all the built-in functionalities and stuff that you want to do with the data on top of it as you analyze it. You know, that's a great example, the columnar, because I remember there was like a lot of hype around it. Oh, it's the Oracle killer. You had Vertica, Vertica is still around, but you know, never really hit escape velocity, but you know, good product, good company, whatever. Neteza, you kind of got buried inside of IBM. ParXL kind of became, you know, Redshift with that deal. So that kind of went away. TeraData bought a company. I forget which company it bought. So that hype kind of dissipated and now it's like, oh yeah, columnar. It's kind of like in memory. We've had in-memory databases ever since we've had databases, you know. It's a good of a feature, not a sector. But anyway, Muriel, let's come back to you. You've got a lot of customer experience and you speak with a lot of companies, you know, during your time at Oracle. What else are you seeing in terms of the benefits to this approach that might not be so intuitive and obvious right away? I think one of the biggest benefits to having a multi-model, multi-workloader, as we call it, a converged database, is the fact that you can get greater data synergy from it. In other words, you can utilize all these different techniques and data models to get better value out of that data. So things like being able to do real-time machine learning fraud detection inside a transaction or being able to do a product recommendation by accessing three different data models. So for example, if I'm trying to recommend a product for you, Dave, I might use graph analytics to be able to figure out your community, not just your friends, but other people on our system who look and behave just like you. Once I know that community, then I can go over and see what products they bought by looking up our product catalog, which may be stored as JSON. And then on top of that, I can then see using the key value, what products inside that catalog, those community members gave a five-star rating to. So that way I can really pinpoint the right product for you. And I can do all of that in one transaction inside the database without having to transform that data into different models or God forbid, access different systems to be able to get all of that information. So it really simplifies how we can generate that value from the data. And of course, the other thing our customers love is when it comes to deploying data-driven apps. When you do it on a converged database, it's much simpler because it is that standard data platform. So you're not having to manage multiple independent single-purpose databases. You're not having to implement the security and the high availability policies, across a bunch of different diverse platforms. All of that can be done much simpler with a converged database because the DBA team, of course, is going to just use that standard set of tools to manage, monitor, and secure those systems. You know, thank you for that. You know, it's interesting. You talk about simplification and you are in Juan's organization, so you have a big focus on mission critical. And so one of the things that I think is often overlooked, what we talk about all the time, is recovery. And if things are simpler, recovery is faster and easier. And so it's kind of the hallmark of Oracle. It's like the gold standard of the toughest apps, the most mission critical apps. But I wanted to get to the cloud, Maria. So because everything is going to the cloud, right? It is, you know, not all workloads are going to the cloud, but everybody's talking about the cloud. Everybody has cloud-first mentality. And so, yes, it's a hybrid world. But the natural next question is, how do you think the cloud fits into this world of data-driven apps? I think just like any app that you're developing, the cloud helps to accelerate that development and, of course, the deployment of these data-driven applications. Because if you think about it, the developer is instantly able to provision a converged database that Oracle will automatically manage and look after for them. But what's great about doing something like that if you use our autonomous database service is that it comes in different flavors. So you can get autonomous transaction processing, data warehousing, or autonomous JSON, so that the developer is going to get a database that's been optimized for their specific use case, whatever they're trying to solve. And it's also going to contain all of that great functionality and capabilities that we've been talking about. So what that really means to the developer, though, is as the project evolves, and inevitably the business needs change a little, there's no need to panic when one of those changes comes in because your converged database or your autonomous database has all of those additional capabilities. So you can simply utilize those to be able to address those evolving changes in the project, because let's face it, none of us normally know exactly what we need to build right at the very beginning. And on top of that, they also kind of get a built-in buddy in the cloud, especially in the autonomous database. And that buddy comes in the form of built-in workload optimizations. So with the autonomous database, we do things like automatic indexing, where we're using machine learning to be that buddy for the developer. So what it'll do is it'll monitor the workload and see what kind of queries are being run on that system, and then it will actually determine if there are indexes that should be built to help improve the performance of that application. And not only does it build those indexes, but it verifies that they help improve the performance before publishing it to the application. So by the time the developer is finished with that app and it's ready to be deployed, it's actually also been optimized by the developer's buddy, the Oracle Autonomous Database. So it's a really nice helping hand for developers when they're building any app, especially data-driven apps. I like how you sort of gave us the truth here, is you don't always know where you're going when you're building an app. It's like, if it goes from building it and they will come to start building it and we'll figure out where it's going to go with Agile, that's kind of how it works. But so I wonder, can you give some examples of maybe customers or maybe genericize them if you need to. Data-driven apps in the cloud where customers were able to drive more efficiency, where the cloud buddy allowed the customers to do more with less. No, we have tons of these, but I'll try and keep it to just a couple. One that comes to mind straight away is Retrace. These folks built a blockchain app in the Oracle Cloud that allows manufacturers to actually share the supply chain with the consumer. So the consumer can see exactly who made their product using what raw materials, where they were sourced from, how it was done. All of that is visible to the consumer. And in order to be able to share that, they had to work on a very diverse set of data. So they had everything from JSON documents to images as well as your traditional transactions in there. And they store all of that information inside the Oracle Autonomous Database. They were able to build their app and deploy it on the cloud. And they were able to do all of that very, very quickly. So that ability to work on multiple different data types in the single database really helped them build that product and get it to market in a very short amount of time. Another customer that's doing something really, really interesting is MindSense. So these guys operate the largest minds in Canada, Chile and Peru. But what they do is they put these x-ray devices on the massive mechanical shovels that are at the cove or at the mine face. And what that does is it senses the contents of the buckets inside these mining machines. And it's looking at that content to see how it can optimize the processing of the ore inside in that bucket. So they're looking to minimize the amount of power and water that it's gonna take to process that. And also, of course, minimize the amount of waste that's gonna come out of that project. So all of that sensor data is sent into an autonomous database where it's gonna be processed by a whole host of different users. So everything from the mine engineers to the geoscientists to even their own data scientists utilize that data to drive their business forward. And what I love about these guys is they're not happy with building just one app. MindSense actually use our built-in low-code development environment, Apex, that comes as part of the autonomous database. And they actually produce applications constantly for different aspects of their business using that technology. And it's actually able to accelerate those new apps to the business. It takes them now just a couple of days or weeks to produce an app instead of months or years to build those new apps. Great, thank you for that, Maria. Gerald, I'm gonna push you again. So I set up front and talked about microservices and the cloud and containers and anybody in the developer space follows that very closely. But some of the things that we've been talking about here, people might look at that and say, well, they're kind of antithetical to microservices. This is Oracle's monolithic approach. But when you think about the benefits of microservices, people want freedom of choice, technology choice, seen as a big advantage of microservices and containers. How do you address such an argument? Yeah, that's an excellent question. I get that quite often. You know, the microservices architecture in general, as I said before, right? Architecture, Linux distributions, et cetera. It's kind of always a bit of like, there's an academic approach and there's a pragmatic approach. And when you look at the microservices, the original definitions that came up in the early 2010s, you know, they actually never said that each microservice has to have a database. And they also never said that if a microservice has a database, you have to use a different technology for each microservice. Just like they never said you have to write a microservice in a different programming language, right? So where I'm going with this is like, yes, you know, sometimes when you look at, you know, some vendors out there, some niche players, they push this message or they jump on this academic approach of like each microservice has the best tool at hand, right? Use a different database for your purpose, et cetera. Which almost often comes across like as, you know, we want to stay part of the conversation. Nothing stops a developer from, you know, using a multiple database for the microservice and just using that as a document store, right? Or just using that as a relational database. And, you know, sometimes, I mean, it was actually something that happened that was really interesting yesterday. I don't know whether you followed that day or not, but Facebook had an outage yesterday, right? And Facebook is one of those companies that are some of the silly convales, you know, know how to do microservices companies. And when you read through the outage, well, what happened, right? Some unfortunate logical error with configurations and so forth that took a database cluster down. So, you know, there you have it where you go like, well, maybe not every microservice is actually, in fact, you know, talking to its own database or its own special purpose database. I think there, you know, what the industry should be focusing much more on this argument of which technology to use was the right tool for a job is more to ask themselves what business problem actually are we trying to solve? And therefore, what's the right approach and the right technology for this? And so therefore, just as said before, you know, multi-model databases, they do have strong benefits, they have many built-in functionalities that are already there and they allow you to reduce this complexity of having to know many different technologies, right? And so it's not only to store different data models, either, you know, treat a multi-model database as a JSON document store or as a relational database, right? Most databases are multi-models since 20 plus years, but it's also actually being able to, perhaps if you store the data together, you can perhaps actually derive additional value for somebody else, perhaps not for your application, but like, for example, if you were to use Oracle database, you can actually write queries on top of all of the data. It doesn't really matter for a query engine, whether it's the data is formatted in JSON or the data is formatted in rows and columns, you can just run a query over it. And that's actually very powerful for those guys that have to, you know, get the reporting done the end of the day, the end of the week or for those guys that are the data scientists that want to figure out, you know, which product performed really well or can we tweak something here and there? When you look into that space, you still see a huge divergence between the guys that put data in, kind of the old to P-style and the guys that try to derive new insights and there's still a lot of ETL going around and, you know, we have big data technologies that some of them come and went and some of them came and are still around like Apache Spark, which is still like a SQL engine on top of any of your data, kind of going back to the same concept. And so I would say that, you know, for developers when we look at microservices, it's like, first of all, is the argument you're making because the vendor, the technology you want to use tells you this argument or, you know, you kind of want to have an argument to use a specific technology or is it really more because it is the best technology, the best use for this given use case, for this given application that you have? And if so, there's of course also nothing wrong to use a single purpose technology either, right? Yeah, I mean, whenever I talk about Oracle, I always come back to the most important applications the mission critical is very difficult to architect databases with microservices and containers. You have to be really, really careful. And so, and again, it comes back to what we were talking before about with Maria, the complexity and the recovery. But Gerald, I want to stay with you for a minute. So there's other data management technologies popping out there. I mean, I've seen some people saying, okay, just leave the data in an S3 bucket. We can query that and we got some magic sauce to do that. And so, why are you optimistic about traditional database technology going forward? I would say because of the history of databases. So one thing that once struck me, when I came to Oracle and got to meet great people like Juan Luis and Andy Mendelsohn who were here for a long, long time, I come to realization that relational databases are around for about 45 years now. And I was like, I'm too young to have been around then, right? So it's like, I was like, what else was around 45 years, right? It's like, well, like just a tech stack that we have today, it's like, how does this look like? Well, Linux only came out in 93. Well, databases pre-did Linux a lot, right? And then as I started digging, I saw a lot of technologies come and go, right? And you mentioned before like the technologies, the data management systems that we had, the camera come and went like the column of databases or XML databases, object databases. And even before relational databases, before Cod gave us the relational model, there were apparently these networks towards network databases, which to some extent look very similar to JSON document stores and storing data in a hierarchical format. And when you then start actually reading the Cod paper and diving a little bit more into the relational model, that's I think one important crux in there that most of the industry keeps forgetting or it hasn't been around yet to even know. And that is that when Cod created the relational model, he actually focused not so much on the application, putting the data in, but on future users and applications still being able to making sense out of the data, right? And that's kind of like I said before we had those network models, we had XML databases, you have JSON documents, JSON document stores. And the one thing that they all have along with it is like the application that puts the data in decides the structure of the data. And that's all well and good if you are that application or the developer writing that application. It can become really tricky when 10 years later you still wanna look at that data and the application of the developer is no longer around, then you go like, what does this all mean, right? Where is the structure defined? What is this attribute? What does it mean? How does it correlate to others? And the one thing that people tend to forget is that it's actually the data that's here to stay, not so much the applications, but it's like ideally every company wants to store every single byte of data that they have because there might be future value in it. Economically, it may not make sense. That's now much more feasible than just years ago. But if you could, why wouldn't you wanna store all your data, right? And sometimes you actually have to store the data for seven years or whatever because the laws require you to. And so coming back then in like 10 years from now and looking at the data and going like making sense out of the data can actually become a lot more difficult and a lot more challenging than having to first figure out in how we store this data for general use. And that kind of was what the relation model was all about. We decompose the data structures into tables and columns with relationships amongst each other. So therefore, between each other, so that therefore if somebody wants to, a typical example would be, well, you store some purchases from your web store, right? There's a customer attribute in it. There's some credit card payment information in it. There's some product information in what the customer bought. Well, in the relational model, if you just wanna figure out which products were sold on a given day or week, you just would query the payment and products table to get the sense out of it. You don't need to touch the customer and so forth. And with the hierarchical model, you have to first sit down and understand how is this structure? What is the customer? Where is the payment? You notice the document start with the payment as it starts with the customer in a way to find this information. And then in the very early days, those databases even struggled to then not having to scan all the documents to get the data out. So coming back to your question a bit, apologize for going on here, but it's like relational databases have been around for 45 years. I actually argue it's one of the most successful software technologies that we have out there when you look in the overall industry, right? 45 years is like, in IT terms, it's like I'm a star being born to going supernova. You have said it before, like many technologies coming and went, right? And just one other more really interesting example, by the way, is Hadoop and HDFS, right? That kind of gave us this additional promise of like, you know, the 2010s, like 2012, 13, the hype of Hadoop and so forth and MapReduce and HDFS. And people are like, just let's just put everything into HDFS and worry about the data later, right? And we can query it and MapReduce it and whatever, right? We are customers actually coming to us. They were like, great, we have half a petabyte of data in HDFS cluster and we have no clue what's stored in there. How do we figure this out, right? What are we gonna do now? Now you had a big data cleansing problem. And so I think that is why databases and also data modeling is something that will not go away anytime soon. And I think databases and database technologies are here for quite a while to stay because many of those other people, they don't think about what's happening to the data five years from now, right? Many of the niche players also and also frankly, even Amazon, following with the single purpose thing is like just use the right tool for the job for your application, right? Just put in the data there the way you want it. It's like, okay, so you use technologies all over the place and then five years from now you have your data fragmented everywhere in different formats and inconsistencies and, and, and those are usually when you come back to this data-driven business critical business decision applications, the worst case scenario you can have, right? Because now you need an army of people to actually do data cleansing and there's not a coincidence that data science has become very, very popular in the last recent years as we kind of went on with this proliferation of different database or data management technologies. Some of those are not even database. But I think I leave it at that. It's an interesting talk track because you're right. I mean, no schema on right was alluring but it definitely created some problems. It also created an entire, you know, you reference the hyper-specialized roles and the data cleansing component and maybe technology will eventually solve that problem but it hasn't, at least up until now. Okay, last question Maria. Maybe you could, you could start off and Gerald if you got want to chime in as well that'd be great. I mean, it's, it's interesting to watch this industry when Oracle sort of won the, the top database mantle. I mean, I watched it. I saw you, it was, remember it was in Formix and it was course DB2 and of course Microsoft it's got to give them credit with SQL server but Oracle won the database wars. And then everything got kind of quiet for a while. Database was sort of boring and then it exploded, you know, all the, you know not only SQL and the key value stores and the cloud databases and this is really a hot area now. And when, you know, when we looked at Oracle we said, okay, Oracle, it's all about Oracle database but we've seen the kind of resurgence in MySQL which everybody thought, you know once Oracle bought son, you were going to kill MySQL but now we see you investing in a heat wave times 10. We talked about in memory databases before. So where do those fit in Maria in the grand scheme? How should we think about Oracle's database portfolio? So there's lots of places where you'd use those different things because, you know, just like any other industry there are going to be new and boutique use cases that are going to benefit from a more specialized product or a single purpose product. So good examples off the top of my head of the kind of systems that would benefit from that would be things like a stock exchange system or a telephone exchange system. Both of those are latency critical transaction processing applications where they need microsecond response times and that's going to exceed perhaps what you might normally get or deploy with a converge database. And so Oracle's times 10 database, our in memory database is perfect for those kind of applications. But there's also a host of MySQL applications out there today and you said it yourself their day heat wave is a great place to provision and deploy those kinds of applications because it's going to run a hundred times faster than AWS Aurora. So, you know, there really is a place in the market and in our customers systems and the needs they have for all of these different members of our database family here at Oracle. Oh, the internet is basically running in the lamp stack. So let's see MySQL going away. All right, Gerald, we'll give you the final word bring us home. Thank you very much. Yeah, I mean, as Maria said, right? I think it comes back to what we discussed before this obviously still needs for special technologies or different technologies in a relational database or multi-model database. Oracle has actually many more databases that people may first think of not only the three that we have already mentioned, right? But there's even S-Base and Oracle's NoSQL database. And you know, on a high level, Oracle is a data management company, right? And we want to give our customers the best tools and the best technology to manage all of their data. Right, and therefore there has to be a need or there should be a part of the business that also focuses on this highly specialized systems and those highly specialized technologies that address those use cases. I think it makes perfect sense. It's like, you know, when the customer comes to Oracle, they're not only getting this, yeah, take this one product, you know, and if you don't like it, your problem, but actually you have choice, right? And choice allows you to make a decision based on what's best for you and not necessarily best for the vendor you're talking to. Well, guys, really appreciate your time today and your insights, Maria, Gerald. Thanks so much for coming to theCUBE. Thank you very much for having us. And thanks for watching this CUBE Conversations, this is Dave Vellante and we'll see you next time.