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

Welcome to the Piper Sandler fireside discussion with MongoDB. My name is Brent Bracelin, I spearhead our research efforts in Application and Analytics, alongside Clarke Jefferies, Hannah Rudoff and [ Maura Molino ]. After this 25-minute discussion, we hope you have a better appreciation for Mongo as one of the leading digital disruptors on our coverage list and a core franchise [ done ] for the next decade. Joining me is Michael Gordon, COO, CFO; and Serge Tanjga, SVP of Finance. Michael, Serge, welcome.

Thanks for having us, Brent. Great to be here.

Let's start out with Mongo. I think you're approaching near your, what, 4-year anniversary of the IPO. I can't imagine it's already been almost 4 years, Michael. What an amazing 4 years. Revenue is on pace to 5x over that period of time. What would you attribute the success of MongoDB over the last kind of 4 years to?

Yes. No, thank you. Yes, we're -- it's amazing to think that we're coming up on 4 years. But I think there are a few things that are probably worth calling out. One is we have an extraordinarily large market opportunity, one of the largest in all of enterprise software, the database market. And so that provides this tremendous runway for our growth and our long-term success. Secondly is the product. The underlying product itself really is a better mousetrap. People have been using for decades the relational model, which is sort of tables of rows and columns, which for its point in time, was extraordinarily efficient and cost-effective given the high-priced cost of storage back in the day. But now when you think about the scalability that people expect, the speed and flexibility that people are looking for in their applications, you really need a modern alternative. And that's what MongoDB offers. And so there's this incredibly strong product and developer affinity, right. MongoDB is consistently the database that developers really want to work with because they understand that it addresses some of the challenges of the legacy relational world. And so we have that opportunity in front of us. And then, I think it's great to have a large market, and it's great to have strong product market fit. But you've got to marry that with good execution. And I think over these last 4 years or really longer, that's really what we've been focused on. And when we look out across the opportunity that we have, really just going in day-by-day, quarter-by-quarter, and doing the work that needed to get done, that's really what we've been focused on.

Big market, good product and great execution certainly is apparent here. As you drill down into what the secret sauce is, from a technology perspective. I mean, we've seen kind of the status quo in databases for 20, 30 years. And so walk us through what is that secret sauce that has really made MongoDB special?

Yes. So I think at the core, it really comes to sort of the document model, and without getting extremely technical for the audience because I'm sure they're sort of generalists as well. Obviously, we're always happy to dive into technology. But really, the reason why people used -- why the relational model was so popular when it was pioneered 40-plus years ago was because it was very efficient at storing data, and you'd sort of put these data in rows and tables. And that was sort of the way to optimize for the cost, right? It's kind of like, the example that I often use, especially for non-technical folks, is if you were running a parking garage and your goal were to store as many cars in the parking garage, you would disassemble every cars that came in. And you'd put the fenders with the fenders, and you put the tires with the tires, and the steering wheels with the steering wheels, and you would be able to cram an enormous number of cars into your parking garage. And that's really what the relational model does because, again, this was done 40, 50 years ago when storage was incredibly expensive. The challenge is when you want to go get your car, there's a fairly high cognitive load to figure out how do I reassemble it. Where did I put these? You're doing lookups. You're joining things, et cetera, et cetera. And the document model has the beauty of just storing your car. And it's much more intuitive. It's much more natural. It's much more how a developer thinks. If you think about the programming languages that are popular today, they're all object-oriented programming languages. And in an object-oriented programming language, the document is the object. So it's very natural and intuitive. Whereas if you compare that to relational, I need to do this thing called object-relational mapping or I need to actually figure out where all the data that I need for my application is stored, because it's stored in these complicated schemas that exist with these very large, specialized printers have to print out the schemas to put on people's walls to figure out and remember where did you put data. So I think it's really the innovation that came from the fact that our founders were developers themselves, and every challenge that they ran into as they scaled businesses was scaling the database, right, including sort of most obviously at DoubleClick, where they were serving billions of ads a day, and they found that all the problems that they were running into were database problems. And eventually they said, "You know what, let's go solve the database problem." And then they founded MongoDB.

