MongoDB, Inc. (MDB) Earnings Call Transcript & Summary

Okay. We're good. All right. Good afternoon, everybody. Thank you for coming. We are very pleased to have MongoDB up with us next. Michael Gordon is the CEO -- I'm sorry, I almost gave you a promotion there. COO and CFO. Sorry, Dave.

I'll tell that about him later.

Yes, yes. Tell him later, he'll find that funny. Maybe not. But anyhow, just as -- just to point out, they are in their quiet period. They were nice enough to come during their quiet period. But just keep that in mind when we go to the Q&A portion that he's going to refrain from answering questions related to the quarter.

But I guess, so let's take a step back. So this is not a question about your most recent quarter, which you're getting ready to report, but more through the course, the first 3 quarters of the year, right, fiscal year. Did the slope of the spending environment or the pace of the spending environment change at all? Did it come in for those 3 quarters like you would have expected it to? Or did you have any deviations?

Yes. So first of all, thanks for having us. It's great to be here. No, in terms of the spending environment for the first 3 quarters of the year, we didn't notice any perceptible changes. I think it was all very consistent with what we have seen and have been seeing. We've certainly heard reports from others about what they've seen so far that is not something that we've seen any evidence or manifest itself in any of our discussions. I think we're at a fortunate point in that we're generally sort of attacking and winning the new workloads or existing workloads migrating. And so maybe the dynamic is a little bit different for us, but we certainly haven't seen anything like that.

So -- and look, you've got a great audience here. But for some of the people, when they're new to the story, the biggest question you get is, okay, what do I use a NoSQL database form? What do I not use it for? So give people a lay of the land, if you will.

Yes. Sure. We'll take a look at [indiscernible].

And how that maybe has evolved, right? Because it has evolved.

Yes. It has evolved, yes. There's no question, it's definitely evolved. I think that distinction and designation was particularly helpful for industry analysts when new technologies were emerging, and they need some way to sort of help people understand the landscape, some format, again, switch through to the Harvey balls or something just to make their money. But if we just take a step back for those, who are newer to the market, there are a ton of publicly traded database companies, so I wouldn't expect you to -- a single mind. I think about this all day. So from an overall backdrop or context, the database market is $64 billion in 2019 per IDC growing to $97 billion in 2023. So a very large market but with pretty significant growth. Typically, you think of -- or at least I think of larger markets are sort of maybe being more mature, maybe having growth, more characteristic or consistent with GDP as opposed to sort of 9%, 10%, 11% year-over-year growth. And I think what that highlights or what that speaks to is the fundamentally strategic nature of the database market. Not only is it incredibly large, but it's really at the heart of whether you call it app modernization, digital transformation, whatever buzzwords you want to use. We have all these companies who are increasingly talking about competing on the basis of their technology, their software and whether you like to think of software eating the world as your favorite phrase or whether you think about these large industrial companies, talking about how many engineers they have in being an engineering or a technology company. That's really the way that people are competing for customer, driving revenue, driving competitive advantage is on the basis of their applications. And at the heart of every one of those applications is its database. And the scalability and agility and how nimble that database is determines your ability to be competitive in the market. And so that's where we come along as being one of the most successful sort of insurgent, if you will, for this landscape that sort of existed for 4-plus decades dominated by relational databases. And we've been able to come along with a better mousetrap and start to eat away at that.

So when you think of the blurred lines of that $60-odd-billion market going to $90 billion, you've got things like asset compliance now, you've got sharding. It -- is there going to be a difference in 5 years like will we be talking about NoSQL as a separate market?

Yes. Maybe those [indiscernible] is something as a technical reason, too, right? I think what we've done is we've continued to invest in the product, is address the main sort of feature gaps or psychological barriers that they might have to using a modern database. And so you mentioned asset compliance.

You might want to explain [indiscernible]. Yes.

