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

Great. Thanks. So for everyone who's tuned in now, we currently have the MongoDB management team. We have Mr. Michael Gordon and Mr. Serge Tanjga. Thank you for joining us today.

Thanks for having us, Mike.

Absolutely. Absolutely. Looking forward to a great fireside today. For any of the listeners who are tuned in, if at any time you guys have a question, there should be a chat box where you can submit questions, and I will do my best to make sure that we address those during this time. With that behind us and the logistics done and out of the way, guys, thanks again for joining us. Can you just provide a quick overview of MongoDB and the company's value proposition, just to serve as a baseline understanding for our listeners.

Sure. Just to give a broad context, so we compete in the database and application data platform arenas. And so really the easiest way to think about this, especially for the nontechnical folks in the audience is that increasingly, companies are competing on the basis of their technology, specifically their software for their customers. And at the heart of every software application is the database. And the database is what determines the agility, scalability and ultimately the speed and pace of innovation that the company can execute. So if you think about these phrases like software is eating the world or every company trying to become a technology company, those are all sort of code names or shorthands for talking about how the fact that companies are trying to derive competitive advantage from their built software. Obviously, all the off-the-shelf software is available to everyone, so that doesn't really provide much of a competitive advantage, but it's the software that you build. And the database is at the heart of each one of those applications. And the problem that we're solving is historically, relational databases have been the core technology choice of companies. And they were great 40, 50 years ago. They were pioneering and solved a number of the problems of the day. But today, the managing of that data is the biggest problem for developers, and that's what inhibits their speed and their ability to innovate quickly. And so what we do is we've got a modern developer-centric approach that makes it much more easy for the developer to use, much more intuitive than the old legacy models that were built before mobile, before social, before the Internet. This is all sort of designed to be cloud-friendly, modern and everything else. And so it's part of the reason why we've been able to have the success that we've had is we're tackling this very, very large market. The database market is one of the largest in all of software, $74 billion in 2021, going to $121 billion in 2025. And we've got this very large market. We have this exceptionally strong and unique and differentiated product that makes it easier for developers. And the result of that is that we've sort of won the hearts and minds of developers and so are the database that developers most want to work with. And we've paired all of that with really good execution in the field to build on the success and kind of capitalize on the opportunity we have.

Awesome. Awesome. And in this database market that you guys are now attacking, who are the primary competitors that you're seeing? And maybe if you could split it up between some of the more legacy guys coming from that relational focus versus some of the new up and comers?

Sure, sure. So if you think about that $74 billion market that I talked about today, like the largest wallet share is with the incumbents that would be typified by companies like Oracle and people like that. There's certainly a crop of new, new relative to Oracle, new players like MongoDB, who've come at the opportunity and have observed this very large market that for decades was really not disintermediated. And with a good capitalistic mindset, markets like that should draw capital, should draw competition. And so we, along with a bunch of other people, saw that opportunity. I think we've been the most successful, really the only one that's sort of broken out and kind of had any kind of meaningful critical mass of success. And again, I think that really is because of the strength of our product, the differentiated features and the fact that developers love it. That sort of developer-centric aspect to what we do and the developer popularity that we have and then all that very good execution. And then the third bucket of competitors would really be the cloud players, right? So these are folks who are increasingly trying to provide lots of different layers within the infrastructure software stack. I think the database layer, in particular, has been interesting. And ultimately, what we've seen is while there's certainly a competitive angle with each of the big 3 hyperscale players, we've increasingly seen them take a more cooperative approach recognizing that, of course, they have competing offerings but that we at MongoDB bring a lot to the table. I think there are kind of 2 important aspects to understand there. One is that customers, particularly large customers, are hypersensitive to vendor lock-in. And because the application is built on the database, the lock-in or the stickiness of the database layer is even greater. And so they're very reluctant to build on cloud proprietary databases because that will lock them in more broadly to that cloud player. And so there's sort of generally an openness to MongoDB because we're multi-cloud in addition to being able to run it on-prem or run it on your laptop or however you want to. And then also the cloud players themselves see the additional pull-through or drag along or however you want to characterize it of the stickiness of that workload that even if they're not getting the database layer, they're getting a whole bunch of ancillary services and value. And so over time, we've seen that relationship evolve. There's, like I said, always going to be a competitive angle but also increasingly cooperative one.