So you have this really interesting document-driven model. What's been the feedback from some of the larger enterprises? I remember early on, beyond, even before the IPO, you're one of 50 flavors of NoSQL, trying to pioneer this market. How have those conversations with enterprises really shifted over the last 4, 5, 6 years? And what's resonating within that enterprise base today around that document model?

Yes. So I think the industry has gone through sort of a natural and maybe somewhat predictable evolution where everyone, many people saw this opportunity and the challenges of relational. And like a good capitalist model, large markets that have been unchanged for 40-plus years should draw capital, should draw competition. That's what you would expect, right? That's what your economics 101 course or whatever would teach you. And the database market was no different. And so a lot of people tackling this. I think one of the things that -- back to the sort of secret sauce question and the kind of the document model, one of the things that MongoDB did differently was recognize that there were a lot of benefits to relational. There -- so let's not throw the baby out with the bath water. A lot of the others sort of created entirely different models that didn't have the transactional robustness that relational has and that MongoDB maintained and preserves and delivers against. And so what you've seen is like a lot of people 10 years ago trying different things, right, seeing those frustrations, the lack of scalability or whatever it might be. But MongoDB being sort of the one technology that really delivered against this general-purpose nature, right? Customers and companies don't want to have a net new database for every new application. They do like this concept of standardizing. And you won't standardize on 1 database only and you do everything because the database is really at the heart of every application. And that's what determines the ability and agility and nimbleness of the database. But what we've seen is that while there's certainly plenty of players out there who've seen the opportunity, while MongoDB was one of many when I arrived 6-plus years ago, we really distanced ourselves from everyone else because of that technology, because of the fact that we can deliver against this general-purpose positioning, because of the developer fondness. And what that's allowed customers to do is pick MongoDB as a database on which to standardize, right? Because it's not just good for application X or use case Y. But really, it's got that breadth and I think that's really been an important part of the process. And then given that, the natural evolution is you wind up having more strategic, more elevated levels of conversation within any given organization, and we continue to see that as well.

Clearly, Atlas and the momentum around Atlas has been phenomenal. This has now quickly scaled to a $450 million kind of business. I think it's closing in on half of revenue. The acceleration you saw last quarter in Atlas felt different. It felt different just given the scale of the business, the pace, the magnitude of acceleration here. So my question here is, why is Atlas winning, particularly given the alternative, other managed cloud database offerings are coming from Amazon, Google and Microsoft. These are really big companies with big resources where people are already spending a lot of money there. So walk me through a little bit of why Atlas seems to be kind of having some runaway success here in the last quarter?

Yes. Sure. And Serge, obviously, feel free to jump in here. But I think in general, it goes back to sort of the product market fit. And what we've seen -- we talk about the way that we go-to-market, there are really kind of 2 channels. There's the self-service channel and then there's the direct sales channel. Within the direct sales channel, you've got sort of the mid-market as well as the field, the kind of high end of the market. And what we've seen is the self-service almost entirely Atlas oriented. The mid-market is very cloud forward and kind of early adopters. And so the vast majority of that business has also been Atlas and been Atlas for some time. And so when you really think about sort of the uptake of Atlas, what you're starting to see is a significant increase in enterprise adoption of public cloud and enterprises embracing Atlas for mission-critical workloads. You'll certainly still see a variety, either geographically or industry-wise in terms of people who are not able to use the cloud, who want to use the cloud or are not able to use the cloud. But increasingly, we're seeing enterprises adopt, not just MongoDB, but specifically Atlas for their mission-critical workloads. So in the June call, we talked about how our enterprise sales force in that quarter saw roughly 2/3 of the new business be Atlas, which is fairly significant given how early on we are in public company -- a public cloud adoption by large enterprises. And so what we're seeing is the incredibly strong fit there, and that's translating ultimately into more Atlas adoption.

And then as you think about Atlas, tremendous momentum here, and maybe we'll pull in Serge here, walk us through the levers around EA. Intuitively, I'm thinking why wouldn't everyone just go Atlas, right? But what are the drivers, what are the reasons people would still kind of deploy EA? And how do you think about EA as a potential lever for growth in the business? Or should we not think about EA as a lever of growth for the business?