So 2 years ago, close to 2 years ago, we introduced multi-document asset transactions, which were really just the sort of highest forms of data guarantees. And they existed, they were sort of the standard. They're particularly important in a relational database because what you're doing in a relational database is you're spending data across multiple tables, and the reason you're doing that is because storage was very expensive when relational database technology was pioneered. And so you wanted to store that data optimally and efficiently. The way I always try to use an analogy with people, who are not technical is, when you think about -- if you ran a parking garage and you wanted to efficiently store the parking, all the cars when they came in, you would actually disassemble the car and you put steering wheels to steering wheels and tires to tires and fenders to fenders, and you'll be able to cram in many, many more cars. The problem is when someone came to you for their car, it would take a little bit time, a little bit complicated. You have to remember where you put everything. In that same context, the software developer, the app owner, is that parking garage valet, who has to remember where they put all the stuff. It's sort of this taxes overhead. And the reason that existed was because storage is very expensive. As you all know, storage is now incredibly cheap, it's not approaching 0. And so what's expensive is developers, right? And it's that developer productivity that developer mindshare. And so if you can interact with a modern database that speaks and feels like a modern programming language, we're a document-oriented database as opposed to sort of a tabular or relational database that fits very nicely with object-oriented programming languages, which is the dominant programming languages with which developers program today. And so there's not any of this impedance mismatch in terms like how do I build code or how do I write code. And so it's very easy for me. And so that's one of the reasons why MongoDB is incredibly popular to developers.

So if you go back 10 years ago, there was a big opportunity for you, for Mongo to get into applications where people were using a relational database, and it just didn't work. Like it wasn't the right database for what they needed to do. And that has been an opportunity for you guys to kind of reclaim workloads that never kind of should have been in that environment. How has the type of application you're being used for evolved?

Yes. So I think as we've continued to invest in the technology and whether it's the multi-document asset support or sort of other things that we've added a little over time, I think there's really no technical reason today where you might not choose MongoDB. Obviously, in that $64 billion of spend in 2019, not every dollar of that is RFP every year, right? There are people who are app owners, who are perfectly happy with their application, and they may not have any need to do that. But if you think about 5 years ago, 10 years ago, MongoDB was relatively early on in the life cycle. And the set of applications or the set of use cases where we've been able to perform well and scale and all those things might have been challenged. But over the last 5-plus years, we've made a number of investments that have really addressed those. So if you're going de novo from today to build something, there will be no technical reason why you would not want to build them on MongoDB. You may not be as familiar with it, you may not know about it, but.

Right. So when you mentioned just before, the $64 billion isn't always doing an RFP every year. What is the average life cycle employment? Is there an average?

Yes. It's hard to get an exact number. We've talked about this. And one way that we sort of think about the market is, if you think about that $64 billion growing to $97 billion over 4 years, it's roughly $8 billion a year of new growth, right, in the market. Most of that is from new applications, right? And so as the leading modern general purpose database, we ought to be well positioned to achieve those. And if you think about the $64 billion, we could have a discussion as an application life cycle, 8 years, 10 years, 12 years, how long is it. I'll use 10 years for simple math. So that's obviously 6 and change, of additional -- $6.4 billion of additional replatforming that's occurring every year. And I think the other thing just to the question is it's hard to pinpoint exactly where life cycles are today, but I think one thing that most people would agree on is they're shrinking, right? It's the pace of competition, the speed and ability, need to iterate as those application life cycles are shrinking faster and faster, which creates more opportunity for us.

And how often do you get into a company where they might be using a traditional database player, but because maybe it might be more rigid, they're using you to extend the data that's sitting in there to maybe a customer-facing application, right? Is that -- how often do you get introduced that way? And then how does the spend evolve as that occurs?