That's great. That's great. And it sounds like the cloud providers really, this more, I guess, cooperative effort is just based on the fact that from drawing an analogy, it's almost like you guys are the Switzerland, being able to play multi-cloud. And then their understanding that once the workload is there, they can still recognize services on top of that but feeding into both sides of the equation between the cloud providers?

Yes. And they get the underlying storage and compute from us as well in addition to sort of being able to sell all the value-added services. And I certainly wouldn't want to pretend. I mean, obviously, they prefer to get every layer that they can, right?

Absolutely. Right.

But I think there's an understanding of the popularity, of the product superiority. And ultimately, from a customer perspective is a heightened degree around vendor lock-in that I think sort of often carries the day.

Great. Coming back to the TAM because I know we had some comments before about that database market being $74 billion growing to $121 billion. Can you walk us through, I guess, how much of this market is coming from this more relational database looking to improve or to find some of the latest technologies on that. I guess, how much of that market are you addressing in addition to that?

Yes. So the way that I think about it is from a technical standpoint the entire market is available and addressable, but that doesn't mean that every workload will instantly or should instantly move over to MongoDB. I think that the database market is different than many other markets in the sense that if you're buying HR, an HRIS or HCM software, you're buying an ERP or a CRM or something like that, those tend to be monolithic across the organization, meaning that the legal department doesn't run in a different set of HR software than the marketing team. Applications are different, right? And a large organization will have thousands or tens of thousands of application and each application will have its own database. And so just because we win an account, we talked about Verizon in the third quarter earnings call back in early December, that doesn't suddenly mean that Verizon, every application within Verizon runs on MongoDB, right? It tends to be much more sort of workload by workload. And so I think that's sort of an important backdrop to the dynamic. And so what that means, if you think about the numbers that I shared in terms of the industry spend, $74 billion going to $121 billion over 5 years, you've got sort of more than $10 billion, roughly $10 billion a year in new applications, right? Most of the new growth, most of the growth is in new applications. And so there's sort of this $10 billion, $11 billion chunk that's up for competition every year. And then we can have a debate around what's the life cycle of the legacy spend, right, the $74 billion that people are going to spent today. And just for simple math, I'll pick 10 years. We know product life cycles are certainly shrinking. But that probably means there's another $7 billion and change of that, that's replatforming every year. So in terms of like the actionable or addressable piece, it's in that sort of $17 billion, $18 billion, $19 billion a year that's sort of in play. And certainly, we see, given that MongoDB is the most popular database and the database developers want to work with, we're very well positioned for new applications, but we also continue to see a lot of legacy applications that are just having challenges with relational who want to move and need to move to MongoDB. And so if you look at our product line, MongoDB Atlas is the majority of the business. That's our database as a service. That tends to be new applications given that those are either new applications because they're native to the cloud or they're being rebuilt and so they're mostly kind of considered new. Enterprise Advanced is our self-managed product. And about 1/4 of that, it obviously varies and fluctuates quarter-to-quarter, but roughly 1/4 of that business tends to be replatforming of legacy relational applications. And so we've always found a healthy mix of both is valuable. But certainly from a technological standpoint, we could do the whole thing. It's just if you have an application and it's working just fine, there's really no reason for you to want or need to replatform that. I think about with my CFO hat on, engineers are a precious resource in any given organization. They always much rather have them do new features and new functionality and new capability and improving user experience rather than rebuilding something existing, right? You go back to rebuilding something existing when it's just not working for you, right? I mean, that's when we'll end up solving some of the problems that relational causes.

Understood. Okay. And I think one of the things that's interesting and maybe as a backdrop here, but in this market, there just seems to be a ton of disruption that we're seeing versus even 10, 20 years ago. What has fundamentally changed that the legacy vendors can no longer solve for? Can you walk us through the major pain points that Mongo is really solving that those other vendors can't really address today?