So maybe I'll take a first stab at that, and Michael, feel free to chime in. So the key sort of -- as you think about the driver of adoption between EA and Atlas, it really comes down to where the enterprise is in its cloud journey. And when we sort of plot our customer base, we sort of have 2 very, very big groups. One is a group that almost exclusively uses EA, exclusively or almost exclusively uses EA. And then another group is those who exclusively or almost exclusively use Atlas. And those who use both in meaningful quantities tend to be a significant minority, a growing minority but a significant one. And what that tells you is that those who use EA are just comfortable with on-prem. And of course, in the fullness of time, we expect that to change. But we don't expect that to be sort of a near-term phenomenon in terms of some switch that will flip. The other thing I should say, for those EA customers, very rarely do we see them take EA workloads and transition them into Atlas, very rare. And of course, we do expect that to pick up at some point in the future. That's the beauty of our platform in that we give you a relatively easy on-ramp to the cloud when you're ready. It just seems the customers aren't. Now the good news is that even in those customers, we have relatively low share of total database spend, so we see opportunity to grow. In fact, in our Q2 call, Dev talked about this pilot that we ran last year where we gave more resources to some of our most promising accounts to see if we can achieve deeper penetration. Some of those accounts were EA accounts and we have seen success. And so it's not -- obviously, Atlas has been driving the growth and we don't expect that to change. But there's a significant portion of our customer base for whom EA will be the go-to product for years to come, frankly. The other thing I would say, Brent, and I know we've spoken about this in the past, but maybe for the audience, good to sort of remind them is, we really don't model the business on a product basis, we model it by channel. And that is because we think that the market is enormous, and we think we have a very popular product. And as long as we effectively deploy salespeople in the field, that we'll be able to achieve growth. Particularly as you take a look out a few quarters, Atlas versus EA tends to be the output of the model that's most [ of the input ].

Fair enough. I remember it wasn't too long ago that many investors felt that Amazon DocumentDB was a killer product, and that MongoDB was road kill. I think we heard a similar thing from Elastic, right? Amazon was going to kill elastic. So maybe we just rewind, fast forward, why do you think Amazon DocumentDB didn't have a bigger impact on Mongo?

Why don't I take that? So a couple of things. Certainly, there was a lot of talk and concern and the reality is anyone in infrastructure software competes with the big cloud players, but you also partner with them. I think what's important here to remember is we own our own intellectual property. And so even though MongoDB is open source and has open-source roots, it's different than most other open source companies. And so the DocumentDB, it was trying to imitate or mimic or look -- the look and feel of MongoDB because Amazon and Microsoft with their offering recognized the popularity of MongoDB, but any time by definition that you're trying to imitate something but can't actually use the underlying thing, it's got to definitionally lag and then it can't perform the same way because it's -- you're not -- it's not as simple as just sort of copying it and then monetizing it, right? If it were a permissive open-source license, that would be possible to do. And there's certainly other situations and other cases where the cloud players have done that. But because we built the technology ourselves and own the intellectual property, they can't just take and go clone it. So instead, what they've tried to do is they've tried to capitalize on the popularity of MongoDB and create this sort of imitation offering. And so the result is definitionally, it sort of lag, it tends to fail the vast majority of our correctness tests, and is underlyingly sort of built on a relational back end or sort of underlying architecture. And so it's got several challenges. So the result of which is our win rates against competition in general are quite high, but are particularly high against the imitation products, in particular, that Microsoft and Amazon offer. So it's sort of in the "imitation is the sincerest form of in flattery" kind of bucket, despite all the headlines.

Absolutely. And have you seen them show up less, show up more with those kind of imitation products? Are they starting -- is the market starting to kind of be a little bit more wary of those products?

Yes. So I think the way I would describe it is, our biggest challenge is the footprint coverage, right? And so it's not like we see every opportunity. And so we know when the opportunities where we see, we are successful at an extraordinarily high rate. But they are large players. They do have large ecosystems. There are -- there's sort of a meaningful flow of business. And sometimes I'm sure there are things that we do not see that would be better served by us. And then we've also had issues at times where the customer doesn't know that what they're using actually isn't MongoDB. So there's some of the naming and other things lead to some confusion, intentional or otherwise, in the market. And so I wouldn't say -- it's not so much sort of what we see or when they show up or don't, but the stuff that I worry about the most is something we don't see, just because of the relative size and scale of our footprints.

