 Welcome back to the Big Apple, everybody. The Cube's continuous coverage here of MongoDB World 2022. We're at the new Javits Center. It's quite nice. It was built during the pandemic, I believe, on top of a former bus terminal, I'm told, by our next guest, Tony Bear, who's the principal at DB Insight, data and database expert, long time analyst. Tony, good to see you. Thanks for coming on. Good to see you face to face. Yeah, and welcome to New York. Yeah, right. New York is open for business. So yeah, and actually, it's interesting, we've been doing a lot of these events lately. And especially the ones in Vegas, it's the first time everybody's been out face to face, not so much here. People have been out and about, a lot of masks in New York City. But it's good, and this new venue is fantastic. Much nicer than the old Javits. Yeah, and I would say maybe 3,000 people here. Yeah, probably. But I think like most conferences right now are kind of, they're going through like a slow ramp up and like, for instance, Sapphire was had maybe about one-third their normal turnout. So I think that you're seeing like one-third to one-half seems to be the norm right now. So still figuring out how and where we're going to get back to. Yeah, I think that's about right. But I do think that in most of the cases that we've seen, it's exceeded people's expectations. Sure. It's been, anyway. Sure. Let's talk about Mongo. It's a very interesting company. You know, we've kind of been watching their progression from just sort of document database and all the features and functions they're adding. You just published a piece this morning in VentureBeat. It's time for Mongo to get into analytics, you know, one of your favorite topics. Well, can they expand to analytics? They seem to be doing that. Let's dig into it. Well, they've been taking slow, they've been taking baby steps. And there's good reason for that because first thing is an operational database. The last thing you want to do is slow it down with very complex analytics. On the other hand, there's huge value to be had if you could turn, let's say, an operational database or a transaction database into a smart transaction database. In other words, for instance, let's say if you're doing an e-commerce site and a customer has made an order that's basically been out of the norm whether it be good or bad, it would be nice basically if at that point you could then have a next best action, which is where analytics comes in. But it's a very lightweight form of analytics. It's not going to, actually, I think probably the best metaphor for this is real-time credit scoring. It's not that they're doing your scoring you in real-time. It's that the model has been computed offline so that when you come on in real-time, it can make a smart decision. Got it. Okay, so I think it was your article where I wrote down some examples of operational use cases. Patient data, there's certainly retail. We had Forbes on earlier, obviously. So very wide range of use cases for operational. Now will Mongo essentially in your view, is it positioned to replace traditional RDBMS? Well, okay, that's a long, that's a much, sort of a loaded question, but no. That's a very loaded question. I think that for certain cases, I think it will replace RDBMS, but I still, I mean, where I depart from Mongo is I do not believe that they are going to replace all RDBMSs. I think for instance, like when you're doing financial transactions, the world has been used to columns and rows and tables. That's, it's a natural form for something that's very structured like that. On the other hand, when you take a look, let's say IoT data, or you're taking a look at home listings, that tends to more naturally represent itself as documents. And so there's a, so it's kind of like documents are the way that let's say you normally see the world. Relational is the way that you would structure the world. Yeah, okay, I like that. So but I mean, in the early days obviously, and even to this day, it's like the target for Mongo has been Oracle, right? And so, and then, you know, you talk to a lot of Oracle customers as do I, and they're running the most mission critical applications in the world. It's like banking and financial and so many. And you know, they've kind of carved out that space, but should we be rethinking the definition of mission critical? Is that changing? Well, number one, I think what we've traditionally associated mission critical systems with is our financial transaction systems and to a lesser, and also let's say systems that schedule operations. But the fact is there are many forms of operations where for instance, let's say you're in a social network, do you need to have that very latest update or you know, basically can you go off, let's say like, you know, a server that's eventually consistent? In other words, do you absolutely have, you know, it's just like when you go on Twitter, do you naturally see all the latest tweets? It's not, the system's not going to crash for that reason. Whereas let's say if you're doing it, you know, let's say in ATM, banking ATM system, that system better be current. So I think there's a delineation. The fact is that in a social network, arguably, that operational system is mission critical, but it's mission critical in a different way from a, you know, from let's say a banking system. So coming back to this idea of this hybrid, I think, you know, I think Gartner calls it H-Tap Hybrid Transactional Analytics. The name's changed by the minute. Right, I mean you mentioned that in your article, but basically it's bringing analytics to transactions, bringing those tools together. And you're saying with Mongo, it's lightweight. You used two other examples in your article, MySQL, Heatwave, I think you had a Google example as well. Those are, you're saying, much heavier analytics, is that correct? Well put it this way, I think they're, because they're coming from a relational background and because they also are coming from companies that already have, you know, analytic database or data warehouses, if you will, that their analytic capabilities are going to be much more fully rounded than what Mongo has at this point. It's not a criticism of MongoDB per se. Is that by design though? Or is that a function of maturity? I think it's function of maturity. I mean, look, to a certain extent, it's also a function of design in terms of that the document model is a little, it's not impossible to basically model it for analytics, but it takes more transformation to decide which, you know, let's say field in that document is going to be a column. Now, the big thing about some of these other, these hybrid systems is eliminating the need for two databases, right? Eliminating the need for, you know, complex ETL. Is that a value proposition that will emerge with Mongo in your view? You know, I mean, put it this way. I think that if you take a look at how they've, how Mongo is basically has added more function to its operations. I'm going to talk about analytics here, for instance, adding streaming, you know, adding search, adding time series. That's a matter of like where they've eliminated the need to do, you know, transformation, ETL. But that's not for analytics, per se. For analytics, I think through, you know, I mean, through replication, there's still going to be some transformation in terms of turning, let's say, data that's formed in a document into something that's represented by columns. There is a form of transformation. You know, so that said, and Mongo's already, you know, it has some, you know, nascent capability there, but it's all, but this is still like at a Rev 1.0 level, you know, I expect a lot more of it. So, you know how Amazon says in the fullness of time, all workloads will be in the cloud, and we could certainly debate that. What do we mean by cloud? So, but there's a sort of analog for Mongo that I'll ask you in the fullness of time, will Mongo be in a position to replace data warehouses or data lakes or, and we know the answer is no. So that's the course. But are these two worlds on a quasi-collision course? I think they're more on a convergence course than a collision course. Because number one, as I said, the first principle in operational database is the last thing you want to do is slow it down. And to do all this complex modeling that let's say that you would do in a data bricks or a very complex analytics that you would do in a snowflake, that is going to get, you know, no matter how much you partition the load, you know, in Atlas, and yes, you can have separate nodes, the fact is you really do not want to burden the operational database with that. And that's not what it's meant for. But what it is meant for is, you know, can it make a smart decision on the spot? You know, it was kind of like close the loop on that. And so therefore there's a form of lightweight analytic that you can perform in there. And actually, that's also the same principle, you know, on which let's say for instance, you know, MySQL, Heatwave, and AlloyDB are based on. They're not, they're predicated on. They're not meant to replace, you know, whether it be Exadata or BigQuery. The idea there is to do more of the lightweight stuff, you know, and keep the database, you know, keep the operations operating. And, but from a practitioner's standpoint, I can and should isolate your saying that node, right? That's what they'll do. How does that affect? Because my understanding is that the Mongo, specifically, but I think document databases generally will have a primary node, and then you can set up secondary nodes, which then you have to think about availability. But with that analytic node be sort of fenced off, is that part of the- Well, that's actually what they've already, I mean, they already laid the groundwork for it last year by saying that you can set up separate nodes and dedicate them to analytics. And what they've added- As a primary- Right, yes, yes. For analytics. And what they've added, what they are adding this year is the fact to say like that separate node does not have to be the same instance class, you know, as the- What does that mean? Explain that. In other words, it's a, you know, you could have, you know, for instance, you could have a node for operations that's basically very eye-opson-tensive. Whereas you could have a node, let's say, for analytics that might be more compute-intensive or more heavily configured with memory, per se. And so the idea here is you can tail in a node to the workload. So that's, you know, what they're saying with, you know, and I forget what they're calling it, but the idea that you can have a different type, you can specify different type of node, different type of instance for the analytic node, I think is, you know, is a major step forward. And that's enabled by the cloud and architecture, for sure. Of course, yes, I mean, we're separating compute from data as the starter. And so, yeah, then at that point, you can then start to, you know, to go less vanilla. I think the, you know, the, you know, the, I guess the fruition of this is going to be when they say, okay, you can run your, let's say your operational nodes, you know, dedicated, but we'll let you run your analytic nodes serverless. Can't do it yet, but I've got to believe that's on the roadmap. Yeah, so SQL brings a lot of overhead. Let's see, again, MQL, but now square this circle for me, because now you've got Mongo talking SQL. They had to start doing that sometime. I mean, and I, and it's been a critique I've had from them from the, from the get go, which is that I understand that you're looking at this as an alternative to SQL, and that's perfectly valid. But don't deny the validity of SQL or the reason why we, you know, we need it. The fact is that you have, okay, the numbers, you know, according to the Tiobindex JavaScript is the seventh most popular language. Well, SQL follows closely behind at the ninth most popular language. You don't want to, and the fact is those people exist in the enterprise. And they're disproportionately concentrated in analytics. I mean, it's getting a little less, though, now that we're seeing, like, you know, basically, you know, Python, the programmatic, but still, you know, a lot of SQL expertise there. It does not, it makes no sense for Mongo to ignore or to overlook that audience. I think now they're, you know, they're taking baby steps to start, you know, reaching out to them. It's interesting, you see it going both ways. See Oracle announces a MongoDB API. Yes, yes. I mean, this is convergence, you called it. Yes. I love collisions. I know, it's like, because you thrive on drama and I thrive on, can't we all love each other? But, you know, actually, but the thing is, actually, I wrote about this, I forget when, I think it was like 2014 or 2016. It's when we, I was noticing basically, you know, the rise of all these specialized databases and probably Amazon, you know, AWS is probably the best exemplar of that. Like, you've got 15 or 16 or however number of databases and they're all dedicated purpose. But I also was, you know, basically saw that inevitably there was going to be some overlap. It's not that all databases were going to become one and the same, we're going to become back into like, you know, into a Pangea continent or something like that. But that, you're going to have a relational database that can do JSON and a document database that can do relational. I mean, you know, to me that's a no-brainer. So I asked Andy Jassy one time, I'd love to get your take on this, about those, you know, multiple data stores at the time, they probably had a thousand. I think they're probably up to 15 now, different APIs, different primitives, et cetera. And his response, I said, why don't you make it easier for customers and maybe build an abstraction or converge these. And he said, well, it's by design. I mean, what if you buy this and what your thoughts are? Cause I, you know, he's a pretty straight shooter. By design, because it allows us, as the market moves, we can move with it. And if we, if we give developers access to those low level primitives and APIs, then they can move with, at market speed. And so that, again, by design. Now, we heard certainly Mongo poo-pooing that today. They didn't mention they didn't call out Amazon. Oracle has no compunction about specifically calling out Amazon, they do it all the time. What do you make of that? Can't Amazon have its cake and eat it too? In other words, extend some of the functionality of those specific databases without going to the Swiss army knife. Don't put this way, you kind of tapped and you're sort of like, you know, killing me softly with your song there. Which is that, you know, I was actually kind of went on a rant about this actually in, you know, my year ahead sort of predictions. And I said, look, cloud folks, it's great that you're making individual SAS, you know, products easy to use. But now that I have to mix and match SAS products, you know, the burden of integration is on my shoulders. Start making my life easier. I think a good example of this would be, you know, for instance, you could take something like, you know, let's say like a Google BigQuery. There's no reason why I can't have a piece of that that might be paired, say, with Spanner or something like that. The idea being is that if we're all working off a common storage, you know, in cloud native, we can separate the computer engines. It means that we can use the right engine for the right part of the task. And the thing is that maybe, you know, myself as a consumer, I should not have to be choosing between BigQuery and Spanner. But the thing is I should be able to say, look, I want to, you know, globally distribute database, but I also want to do some analytics. And therefore behind the scenes, you know, new microservices, it could connect the two. Wouldn't Microsoft Synapse be an example of doing that? It should be an example. I wish I would love to hear more from Microsoft about this. They've been radio silent for about the past two or three years in data. You hardly hear about it. Synapse was actually one of the ideas I had in mind. Now keep in mind that with Synapse, you're not talking about, let's say, I mean, it's obviously a SQL data warehouse. It's not pure Spark. It's basically, it was their curated version of Spark. But that's fine. But again, I would love to hear Microsoft talk more about that. They've been very quiet. Yeah, I mean, the intent is there to simplify it. Yes, exactly. And create an abstraction. Exactly. But yeah, they have been quiet about it. Yeah, yeah. You would expect that maybe they're still trying to figure it out. So what's your prognosis from Mongo? I mean, since this company IPO, usually I tell, and I tell everybody this, especially my kids, don't buy a stock at IPO. You'll always get a better chance at a cheaper price to buy it. And even though that was true with Mongo, you didn't have a big window, like you did, for instance, with Facebook. Certainly, that's been the case with Snowflake and Alibaba. I mean, I'd name a zillion style. It was almost universal. But since that first few months period, this company has been on a roll. Right. And it obviously has been some volatility, but the execution has been outstanding. No question about that. I mean, the thing is, look, what I, and I'm just going to talk on the product side, not on the sales side, but on the product side, from the get-go, they made a product that was easy for developers. Whereas, let's say, I mean, someone's giving an example, for instance, Cosmos DB, where to do certain operations, they had to go through multiple services, including Azure portal, with Atlas, it's all within Atlas. So they've really, it's been kind of like design thinking from the start. Initially, with the core MongoDB, you know, the on-premise, but this predates Atlas. I mean, part of it was that they were coming with a language that developers knew was just JavaScript, a construct that they knew which was JSON. So they started with that home-court advantage, but they weren't the only ones doing that, but they did it with tooling that was very intuitive to developers, that met developers where they lived. And what I give them, you know, an additional credit for is that when they went to the cloud, and it wasn't an immediate thing, Atlas was not an overnight success, but they employed that same design thinking to Atlas, they made Atlas a good cloud experience. They didn't just do a lift and shift to the cloud. And so that's why today, basically like five or six years later, Atlas is most of their business. Yeah, that's what, 60% of the business now, and Dave on the earning scholar, maybe it wasn't Dave, somebody else in response to the question said, yeah, ultimately this is the future, maybe 90% of the business, I'm not going to predict when. So my question is, okay, so let's call that the midterm. Midterm, Atlas is going to be 90% of the business with some exceptions that people just won't move to the cloud. What's next, is the edge a new opportunity? Is Mongo architecturally suited for the, I mean, it's certainly suited for the home depot store, you know, at the edge. If you consider that edge, which I guess it is form of edge, but how about the far edge? EVs, cell towers, you know, real time AI inferencing. What's the requirement there? Can Mongo fit there? Any thoughts on that? I think the AI and the inferencing stuff is interesting. It's something which really Mongo has not tackled yet. I think we take the same principle, which is the lightweight stuff. In other words, you'll let's say do, let's say a classification or a prediction or some sort of prescriptive action. In other words, where you're not doing some convolutional neural networking and trying to do like, you know, text the voice or vice versa, so you're not trying to do all that really fancy stuff. I think that, you know, if you're keeping it sent, you know, kind of like the Kiss principle, I think that's very much within Mongo's future. I think with the realm, they have, they basically have the infrastructure to go out to the edge. I think with the fact that they've embraced GraphQL has also made them a lot more extensible. So I think they certainly do have, you know, I do see the edges being, you know, in their pathway. I do see basically lightweight analytics and lightweight, let's say machine learning, definitely in their future. And they would, would you agree that they're in a better position to tap that opportunity than say a snowflake or an oracle. Now, maybe M&A can change that. R&D can maybe change that, but fundamentally from an architectural standpoint, are they in a better position? Good question. I think that Mongo, snowflake by virtue of the fact that, I mean, that they've been all, you know, all cloud start off with, I think makes it more difficult, not impossible to move out to the edge. But it means that, and I said the role is starting to make some tentative moves in that direction. I'm looking forward to next week to, you know, seeing what, you know, hearing what we're going to, what they're going to be saying about that. But I think, you know, to answer your question directly, I'd say like right now, I'd say Mongo probably has a head start there. I'm losing track of time. I could go forever with you, Tony Pear, DB Insight with tons of insights. Thanks so much for coming back. It's only one insight, DB Insight. Dave, good to see you again. All right, good to see you. Thank you. Okay, keep it right there. We're right back at the Java Center, Mongo DB World 2022. You're watching theCUBE.