Yes. Why don't I take that one, Mike? So really, the story begins 15 years ago. And the story of MongoDB, but also the story of sort of increased innovation in the database space. And the reason is because that's sort of time frame coincides with Internet 2.0, with Google, with Facebook, with other applications that sort of reached a whole new level of scale. And frankly, that's also the founding story among the MongoDB and our founders came from DoubleClick. And these are companies that just had requirements for their application that are different, orders of magnitude different than what came beforehand. And it became obvious that the relational technology, the legacy relational technology was not going to be sufficient, frankly, to solve the challenges of the application of the future. And so the realization that the application in the 21st century effectively are going to require a different underlying database architecture underneath. And what Michael was talking about, sort of this idea that in the world of capitalism, markets will attract competition, meant that literally dozens of companies were founded and received significant funding to go after this market and go after this market in a way that is to try to solve the problems that relational couldn't solve. And those problems were difficult for developers to work with, problem scaling and real problems distributing data, in other words, not built for the Internet age. And so a lot of innovation happened, again, starting in sort of 15 years ago. A lot of companies were founded that were introducing different models, different ways of sort of building the database and we were one of them. And we focused on the document model, which is at the core of what MongoDB is all about. And much of the companies that sort of came or that crop of companies tried to do was solve for the problems of relational but sort of throw the baby out with the bathwater, meaning leave the good things behind that relational had. And don't forget, it's a technology that worked for a long period of time. It's a technology that's still the vast majority of the dollars spent in the database industry. And what we did was different. We tried to marry the best of both worlds. So we try to solve for developer productivity. We try to solve for scalability, performance, data distribution, but we also understood that transactional guarantees, rich query functionality and a number of other sort of features that are sort of table stakes for relational technology, we needed to bring to bear as well in order to be seen as a mature enterprise-ready platform that can handle the most demanding workloads. And frankly, that's the story of MongoDB over the last 15 years, which is sort of continued investment behind that original idea that was going to solve for problems of relational, but continue investing in order to make sure that the platform is enterprise-ready. And sort of the market share that we've been able to gain and the sort of the distance we've put between ourselves and all the other newcomers indicates that, that was the right strategy and also that we executed really well against it. But there was this sort of, what should we call it, there was a problem in the market, a lot of people try to solve for it and there was almost a fragmentation of the market because a lot of more offers were put there in the market because customers were struggling, and they were willing to try any number of these new vendors, and that's sort of the fragmentation of what the market has been going on for the last 15 years.

So that's actually hitting on like the next, the absolute next item I wanted to touch on with you. And we've been discussing it as well, this database fragmentation, based on the various use cases, the technologies, the vendors. In your view, given this has been taking place over the last couple of years now, is this fragmentation a good thing or a bad thing? And over time, do you see consolidation towards a single vendor again or we just passed this toll booth and this fragmentation likely persists?

So I'll speak to it from the point of the customer because that's who we ultimately want to listen to and sort of adjust our approach based on what the customers tell us they want. Customers don't want more database. Customers don't want a net new database for every new workload. Because with that new database comes increased complexity at the back end, increased data siloing and actually turns to then slow down the developer because now the developers need to sort of context with between a variety of different technologies, and you're not maximizing the resource that is most scarce in today's world, that's your developer time. And so we understand why fragmentation happens, and we see this sort of pendulum swing in technology over and over again. There was a problem. There was a dominant technology. It was 100% share of relational, whatever, 15, 20 years ago. It became obvious that, that technology had limits. We had innovation to solve that and customers were adding key value stores, graphs, graph databases, time, any number of other technology, time series databases, any other technologies to try to supplement their relational estate but that was because they needed to solve their burning application front-end issues while increasing the complexity of their back end. And so where we think it's going to go and frankly, the bet that we're making is that customers actually want to run fewer general-purpose databases rather than more specialized niche databases. And that's what we think is the appeal of MongoDB is that we are the best application for all but relatively small number of very, very specialized and niche use cases. So we are betting on the pendulum swinging the other way in the market. So away from fragmentation, which has kind of gone too far, and back towards consolidation, where you're going to want to have a modern standard on which you are going to deploy a majority of your modern applications. And you'll still probably have a relational standard as well because that's still a large estate that will likely stay in the enterprise for a long period of time. But the customers will go away from this approach of new workload for, sorry, new application for every workload only because they understand that the tax that they're paying in terms of back-end complexity is enormous.

