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

Thank you, everyone, for joining us today. My name is Mike Cikos, I'm the lead analyst here at Needham covering infrastructure software. With me, I'm pleased to say we have the management team from MongoDB, CFO and CEO, Michael Gordon; as well as SVP of Finance, Serge Tanjga. Thank you to both of you guys for joining us today. We really do appreciate the support to the Needham Growth Conference.

Thanks for us, Mike.

And I know we're going to be tight on time here, so we're just going to just tackle it right up front. But one of the things I received a decent amount of inbounds on obviously, has been the December security incident. Just to kick it off, can you kind of put any parameters out there as far as how extensive the unauthorized access was with respect to the customer base as well as just set the table, I'm sure not everyone is following the blogs like I was, but anything else you could put around that, that would be great.

Sure. Yes. Thanks again for having us. Happy to dive right into it, and let's start with that. So as we shared, we were the subject of a phishing attack, they gain access to certain of our corporate applications. The unauthorized person got access primarily to customer contact info and other account-related information. We found no evidence of unauthorized access to Atlas clusters or the Atlas authentication system. Those are 2 different systems. So that's sort of important to note. At this point, our investigation is complete and closed. And so I think that's sort of the quick headline. I know these are somewhat common and unfortunately, increasing common events across the landscape. We tried to take a very transparent approach with customers and everything else. And so from within a matter of days of getting -- determining that there had been that unauthorized access, we alerted customers and, therefore, kept the public abreast with various updates on our alerts web page and everything else and have got a number of kudos from customers for doing that. So that's a quick summary.

And maybe just from a logistics standpoint, but is it fair to assume then that there might be incremental costs related to the forensic partners on the security side of the house or cyber insurance, non-GAAP-ing that out? Like how do we think about that?

Yes, nothing material. I mean, obviously, yes, when you're responding to one of these, you have some incremental costs that you had intended. We did retain third-party help, et cetera, et cetera. But as of right now, nothing that we would attend to non-GAAP out or anything like that. I think from a materiality standpoint, obviously, you've got to run through all the assessments everything that while we disclosed it publicly that was more because we're disclosing to our customers rather than because it was material financially.

Understood. And thank you for the qualifier on that. Want to shift to consumption for a second. But just so the audience knows, and I know I'm going to be moving around a little bit, but there should be a chat box on your interface. So if you want to send in a question, feel free to do so. I'm going to try and get to as much as I can, while we have Michael and Serge here as well. But please send those questions in. On the consumption. So again, just taking a step back, can you help us think about the consumption trends that we've seen through calendar '23? And really, I guess, what occurred in Q3 versus your expectations? And how did that influence your assumptions when thinking about the Q4 guide?

Maybe I'll take a first step at that, Mike. So I'd actually start a little bit earlier than fiscal year '24 or calendar '23. So starting in the late first quarter of fiscal year '23 for us, so calendar '22 effectively. We're starting to see a macro induced slowdown in consumption. And we were among the first people to call it out. Incorporated in our guide and so forth. And we've sort of done it before, it really started, because we saw enough evidence at the end of Q1 to make it a part of our Q2 guide than in Q2 of last year, so at this point, 5 or 6 quarters ago, we did see that slow down materially. And since then, we've had periods of seasonal strength and seasonal weakness. And frankly, some just natural variability in the numbers, and we've tried to kind of be transparent along to wait and give investors sort of our latest thinking. But now with the benefit of [indiscernible], if we look at that period, effectively starting in Q2 of fiscal year '23, through Q3 of fiscal year '24 and also how we thought about guide for Q4 is we've seen a relatively stable environment, just the growth was at a lower level. So there will be periods of strength like the back half of Q3 tends to be seasonally strong. There will be periods of seasonal weakness like around the holiday season. And we try to take that into account when we provide guidance. And certainly, when we provide commentary in terms of how we've done vis-a-vis our expectations. But generally speaking, there's sort of like a range of consumption outcomes and if you might recall, we showed that chart at our Investor Day, that kind of shows on consumption. And a certain level before Q2 and then at a lower level on average since then. And yes, there's variability around that average, but we've been in kind of that slower stable world since there. So let's just take a general construct. For Q3, now we're in a world in which we have been in the world of lower macro for more than a year. So what we're trying to do is give you color versus our expectations, but also versus last year. And you should expect that we'll kind of continue doing that going forward. But in Q3, consumption trends were in line with our expectations. We did see a seasonal recovery in Q3, meaning seasonally because Q3 was stronger consumption than Q2. However, the seasonal recovery was not as strong as it was in Q3 of last year. Now you might ask yourself, okay, well, if it was not as strong as last year, why did you expect that? And the reason why we expected that is because generally speaking, we are seeing less variability in consumption in fiscal year '24 than we did see in the back 3 quarters of fiscal year '23, and we have some reasons and hypothesis of why that might be the case, but that's what we're observing. So as a result, we sort of thought that we would have more -- less of a seasonality benefit in Q3, and that's what it's transpire. When it comes to Q4, two things to keep in mind. One is that we told you in December that we expected to see a seasonal holiday slowdown that plays out through December and January. That's usage-based like everything else in our model. Usage -- underlying application usages will drive our consumption growth. And we just see application usage take a breather in the -- during the holiday season, and that drives our consumption growth as well. And then another thing that we called out when it comes to Q4 guide, which isn't a consumption phenomenon, but is important as you think about revenues is, it relates to unused commitments. So in Q4 of last year, we talked about several million more than normal unused commitments. That happened because, frankly, that was the last big batch of customers that kind of signed committed deals before macro slow down. And as a result, on average, there was more than normal unused commitments. That was important to call out, particularly when it comes to sequential guide and how people thought about the beginning of this year. But the thing to keep in mind is that we have unused commitments every quarter, it's a normal course of business. It's a minor portion of our business, but it's always there. In Q4 of last year, we had more of it, and that's why we called it out in the context of Q4 performance of last year. Now as you think about Atlas year-over-year growth rate or sequential growth rate for that matter in Q4 revenue. You got to keep in mind that last Q4 benefited from several million dollars incremental of unused commitments and we do not expect that to reoccur this year.