Absolutely. Let's shift gears a little bit to trying to help understand where your penetration sits. Even with some of the larger customers, I think you have 300 100,000-plus customers at the IPO. You now are at over -- well over 1,100. I think now you have 100 customers spending a $1 million-plus on Mongo. So if you looked at that $1 million-plus cohort, what's your share? What's your market share even some of those customers? Are you kind of pushing close to 50% market share of the database spend at those 100 -- at the larger customer set? Walk us through penetration at the largest customers.

In general -- obviously, Serge, feel free to jump in here. But in general, the market, especially among larger customers, tends to be quite barbell. Either it's a newer modern company, where we have the vast, vast majority, if not the entirety, kind of their database spend, they kind of built their business on MongoDB, so to speak. Or it's a large enterprise where we have very little market share, single-digit market share. And so for the $1 million-plus companies, the vast, vast majority of those are large enterprises where we have single-digit market share. But we have started to see over the last couple of years, that get populated by a small number of accounts that are new, modern businesses that have had a lot of success, that have built the -- or large chunks of their business on MongoDB. And we've participated in their success as their usage and consumption and adoption of MongoDB has increased. But in the large enterprises, we have single-digit and usually low single-digit market share. Again, it sort of speaks to the size of the market, the magnitude of the opportunity, and for some investors who maybe don't think a lot of time thinking about databases, acknowledges that the database market is a little bit different. It tends to be a less monolithic market where one entity says, "Okay, I only use this database." Right? Whereas in ERP or HR systems or otherwise, you would tend to have an enterprise-wide purchase -- CRM, other things like that -- databases are a little bit different. So that's what sort of explains [ this ].

The only other thing I would add, Brent, over the last few quarters here and there, we mentioned that we're now starting to see 8-figure customers. And even in those accounts, we're nowhere near 50% market share. So this speaks to sort of the size of the market and the fact that it's not monolithic, but frankly, to the opportunity that lies ahead.

Interesting. Just one or two 8-figure customers is that the way to frame it? Or is there some momentum there on the 8-figure side?

Well, think of it as sort of the continued motion, but now some nontrivial number of them has crossed into the 8-figure number.

I think the key point there is that in those situations, it still fits in the barbell, right? It's all there because we are the primary database, or we still are in low market share.

Look forward to the disclosure of 8-figure customer metrics over the next 4 years. You started with 100,000, you moved to 7-figure. Over the next 4 years, maybe we'll start to track the 8-figure customer opportunities, for sure. Let's pivot here, last question for me is just really around the opportunity and the investment side. You talked about, Michael, being nervous around, hey, we just don't have the coverage. It sounds like some of the named account activity things you've been working on is really working well. You have less than single-digit penetration at some of these large Fortune 500s. Why not do more? What are you doing there? How aggressive do you plan to be? And obviously, we are in a pandemic, I get that. But walk me through how your -- how ambitious your investment plans are in sales and marketing through the go-to-market strategy here?

I think the key thing there, and we've talked about this before, is that we -- our operational constraints are our largest constraints. We're not market constrained. We've certainly raised plenty of capital. And so really, it ultimately becomes this question of how quickly can you hire quality people without either lowering your bar or increasing the odds that you degrade the quality of their ramping time because you ultimately want them to be effective and producing at the high levels that we want them to, for the underlying unit economics to be strong. And so really, it's a fairly boring operationally oriented answer more than anything. I think each of the years that we've gone into the planning process that I've been here, from a sales and sales and marketing perspective, the starting constraint is what do we think we -- there are really 3 parts of the equation: how many people do think we can hire; what do we think the ramps will look like; and once they're ramped, what's their productivity going to look like? And almost always the first one is the constraint in terms of ultimately the magnitude of investment and the growth.

Looking out to next year, Michael, what are you most excited about?

I think it's just a continued opportunity. I feel like we're -- we've had enormous success. We've probably grown revenue in the time that I've been here 20x, and we're about 1% market share, right? You don't get to say that a lot of times in your career. And so when I look at it, it just feels like we're getting started.

Great way to end the session here. Thank you so much for your time, and I look forward to talk and touching base.

Thanks for having us. It's great to be in your program. Good to see you.

And continue.