Yes. I would just describe, that's what we see in the market, what we've seen for years. I wouldn't quite characterize it as sort of a bet on some future state that is divergent from the existing state. It's more just sort of what we benefit from in the market given that people don't want to have a net new application for every new, sorry, net new database for every new application. There are benefits to standardizing. And I think Dev and Serge and I have talked about in the prepared remarks in the earnings calls as sort of progression that accounts go through, where they start to become, they declare MongoDB a standard, and we're one of the few technologies that has the potential to broadly be declared a standard really across the board as sort of like the modern alternative.

Right. Okay. And if that is the case, how would you best describe the use cases where Mongo resonates best in the market? And are there specific use cases that you think are more utilized for, let's say, new customer land whether it's by vertical, by geography, how do you think about those use cases for your database specifically?

Yes. I think that, that was either more true for us several years ago or is more true for some of the other would-be challengers, if you will. But I think part of the reason why we've had the success that we've had is this breadth of use cases is the general purpose nature of what we do. And so there are certainly other players who, to Serge's description, saw the challenges of relational, came up with a solution, but could only do this type of use case. And so in some ways, that's easier, right, because they can then go train the sales force and be the hammer that looks for all the nails out there that they can find. Ours is a little bit different because of the general purpose nature of what we do. It's really the full suite. And so you see every flavor of application. You can find a single view of a customer and content management and transactional and graph, like all different flavors. And so it's a little more challenging in a certain sense for our sales force, right, because they can't just sort of like quickly with it on the universe and say, okay, here are the things that are going on within this account that we can't do. And so let's look and see if we can find the 1 or 2 things that we can do. It's a good thing overall in terms of the breadth and scope of the opportunity, but there is a little bit of an incremental challenge in terms of sort of prioritizing and finding out everything else because you can't just go look for the one use case that you do really well.

Okay. And I know we've hit on the developers, right, being able to make sure they're using their time efficiently and helping them scale to the best of their abilities. Can you help us understand the go-to-market approach for MongoDB? Maybe any detail on how the pipeline looks today and interweave with that, I know I've got a couple of questions around the potential impact from the Omicron variant given where we are today.

Sorry. I muted myself. Yes. So the go-to-market has got a couple of different aspects to it. There's both a self-service component, which lends itself nicely to sort of the developer-led motion, but also a direct sales component. And the direct sales component, while they're sort of increasing, segmentation is best described as having sort of 2 flavors, sort of an inside sales kind of mid-market model that would be familiar to folks and then an enterprise model that still focused on the largest customers, Fortune 500, Global 2000, kind of people like that. And so it's a little bit different given that MongoDB is open source, right? So people can use it on their own, whether they're using a free tier of MongoDB Atlas, whether they're self-serving into becoming a paid Atlas customer or whether they're downloading a free version from our website or any of the other repositories out there and just getting started and go and use it. And so the situation is then trying to find opportunities where people either want to run it as a managed service, which is our Atlas product, or if it's a larger organization that's probably less cloud forward, it's more they might need help or want to think about how to deploy MongoDB broadly. And so what the sales team is looking for is looking for activity, looking for pockets of the signals. Obviously, with Atlas, the database as a service, we have many more signals than we used to have. So we used to only know sort of who downloaded it and then we'd have to do a lot of exploratory work within the account to understand maybe there was activity, maybe someone asked for a white paper, maybe someone attended a webinar and try to figure out and triangulate where the activity is. Obviously, with the database as a service offering, we have many more in-product signals so we're getting better about harnessing those. But over time, what we're seeing is that all the channels are working better together so effectively more in concert. We've sort of originally conceived of the channels, particularly the self-serve and the direct sales, as a little bit more separate or discrete and we've increasingly gotten more effective at finding ways to sort of interact those, right? So we talk about Atlas. And while the sales sold when you look at the customer counts and the sort of implied revenue and everything else is larger, I think it's easy for people to sometimes forget that the majority of self-serve customers or majority of self-serve revenue started out, sorry, the majority of Atlas revenue started out as self-serve, right, was self-serve sourced. But the majority of the expansion occurred while it was in the sales team's hands. And so I think we're sort of increasingly getting better and more effective at how to leverage those 2 together.