Got it. And you're already answering my next question. So just to tease that out, again, as far as quantification, we haven't gotten anything more specific, but $7 million. And then it is something that impacts your each quarter, but the reason for the call out specifically in Q4 last year was because it was larger than what you guys typically experience.

Yes. And just to be clear, we didn't say 7, we said several.

Several, several. Okay.

So it turns out that the bid-ask spread of several is larger than we thought it was, but as specific as we got it, so we're going to stick with that.

I think you got this, Mike, but just for the full audience, that's sort of the incremental, the several million is the incremental over and above what we kind of normally would have expected or sort of normally see with that, given the dynamics that Serge talked about where you've got people who had commitments before macro slowed down and therefore, we went up as kind of disproportionately more.

Got it. And maybe to tease out one more item on the consumption, but we actually hosted another consumption rev rec model based company last week, who's actually talking about a potentially steeper than expected drop ball in relation to Christmas, because Christmas this year ends up on a weekday instead of a weekend. Is there anything that you guys have seen again -- I'm trying to think because we're all in this new consumption environment, trying to figure out how these holidays flow through these consumption models?

Yes. We haven't specified in terms of the size of seasonality we're expecting to see in Q4. The thing that I would say, though, is our underlying source of variability might be different than other people. And this is where like you've heard Michael and me say in the past, if consumption is not a business model consumption is revenue recognition sort of requirement. And so the driver for us is the underlying application usage. So literally, as you just think of yourself as a person who interacts with apps as a consumer and then interacts with apps in your place of business, you just do less of that during the holidays. You also do less of that during the summer. And then when you're back in the fall, you do more, I mean, which is why you see positive seasonality in the back half of Q3 and that's what we just see around the holiday. So what they do on the week doesn't really matter because people don't work on Christmas or we wouldn't pause it that it would matter for us. And so as long as people are taking vacation as long as they're using those vacations to detach from applications in their life, we see a slowdown in usage and therefore, a slowdown in consumption growth for us.

I do think it's an interesting point, though, Mike, to your comment, and I know a lot of people are trying to understand or [indiscernible] the trends or understand it at a deeper level. And without standing up on our soapbox to Serge's point, just because it's a common reference model, it doesn't mean that the business model is the same. And so I think for any company, it's a good idea to sort of ask that question or probe further and say what is driving that underlying usage in consumption, right? And so for us, to sort of this point, I don't think it happens topically a matter of time where Christmas falls in terms of days of the week. And for others it may, right, if you're -- if it's -- if the consumption is driven by analysts deciding to run queries and those analysts are on a holiday or not on a holiday or this that or the other thing like that will all affect things just like -- but ours is at a more sort of fundamental read-write-transactions in the database. And the beauty of having as diversified the portfolio as we do, is you can't just pinpoint and say, "Oh, it's this one thing." We're all about e-commerce and so we get this bump here or this low here, we've got a portfolio of applications not just given the size of our customer base, but given the breadth of use cases, but it does have some of these underlying seasonal trends that Serge is talking about.