Yes. We get introduced in lots of different ways. It would be typical -- the most common, sort of new entry point within a customer, would be for an application that's brand new, right? They haven't done it before. There isn't any legacy infrastructure, and they're trying to build a modern, scalable application. And one of their developers has used or is familiar with MongoDB, and that creates sort of the initial application. Then over time, we have a land-and-expand model that's been very successful for us for the last several years. We are able to go into the account and expand the footprint, either within the existing same department, maybe the same application on our own multiple applications because in certainly large organizations, probably thousands or tens of thousands of applications that exist. And so we'll be able to sort of incrementally win new workloads, and then you tend to see a relational migration will come up a little bit later after there's some pockets of success. And that continues to go on. And so I think that's a little bit what the pattern looks right. And I think it's probably important for people who don't think about the market all the time or aren't familiar with it. It is a little bit different. The way that I often try and describe it is it's not a monolithic market. Goldman Sachs doesn't run every application on one database, right? There are multiple databases that they have within the application, whereas there's typically an organization where we have one ERP system or one HRIS or one CRM, whatever they do. And -- but database is a little bit different. So there tends to be a handful of databases. And then what we see is as we get into an account, the goal is to get standardized, either as the new modern alternative, as the nonrelational alternative, as a default for all new applications, it sort of varies within each customer.

So as you -- we had Thomas Kurian here earlier today. He was talking about their strategy of partnering with open source companies. How do you kind of -- I mean, you can run on AWS. You do obviously as well. But how do you think about the competitive landscape that the public cloud players -- you've got maybe GCP, which is maybe more partner-friendly and AWS, maybe not as much. But how do you think about, I guess, competing with the public cloud players versus just partnering with them?

Yes. There are competitors and partners, all 3 of the large players have proprietary database offerings of their own. And I think that sort of makes sense for them, in that what they're mostly trying to compete for are the storage and compute workloads. And they want to keep them on their platform and not give any customer any reason to go to Azure. Yes, I don't want to give you any reason for Azure or GCP. And so it makes sense for me to have 14 or 15 different databases. It's almost like a classic e-commerce or retailing game of shelf space, right? I just want to make sure that you don't have any reason to go to the competition because I want to keep that storage and compute and kind of sell the rest of the services that I sell up and down the stack. That said, we've been able to compete very successfully against all 3 of them with our own offering. MongoDB is the most popular modern general purpose database. In survey after survey, it's the database developers most want to work with. And so that is sort of that developer mindshare. We introduced the Database as a Service offering over 3 years ago. It's called -- Atlas is the product name. Atlas is now 40% of our revenue in our last quarter. And you can run along with the Atlas on any of the 3 major cloud players. So it gives you that flexibility of being multi-cloud. And one of the things that we hear from customers repeatedly, especially among large enterprises, is incredibly worried about lock in, right? They don't want to pick a database that ties them to a cloud provider and the rest of that stack within that cloud provider. So of course, we compete with all 3, but all 3 have been really strong partners. We have co-sale agreements with all 3. And to your point, certainly, GCP, particularly under Thomas' leadership, is very focused on differentiating and playing catch up.

So you mentioned from fiscal '19, Atlas was 23% of your revenue. In your fiscal 3Q, it hit 40%, right? So if you kind of run the math on what that means for how fast that's grown I mean, it's been unbelievable growth. So while that's been growing north of 100%, you've seen your subscription revenue ex-Atlas actually come in to sub 20%, I think, as of fiscal Q3, I think it was 16%. I mean, ultimately, how do you guys run the business? Do you care which channel it's coming in from? And how should we -- how do we think about the mix?

