 Oracle continues to pursue a multi-mode converged database strategy. The premise of this all in one approach is to make life easier for practitioners and developers. And the most recent example is the Oracle Database API from MongoDB, which is announced today. Now, Oracle, they're not the first to come out with a MongoDB compatible API, but Oracle hopes to use its autonomous database as a differentiator and further build a moat around OCI, Oracle Cloud Infrastructure. And with us to talk about Oracle's MongoDB compatible API is Gerald Vensel, who's Distinguished Product Manager at Oracle. Gerald was a guest along with Maria Colgan on theCUBE a while back, and we talked about Oracle's Converged Database and the kind of Swiss Army Knife strategy, I called it, of databases. This is dramatically different. It's an approach that we see at the opposite end of the spectrum, for instance, from AWS, who for example goes after the world of developers with a different database for every use case. So kind of picking up from there, Gerald. I wonder if you could talk about how this new MongoDB API adds to your converged model and the whole strategy there. Where's it fit? Yeah, thank you very much, Dave. And by the way, thanks for having me on theCUBE again. Pleasure to be here. So essentially the MongoDB API or the compatibility that we've used with this API is a continuation of the Converged Database story, as you said before, right? Which is essentially bringing the many features of the many single-purpose databases that people often like and use together into one technology so that everybody can benefit from it. So as such, this is just a continuation that we have from so many other APIs or standards that we support. It's a long time we're ready, of course, to SQL because we're a relational database from the get-go but also other standards like GraphQL, Sparkle, et cetera that we have and the MongoDB API is now essentially just the next step forward to give the developers this API that they've gotten to love and use. I wonder if you could talk about from the developer angle. What do they get out of it? Obviously you're appealing to the Mongo developers out there but you've got this Mongo compatible API. You're touting the autonomous database on OCI. Why aren't they just going to use MongoDB Atlas on whatever cloud, Azure or AWS or Google Cloud Platform? That's a very good question. We believe that the majority of developers want to just worry about their application, writing the application and not so much about the database backend that they're using especially in cloud with cloud services. The reason why developers choose these services is so that they don't have to manage them. Now, autonomous database brings many top notch advanced capabilities to database cloud services. We firmly believe that autonomous database is essentially the next generation of cloud services with all the self-driving features built in and MongoDB developers like what developers writing applications against the MongoDB API should not have to hold out on these capabilities either. It's like no developer likes to tune the database, no developer likes to take a downtime when they have to rescale their database to accommodate a bigger workload. This is really where we see the benefit here. So for the developer, ideally nothing will change. You have a MongoDB compatible API so they can keep on using the tools, they can build the applications the way that they do but the benefit from the best cloud database service out there not having to worry about any of these backend things anymore that even MongoDB Atlas has a lot of shortcomings still today as we find. Right, of course, this is always a moving target, right? The technology business, that's why we love it. So everybody's moving fast and investing and shucking and jiving but I want to ask you about, well, by the way, so you're hiding the underlying complexity. That's really the big takeaway there. So that's huge for developers but take, I was talking before about the Amazon's approach, right tool for the right job, you got DocumentDB, you got Microsoft with Cosmos, they compete with Mongo and they've been doing so for some time. How does Oracle's API from Mongo different from those offerings and how are you going to attract their users to, for instance, your JSON offering? Yeah, so first of all, we have to kind of separate slightly DocumentDB and AWS and CosmosDB and I'm sure they have slightly different approaches there. DocumentDB essentially is a document store owned by and built by AWS, nothing different to MongoDB. It's a head-to-head comparison, it's like use my document store versus the other document stores. You don't get any of the benefits of a converged database. If you ever want to do a different data model, run an analytics server, et cetera, you still have to use the many other services that AWS provides you to, you cannot all do it into one database. Now, CosmosDB, it's more interesting because they claim to be a multi-model database and I say claim because what we understand as multi-model database is different to what they understand as multi-model database and also one of the reasons why we start differentiating with converged database. So what we mean is you should be able to, regardless what data format you want to store in the database, leverage all the functionality of the database over that data format with no trade-offs. CosmosDB, when you look at it, it essentially gives you a mode of operation. When you connect as the application or the user, you have to decide at connection time how this database should be treated. Should it be a document store? Should it be a graph store? Should it be a relational store? Once you make that choice, you are locked into that as long as you established that connection, right? So it's like, if you say, I want a document store, all you get is a document store. There's no way for you to cross-analyze with the relational data sitting in the same service. There's no way for you to break these boundaries. If you ever want to add some graph data and graph analytics, you essentially have to disconnect and now treat it as a graph store. So you get multiple data models in it, but really you still get one trick pony the moment you connect to it that you have to choose to. And that is where we see a huge differentiation again with our converge database because we essentially say, look, one database cloud service on Oracle Cloud where it allows you to do anything if you wish to do so. You can start as a document store if you wish to do so. If you want to write some SQL queries on top, you can do so. If you want to add some graph data, you can do so, right? But there's no way for you to have to rewrite your application, use different libraries and frameworks now to connect the central central. Got it, thank you for that. Do you have any data when you talk to customers? I'm interested in the diversity of deployments. For instance, how many customers are using more than one data model? For instance, do JSON users need support for other data types or are they happy to stay kind of in their own little sandbox? Do you have any data on that? Yeah, so what we see from the maturity of our customers, there is no such thing as one data model fits everything, right? And it's like, we're there again, we have to differentiate the developer that builds a certain microservice that makes happy to stay in the JSON world or relational world or the company that's trying to derive value from the data, right? Which is like, the relational model has not gone away since 40 years of existence, it's still kicking strong, it's still really good at what it does. The JSON data model is really good at what it does. The graph model is really good at what it does. But all these models have been built for different purposes, right? Try to do graph analytics on relational or JSON data. It's like, it's really tricky, but that's why you use a graph model to begin with, right? Try to shield yourself from the organization of the data, how it's structured. That's really easy in the relational world, not so much when you get into a document store world. And so what we see for our customers is like, as they accumulate more data, as they have many different applications to run their enterprises, the question always comes back as we have predicted since about six, seven years now, where they say, hey, we have all this different data in different data formats. We wanna bring it all together, analyze it together, get value out of the data together. Right, we have seen a whole trend of big data emerge and disappear to answer that question then quite through the trick. And we are basically now back to where we were in the early 2000s when XML databases have faded away because everybody just allowed you to store XML in the database. Got it. All right, so let's make this real for people. So maybe you could give us some examples. You got this new API from Mongo. You have your multi-model database. How, take a painted picture of how customers are going to benefit in real world use cases. How does it kind of change a customer's world before and after, if you will. Yeah, absolutely. So, you know, the API essentially we have introduced it to a set before you know, make the life of the world at the lives of the developers easier, but also of course to assist our customers with migrations from MongoDB over to Oracle Autonomous Database. One customer that we have, for example, that would have benefited of the API the sample a couple of years ago, two, three years ago. It's one of the largest logistics company on the planet. They track every package that is being sent in JSON documents, right? So every track packages essentially is resembling a JSON document. And they very early on came in with the next question of like, hey, we track all these packages in document and JSON documents. Will be really nice to know actually which packages are stuck, right? Or anywhere where we have to intervene, right? It's like, can we do this, right? Can we analyze just how many packages could stuck didn't get delivered on the end of the day or whatever. And they found this struggle with this question a lot. They found this was really tricky to do back then in that case in MongoDB. So they actually approached Oracle, they came over, they migrated over and they rewrote their applications to accommodate that. And they're happy chasing users in Oracle Database. But if we were having this API already for them, then they wouldn't have had to rewrite the applications or would we often see like worry about the rewriting the application later on, right? Usually in migration use cases, you want to get kind of the migration done, get the data over, be running and then worry about everything else. So this would be one example that they would have greatly benefited to shorten this migration time window. If we had already the MongoDB API back then with compatibility there. Yeah, it's a good use case. I mean, it's one of the most prominent and painful. So anything you can do to help that is key. You know, I remember like the early days of big data, you know, no sequel, of course, was the big thing. There was a lot of confusion. No, people thought was none or not only sequel, which is kind of the more widely accepted interpretation today. But, you know, really it's talking about data that's stored in a non-relational format. So, you know, some people, again, they thought that the sequel was going to fade away and some people probably still believe that. And, you know, we saw the rise of no sequel and document databases. But if I understand it correctly, a premise for your MongoDB API is you really see sequel as a main contributor over MongoDB's document collections for analytics, for example. Can you maybe add some color here? Are you seeing, you know, what are you seeing in terms of resurgence of sequel or the momentum in sequel? Has it ever really waned? What's your take? Yeah, no, it's a very good point, right? So I think there as well, we see to some extent history repeating itself from, you know, this all has been tried beforehand with object databases, XML databases, et cetera. But if we stay with the no sequel databases, I think it speaks at length that every no sequel database that as you're rightfully said, so started with no sequel. And then, well, actually we always meant not only sequel, everybody has introduced a sequel-like engine or interface. The last two actually joined this family is MongoDB now. They have just recently introduced a sequel compatibility for the aggregation pipelines, something where you can put in a sequel statement that essentially will then work with aggregation pipeline. So they all acknowledged that sequel is powerful. For us, this was always clear. Sequel is a declarative language. Some argue it's the only true 4GL language out there, right? You don't have to code how to get the data, but you just ask the question and the rest is done for you. And, you know, we think that as we, you know, basically is has sequel ever diminished? As you said before, if you look out there, sequel has always been in demand, right? Look at the various developer surveys, the various job skills that are asked for a sequel has never gone away, right? Everybody loves and likes and he wants to use sequel. And so, yeah, we don't think this has ever been, you know, going away. It has maybe just been, you know, put in the shadow by some hypes. But again, we had the same discussion in the 2000s with XML databases with the same discussions in the 90s with object databases. And we have just frankly all forgotten about it. You know, I love when you guys come on and let me do my thing. And I can pretty much ask any question I want because, you know, I gotta say, when Oracle starts talking about another company, I know that company is doing well. So I like, I see Mongo in the marketplace and I love that you guys are calling it out and making some moves there. So here's the thing, you guys have a large install base and that can be an advantage, but it can also be a weight in your shoulder, right? These specialized cloud databases, they don't have that legacy. So they can just kind of move freely about less friction. Now, all the cloud database services, they're going to have more and more automation. I mean, I think that's pretty clear and inevitable. And most, if not all of the database vendors, they're going to provide support for these kind of converged data models. You know, however, they choose to do that. They might do it through the ecosystem, like what Snowflake's trying to do, or, you know, bring it in the house themselves. You know, like a watch maker that brings an in-house movement, if you will, right? But it's like death in taxes. You know, you can't avoid it. It's got to happen. That's what customers want. So with all that being said, how do you see the capabilities that you have today with automation and converge capabilities? How do you see that playing out? What's, do you think it gives you, you know, enough of an advantage? You know, obviously it's an advantage, but is it enough of an advantage over the specialized cloud database vendors where there's, you know, clearly a lot of momentum today? Yeah, I mean, you know, honestly, yes, absolutely, right? I mean, we are, with some of these databases, 20 years ahead, right? And I'll give you concrete examples, right? It's like Oracle had transaction support, asset transactions since forever, right? No SQL players all said, oh, we don't need assets transactions, base transactions, it's fine, yada, yada, yada. Longer to be started introducing some transaction support. It comes with some limits, right? Kind of be longer than 60 seconds, kind of touch more than a thousand documents as well, et cetera. They still will have to, you know, do some catching up there. I mean, it took us a while to get there. Let's be honest, right? We have been around for a long time. Same thing now that happened with version five. It's like they started some simple version of multi-version concurrency control that comes along with asset transactions. The interesting part here is like, we've introduced this also in Oracle five, which was somewhere in the 80s before I even started using Oracle database. So there's a lot of catching up to do, right? And then you look at the cloud services as well, there's actually certain, a lot of things that we kind of got and take, we kind of, we Oracle people have taken for granted and we kind of keep forgetting, right? For example, our elastic scale. You want to add one CPU? You add one CPU. Should you take a downtime for that? Absolutely not, right? It's like, this is ridiculous. Why would you, you cannot take a downtime in a 24-7 backend system that runs the world, right? Take any of our customers. If you look at most of these cloud services or you want to reshape, you want to scale your cloud service, that's fine, right? It's just to be under the covers, which has shut everything down. Give you a VM with more CPUs, boot it up again, downtime right there, right? So it's like, there's a lot of these things where we go like, well, you know, we solved this frankly decades ago, that these cloud vendors will run into. And just to add one more point here, right? So it's like one thing that we see with all these migrations happening is exactly in that field, right? It's like people essentially started building on what it's longer to be out of these no SQL databases or cloud databases. And eventually as these systems grow, as they ask more difficult questions, their use cases expand, they find shortcomings, right? Whether it's the scalability, whether it's the security aspects, the functionalities that we have. And this is essentially what drives them back to Oracle. And this is why we see essentially this popularity and not a pendulum swimming towards our direction again, where people actually happily come over and actively come over to us to get their workloads enterprise-grade, if you like. Well, it's true. I mean, I just reported on this recently, the momentum that you guys have in cloud and positive it's because you got the best mission critical database, you're all about maps. I got to tell you a quick story. I was at a Vertica conference one time, I was on stage with Kurt Monash. I don't know if you know Kurt, but he knows this space really well. He's probably forgotten more about database than I'll ever know. But I was kind of busting his chops. You were talking about acid transactions. I'm like, well, with no SQL, who needs acid transactions? Just to poke him. And he was like, are you out of your mind? And he said, okay, it's everybody is going to head in this direction. It turned out it's true. So I got to give him props for that. And so, okay, my last question. If you had a message for, let's say there's a skeptical developer out there that's using MongoDB and Atlas, what would you say to them? I would say, go try it for yourself. If you don't believe us, we have an always free cloud tier out there. You just go to work.com slash cloud slash free. You sign up for an always free tier, spin up an autonomous database. Go try it for yourself. See what's actually possible today, right? Don't just follow your trends on Hack and Use Assets, show rumors that a year out there. Go try it for yourself and see what it's capable of. All right, Gerald. Hey, thanks for coming into my firing line today. I really appreciate your time. Thank you for having me again. Good luck with the announcement. You're very welcome. And thank you for watching this CUBE Conversation. This is Dave Vellante. We'll see you next time.