Got it. And two points I'd like to highlight with respect to, I guess, population of workloads as well as the Atlas versus EA. And so first on workload population, what I'd say is like while the growth of underlying workloads was impacted by this macro downturn over the last 12 to 18 months, right? I think management has been consistent in saying that the number of net new workloads being brought to MongoDB has been relatively consistent or persistent. And so where I'm going with this, is it fair to think that there's this large volume of orphaned applications, if you will. And so if the macro were to improve or the consumption environment were to improve, that is this cohort of applications should torque higher at the same time like you get a springboard effect naturally. Is that a fair characterization? Or is that maybe overstepping or mischaracterizing?

So I think -- I don't think of us as having orphaned applications or certainly not having -- if I follow the logic train, more orphaned applications as a result of macro. Here's some way that I would describe it and the way that, we've talked about it is that we have done a good job despite the more challenging and uncertain macro environment and continuing to win new workloads. The value [indiscernible] resonates and we continue to bring those new workloads on board and have been satisfied with that progress. The growth of existing applications has grown more slowly, and that's this read-write underlying usage dynamic that we're talking about that sort of macro affected. And in the shorter term, when you think about a large installed base, in the shorter term, the results will be much more dictated by the growth of existing applications than the impact from new workloads that you win. Over time, right, if you take a 5-year time horizon, it's going to be much more affected by the new workloads that we're winning now over that time period than the growth of existing. But in the short term, we grow the existing sort of outweighs that. We haven't seen a dynamic like I said, that would lead to some sort of like orphaned application or whatever. And if you want to explore that topic, we can definitely talk about it more. But that's not something that we've seen. Certainly, new applications, new workloads or applications -- and so while they ramp more rapidly than your average application, they grow more quickly in those first couple of quarters than an existing application. They are macro affected, right? And so they are growing at a slower rate than on quarter X than a new application would have pre-macro, right? And so that's a dynamic. And certainly, the last thing, and maybe this ties to your kind of [indiscernible] question or part of the question or whatever, but is we've sometimes been asked about inflection points and reacceleration and things like that. And I think what we've seen is we've been in a pretty consistent and stable macro, and so to point to an acceleration from here, I think you have to believe in an improvement in the macro, there are other scenarios as well that can lead to that. But for this conversation, the one in some of the most relevant would be an acceleration of macro. We haven't seen the macro get better. We haven't seen the macro get worse. So we have no reason to call that when we think about our guidance, that hasn't been a call embedded in our guidance. And obviously, we'll continue to monitor things, and in March, when we give our full year outlook, we'll kind of update it with the latest that we have done, but that's kind of how we think about it.

Okay. And again, on the Atlas versus EA that I wanted to address as well. And again, I just want to make sure I'm not mischaracterizing this. But like when I look at customers that are bringing workloads on to EA, I think management has been consistent in saying, "Hey, we're going to meet you wherever you are in your cloud journey, yes." Like my view is that if you're bringing a workload to EA, it's just an on-ramp essentially for workloads over the long term that are probably eventually going to end up on Atlas. And again, is that fair? Or do you say, hey, there's regulatory constraints or maybe it's just a modernization effort that's not necessarily the case.

That narrative that you're describing of sort of EA increasingly being viewed as an on-ramp to the cloud. I do think is correct. That doesn't mean that 100% of workloads will move to the cloud, right? You can talk to different customers and that there are plenty that are still on-prem or mostly on-prem. We shared at our Investor Day the ARR from our top 100 customers, and we kind of broke it down into who is mostly EA, beating 80-plus percent of their ARR is EA or mostly Atlas, 80-plus percent or more of their ARR with Atlas. And 85% of the dollars are one or the other, right? And so people -- while there is an increasing hybrid world and those kinds of things. The people who are running EA really are not in the cloud, they are concerned about it. To your point, it could be for regulatory reasons. There's a whole longer list of reasons, could be data privacy, government sovereign, a whole long list of reasons. And in those places, can you find developers who are frustrated that they can't modernize or do things? Absolutely. One of the ways that they can start to modernize is by picking MongoDB, right? And even if they're still running it in an on-prem fashion, they're doing a bit more future proofing and they're getting closer to their ultimate end goal for whenever they can kind of adopt public cloud. And I think we've also seen that evolution in the other way where maybe a few years ago, moving to the cloud and modernizing were viewed as a little bit more synonymous than they really are. And I think people realize and understand that sort of adopting the cloud is just sort of one aspect of that. And then there are many other aspects to modernizing. And so we see people pursuing it in all different flavors.