Okay. And anything that you guys are seeing currently as far as impact to the pipeline as a result of this Omicron variant or has that not really shown up just yet or is it not expected to show up, sorry, let me rephrase that.

Yes. That's fine. So I'd say a few things. Obviously, Omicron most showed up over a lot of the holiday period, so certainly a little too early to tell. If we take a broader step back, we've been fairly consistent. Certainly, folks who have followed the company will know that we've been quite deliberate and transparent in trying to describe the impacts that we've seen throughout the many waves now of COVID starting with the March 2020 call that we did where we described the outlook, quantified the potential impact on the horizon that we saw from COVID. The primary impact being concerns around the ability for the sales force to close new business, right, and sort of concerns around new business. One of the things we said most recently in the December call of this past year reporting our Q3 results was that as we look out on the Q4 guide, certainly, at that point, we didn't obviously know exactly where Omicron would take us. But it was very clear that there continued to be lots of uncertainty in the market around COVID. But then now we had several quarters of having dealt with that uncertainty. And so the risk related to the uncertainty in our judgment was lower than it had been previously because now we at least had some data points where sort of despite the uncertainty, we've been able to sort of manage through all of that. So the uncertainty continues to exist, Omicron just being the latest, but I think that we have developed a level of confidence and conviction that the sort of risk in the business is smaller than we previously sort of identified and ultimately quantified in terms of forecast and guidance and things like that as a result of the fact that we clearly executed successfully and beyond our expectations for the last several quarters.

Great. Great. And turning back to the customer base, can you help us think maybe from a strategic standpoint, how is it you think about growth, whether it's forming your existing customers or an approach towards, I guess, acquiring new logos just given this massive market opportunity we're talking to. How do you guys strike that balance?

Yes. So I think what we prioritize is a healthy mix of both. And if you think about an individual sales rep, they have a certain territory. And because, as we described at the beginning, the database market isn't monolithic. And once I've won an account, I'm sort of getting all of the workloads within the account. There's a very, very large opportunity to continue to expand within an account even after that initial land, right? So the simplest quantification to offer was to go back to the IPO several years ago. And what we talked about at that time was that we had just over half of the Fortune 100 were customers, right? And I think it provides a neat little example to help people understand of what that means from a customer count standpoint is that the best you could do is not quite double your customer count. But at the time, our estimation was that we also had less than 1% wallet share from that set of customers, right, which means that you could increase your business with them more than 100x, right? And so there is this landing, given the size of the market, landing new logos continues to be important, and we continue to do well at that. But there's also a lot of opportunity just within the existing accounts that we still have given that the way the database market works is more sort of application by application. And so we've talked about and help people try to dimensionalize this in a few different ways. Another way that we've talked about that's maybe helpful is, if you look at our customers that are our largest customers, right, our largest 50 or our top 50, top 100 customers spending over $1 million or whatever way you want to sort of like conveniently kind of slice and dice it, what you'll find is there are a minority of those customers where we really have very, very high market share, right, high wallet share, right? These tend to be exemplified as sort of newer businesses, cloud-native businesses that have built the entirety of their business on MongoDB. And so there's not a lot of incremental in those accounts opportunities for workloads, but we're benefiting from their growth as a company or as an application. That tends to be the minority of those largest customers. The vast majority of those customers are, again, the Global 2000, the Fortune 500 customers where even though they're a 7-figure relationship or one of our top customers or however you want to slice and dice it, we're probably still single-digit market share or wallet share within their database spend, again, just sort of underscoring the magnitude of the market opportunity that we have and the fact that it tends to be more workload by workload even when you're sort of a standard in the account.

Terrific. Terrific. And probably more competitive question here, but I'm thinking about the technology behind your database. Can you walk us through the advantages of how you guys have architected the solution? At this point, I would think that it's not so much an evangelical sale. But do you think that, that architecture, the way that you guys have been built resonates in the market today or is there still more to do on that front from an awareness standpoint?