Yes. Sure. So one of the things to call out is this is that Atlas versus Enterprise Advance, which is sort of the other main product, is really a product slice of the world. And we've tried to provide a bunch of information for investors to understand, to appreciate some of the differences, and that was particularly relevant when Atlas was first launched. That was growing quite rapidly. But also, I think it was really important for people to understand, given the different gross margin profile, right? Atlas includes the underlying infrastructure. So when you're signing up for Atlas, you're picking which cloud vendor. And then we're providing you the storage and compute that goes along with the Database as a Service. As Atlas has grown, we've done a very good job of optimizing the gross margin. We've actually executed ahead of our plan, which is why in Q3, when we reported and we had 40% of the revenue was Atlas, I never would have said at the time of the IPO that we'd be 40% of revenue and 72% non-GAAP gross margins, right? I don't think we'd be able to do that. So we've executed well there. Part of the reason initially to call out the product difference was because of that gross margin profile, right? Because that gross margin profile has shrank, that product focus is probably a little less helpful if you're thinking about the financial modeling. And in terms of how we think about the business, we think about the business on a channel basis, which is why in our Qs and Ks, we report a bunch of information about the channel slice of the business, and the really 2 main channels with one sort of slight disaggregation that I'll give you. So there's the sales sold channel, right? So this is salespeople who are selling customers in annual commitments of one kind or another. And then there's the self-service portion of the business. So these are people who are signing up for Atlas with the credit card. So the sales sold side is all products and has 2 sort of sub channels, if you will, under it. There's the enterprise, classic field deployed model and then there's a mid market team. The mid market team, at this point, sells principally Atlas and leads with Atlas because most of the customers in that segment are either cloud-first or digitally native and that product market fit is incredibly strong with them. For the enterprise channel, it's really still -- still really pretty early. I don't know if you all have disclosed to what percent of your workload is in the cloud, but when I talk to customers, it's a really shockingly small number. And so -- and there's been a little bit of MongoDB salesperson can go do if they're calling Goldman Sachs or someone else because they like, run this app in the cloud or on prem. Companies have an IT strategy. They have a game plan for how they want to deploy it. And so that person is -- our goal with providing Atlas and a couple of years ago, introducing the enterprise features into Atlas, is just making it easy for them to consume Atlas and meet the customer wherever they are in their cloud journey. So if you think about the Atlas mix over time, it will depend, I think, most on how quickly do large organizations about public cloud. I think the mid-market team is growing nicely, but it's already pretty heavily Atlas and then the self-service side is monetizing small credit card-driven usage, and it's been growing. It's roughly half of the Atlas business today is self-service. And then over time, what we've seen is we've sort of evolved and matured. Our go-to-market motion is system interplay, where the self-service customers get some traction. It makes sense for them to get into a customer relationship, et cetera, et cetera. So some of those lines blur. But I think in general, it's easiest to think about it on a channel basis. And we have all the disclosure in our Qs in case that provides that. About 78% of the business is through the direct sales, 22% is self-serve. That's -- the last 2 quarters have looked like that. And then just one last thing. Just as answering your question of -- a number of people do the math that you were sort of walking through, which is Atlas is growing really quickly. Therefore, you can calculate what's the sort of implied non-Atlas growth rate and you get a number that's lower. Q3 was particularly low. And it's because of the 606 winds up affecting a lot of that. We also provide disclosure, the 16% that you can calculate is sort of for all non-Atlas products. Enterprise Advanced is called out specifically in the Qs and Ks and tends to run about 500, 600 basis points better than what they are on Atlas implied. So 22% last quarter, but that's really because of the -- both the 606 and for those who've paid attention to the story we've been calling out in Q3 of last year, we had a lot of multiyear contracts that really inflated and they just made a very difficult compare.

And so your Enterprise customers can typically -- or will typically use both, right? So I think we'll use you on-premise, we'll use Atlas as well. Is that a typical...

Yes. Increasingly. I think that most of the direct customers started with Enterprise Advanced. But as we continue to add workloads, particularly as people are building new applications, cloud often comes up. And yes, so that's pretty common.

So if that -- if you're Enterprise Advanced kind of, as you were mentioning, is 5 to 6 points higher, and that's 21% or 22%. And the database market is growing 9% or 10%, right? Is that -- has the -- I mean, because most of the database market is on-premise. Is that kind of how you benchmark your successes versus that overall number? Or you would think about it that way?

Yes. I would look at it that way only with the Q3 because the compare is so difficult, right? So if you're looking about sort of the dollar itself...