Okay. And shifting over to product now, right? So I think Vector Search is the first one I wanted to tackle. MongoDB announced that Vector Search was in preview in June. In our view, I think one of the things that MongoDB strikes to say is you guys have done a great job. Let's say, featurizing or integrating newer technologies as they become available, right? And that's kind of established you guys as a general purpose database. Atlas Vector Search became generally available in early December. Just to start off with there, but how has customer feedback been? And then secondly, have you guys thought about maybe the percentage of customers that Vector Search is applicable to? Anything you could do to frame that out?

Yes, maybe I'll take a first step at that. So what we've said really even before GA, which was early December, so a few weeks ago, is that we've been very pleased with the feedback that we're getting from customers. And incrementally, what I would say is pleased that there's been sort of like a third-party validation of that feedback. So we mentioned the retool survey, but there are sort of other things we've heard indirectly from people that gave us the highest NPS score of all the Vector Atlas products. And that was because -- sorry, that was before we went GA. Now you might ask you, that's an unusual state of affairs, right? The most like product isn't actually yet even generally available compared to all the other alternatives that are out there. And I think that fundamentally speaks to the value proposition that we're bringing to the table. And the value proposition is the simplicity of working with our Vector Search offering because it's seamlessly integrated with the operational database. And that demonstrates -- that speaks; a, to the value of the product, but indirectly speaks to the pain of having to stitch multiple individual services together to create this offering, which if you're going with stand-alone Vector Search solution, you would need to be doing, right? So I think that the validation that we're getting is for the work that we've done, but also for like really understanding what is the pain point. And the pain point is operationalizing this and making it easier for the developer to actually deploy and get some value from it. I'll just maybe side bar before I get back to Vector Search [indiscernible]. What I particularly like about the retool survey and the fact that it kind of demonstrates sort of the value of our product market fit and sort of the specific value of our value proposition is that it actually applies more broadly, sort of related to your point, to other things that we've added to our portfolio, whether it is traditional search, whether some of the stuff we've done at the edge, whether it is analytics. Ultimately, customers don't want to have these multiple point solutions. They don't want to deal with the pain of integrating them in the background. And ultimately, the developer data platform vision is all about making the developer jobs easier by solving more and more of the developer problems that relate to data in the sort of behind a single pane of glass and sort of with an elegant developer experience. And it's kind of great to see that, that value proposition resonates in a space that is particularly a focus to customers and investors right now and where we're so early on [ AI ], this was done before we even had the GA. So that's on the traction. The second -- when it comes to like how broadly applicable it would be, I guess the only thing I would say is 2 things. One is it's very, very early days. Most of what we're seeing in AI really sits in the proof-of-concept category as opposed to deployment of actual production applications. That should not be a surprise. And not only is it not a surprise because AI even they might not feel their way to the investor community, it's still a relatively new priority to your enterprise IT executives. Secondly, they are increasingly realizing that their data is not ready to really help them build AI-enabled application. That's an opportunity for us in the long term, but that's like the first impediment sort of to kind of think about a typical enterprise in their data estate. So it will take some time. The thing that we have said, and again, this is exceptionally important, but really in the long term is like we see most absolutely one way or another be AI-enabled, whether new ones or rebuilding the existing one, but that's like over a really, really long time horizon, but obviously an incremental benefit to us.

Yes. I think it will become -- this requires a look out in the future and from [indiscernible] a little bit. But if you just think about where applications are likely to go. It won't be the core part of every application to Serge's point. But I think this will be pretty common feature functionality, and we've used the example that there was a point in time when indexes from a database standpoint were innovative, right? And then they just became used as part of everything, and this has an aspect that's like a reverse index. It will be used in every single application will be the core of every single application. But I think it will be pretty foundational over time to just how applications are used much like tech search or other things. And so I think how to get integrated in your operational transactional database is an advantage for us.

And probably more of a tech-based question, like a 2 quarter though. So when a customer brings a workload to MongoDB for Vector Search, like when is the data being vectorized? Is it upon ingestion? And then the second part is like when is the embedding model then being employed? Is that like when the query is being called? Again -- sorry I'm just trying to figure out how this process flows.