Yes. So at the core of how we organize, the architecture is sort of the data model that you use so. And we sort of, I'll juxtapose us versus the relational technology. So relational technology is based on rows and columns. Think of it as Excel on steroids, where you have data organized in tables and multiple tables pointing to data to other tables to pull information together to represent whatever needs to be represented. By contrast, we are organized in the document model. And so usually, information on a single entity is all placed in a single sort of location in a single document. So you think of an application that needs to store an information on a customer or an employee. So if you need to have first name, last name, address, credit card number and whatever other characteristics you're going to take from that customer, in a relational technology, that's going to be distributed across a number of different tables, whereas all of it is going to be in a single document for us. And so why would that be the case? Why was the technology that was started in 1970 built around the concept of rows and columns and tables that point to one another versus different technologies, including ours that is used today. Relational was trying to solve in the '70s and '80s when the technology was started for the constraint of that time. And the constraint of that time was expensive storage. So what you wanted to do is repeat as few times as possible data because that data takes place on a storage disk, and that was very, very expensive. So that's why they created this elaborate system of multiple tables that point to one another in order to every single piece of information capture only once. It will be the equivalent of, you had a garage and you try to park as many cars in there as possible and disassemble the car at the interest of the garage in order to maximize the space of the number of cars that you would need to put in there. Fast forward to this century, storage is effectively free or heading in that direction. That's no longer the dominant constraint. The dominant constraint is how quickly you can innovate based on some of Michael's comment. So when you have all the data around an entity or an object in a single place, that means a few things. Number one, it's much easier to add to that document. You could add incremental information, incremental categories, incremental metric, statistics that you want to keep on the customer as opposed to in a table, where it's not just about updating a single table, all of them need to be updated and all the relationships between them need to be updated. It's extremely complicated and taxing. Second of all, if you try to grab quickly information on that customer because they're pinging your database for something. Instead of going to many different places to grab various features of them to bring their profile together all at once, you're all going to the same place and getting it quickly and therefore, delivering a better customer service. So that's why, those are some of the major advantages of the document model. Data that is accessed together is stored together. And that means that developers can innovate faster and the application can get the data from the database faster because of the way that our technology is organized. And also ours is easier to scale because distribution of incremental documents is relatively simple compared to scaling of this enormous labyrinth of data tables across many more customers.

Got it. And I did want to come back to the go-to-market as well. I know that Michael was talking to this developer-led engagement alongside some of the sales force, more traditional sales force teams that we would think about. When you guys are seeing these channels line up, I'm curious, are you seeing some of the conversations in the market maybe shift to a different persona as these purchases are taking place? Or maybe more of your leads beginning higher up in the market or is it expected that these 2 channels are going to stay about where they are and continue to work alongside each other as you guys look to the future of the company?

I think they definitely work together. I think that what I would say is increasingly, over time, we've had -- and we've called this out, I think, in some of the earnings calls -- more and more C-suite level dialogue, right? As you wedge or break into an account, there tends to be a specific application, either an existing application or a new application that's important from a launch perspective to the business that isn't working, right? The relational isn't scaling. It's too brittle. They're not able to innovate quickly enough. And so they want MongoDB and there's that sort of point of pain. And then within an account, we tend to repeat on that success, use that first application as an internal reference account, you build up more momentum, you get a little bit more awareness and then you start to see some broader adoption. And then ultimately, there's a higher level conversation that involves some level, usually a C-suite dialogue that involves some level of standardization. And one of the ways we've sort of talked about this is that initially you have to sort of break in the side door and that's our first application. You then develop a relationship and you're working more broadly in the account. And then you're sort of invited to the front door and people like finance and procurement and sort of other organizations or functions within a big, large organization get involved. And then eventually, it becomes a strategic relationship and then you sort of move to the loading dock where you're more central, you're sort of integrated more effectively. You've been declared a standard. Adoption becomes much, the topics become much broader. There's still work to do. It's not like suddenly you're declared a standard and then like just the orders flow. There still is, it's sort of an application-by-application, workload-by-workload dialogue that needs to go on but some of the barriers have come down.

Terrific. Terrific. And I'm looking, we are just about out of time now. I have about a half dozen more questions for you guys, but I think we're going to have to leave it there, unfortunately. I do appreciate the time. And thank you very much, guys. Good luck with the rest of the conference. And to everyone listening in, thank you very much for your time as well.

No, thanks for having us, really appreciate it, both the session and the conference overall. So thanks, everyone.

Thank you.

Thanks, guys.