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

Welcome to our next section. Great to have the 2 of you on stage. Given that we just had Q3 results, maybe we start with actually like summary from both of you, like how do you see the quarter play out? Like what it highlights from your perspective?

Yes. Maybe I'll start and you can add some color. We feel good about the quarter. We beat on the top and bottom line. As we said, consumption was slightly better than our expectations. We obviously were the beneficiary of some a few multiyear deals on EA. I think EA speaks to the attractiveness of our run anywhere strategy, where customers have the optionality to run workloads in the cloud, on-premise, move workloads from cloud to on-premise and that's very attractive to customers, especially large enterprises who have very hybrid environments. And retention rates were very strong. Some people noted our NDR was at 120, which I think some people were surprised by. So we feel the fundamentals of the business are very good.

Yes. Good quarter. As Dev said, strong new business, both on EA and on Atlas. And then within Atlas, the consumption trends were slightly better than our expectations. So all in all, a very good quarter.

Okay. Perfect. And then you called out the multiyear deals, and I wanted to stay on that a little bit. It's like when I talk to investors, it was like, Oh, there's multi-years," but that's a positive thing. Like can you kind of speak to you a little bit to that. And I think it was in both within EA and the other revenue a little bit, like I don't know if you have more color there.

Yes, sure. Happy to talk about that. So yes, so the EA business, first just we take a step back, we run the business on a channel basis, right? And customers have an IT strategy. They have a point of view on how they want to run their applications. And so MongoDB coming in there and saying run this in the cloud or run this self-managed or whatever, really isn't how it works. And so our goal is just to make MongoDB easy for our customers to use regardless of their deployment choices when they're running on-prem in a hybrid model, in-cloud, multi-cloud, et cetera. And so yes, I think it's generally a good thing. I do think people tend to sort of sometimes maybe over-rotate to Atlas. To Dev's earlier comment, the run-anywhere strategy really does resonate. And so we've seen continued strength within EA. In this most recent quarter, we saw strength EA broadly, but also incrementally in multiyear deals. And so the reason why that's important is from a business standpoint, it's great and a positive to your point, because what that means is the customer is looking ahead, seeing more demand wants to standardize or invest more in MongoDB. And so rather than signing a year-to-year deal, they kind of want to lock in some certainty because they've got conviction in MongoDB as a platform. And so that's a good thing for us. And we continue to see that. The reason why it matters and affects the numbers is because of the accounting and ASC 606 we're required to recognize the term component of the upfront, I mean, the license component upfront. And so in a multiyear deal, you end up recognizing more. And so just because that affects the numbers both this year, it also increases the variability and reduces the comparability in effect kind of the year-over-year numbers. I mean that's why we kind of talk about it a little bit. And when helpful quantify it to help people be able to kind of piece part things together.

But it's like it's -- you're on the license side, it's not like -- I mean, if I remember correctly, you were like 20% 20%, 25%...

It's about a quarter upfront. So if you just want to simplistically think about if you did the 3-year deal, right, versus a 1-year deal, if you had a 1 year deal, it was $100. You'd roughly take $25 upfront and the $75 over the remaining 12 months to contract, where we had the 3 deals, same concept, $100, $100, $100, let's not have a ramping deal or add the complexity here $100, $100, $100, you recognize $75 million upfront and then that remaining $225 would go over the 36 months. And the reason why that's important is because when you think about the comparisons, I think generally, you all are very good at understanding what it means in terms of the base period, right, and what -- how the denominator has changed. But I think what sometimes people forget about is the numerator doesn't have that term license component that it would have in year 2 and year 3. And that's what makes some of the comparability hard. The last thing, Raimo, to your question on sort of the EA versus the other, other or non-EA, non-Atlas, what we talked about is we talked about seeing more than $15 million of multiyear in this Q3 versus Q3 a year ago really just from a few deals. One of those deals will show up in that non-Atlas non-EA. And while most of our deals, whether they be Atlas or EA deals, are 1-year deals that kind of OEM licensing, kind of other category is probably the 1 area that sort of structurally is oriented to multiyear deals. We've talked about Alibaba as an example what's in there. This quarter Alibaba is not what was driving it because they [indiscernible] because that's one that's been named, and they did a press release on. It doesn't make sense for them to do that 1 year, right? They're offering them an authorized MongoDB as a service offering and so they want to have multiyear certainty and access to our intellectual property.

Yes. And then on that theme, like we talked about EA being stronger last year, and I want to kind of link it to theme of like app modernization. Is that kind of actually not kind of linked that people want to start to modernize the applications. And yes, might go to Atlas, but they might want to do it in-premise as well?

Right. So just stepping back, so why do customers want to modernize. So you have to remember, a large enterprise may have over 1,000, if not 5,000 or 10,000 plus applications. Some of these applications were built 10, 15, 20, 30 years ago. And now they're looking at their architecture, a lot of those legacy applications have a tremendous amount of technical debt, so it's very hard to innovate. The cost and tax of managing and supporting those applications is very high. And for regulated industries, the regulators are saying there's a systemic risk of being reliant on these legacy applications that need to be modernized. There's some end-of-life issues like Sybase announces going end of life. So a lot of customers are having a "Oh my God moment," of like, I can no longer kick the can down the road. And so there's a confluence of events where customers are very interested in figuring out how to modernize. The biggest challenge in modernizing is not moving the data, it's not mapping the schema. The biggest challenge in modernizing is rewriting the application because there potentially hundreds of thousands if not millions of lines of code, and that would take a lot of man hours to basically rewrite on a new platform. That's where GenAI comes in. All of a sudden, people say, now with the use of GenAI, I can do a few things. One, I can analyze the existing code because in some cases, those developers are no longer in the firm. So they don't even know what that code does so they can analyze the existing code. Two, they can then generate tests to really understand what does this code do and based on this input, what outputs are generated, that's very important because when they reproduce new code or generate new code, they can then use the same tests and say, do those -- does the new code do the same thing as the old code because no one is going to migrate if they can't have certainty that the new code does what it's supposed to do. So all that work, which is very tedious, mundane and labor-intensive, all of a sudden can -- a majority of it can be automated, and that's creating a lot of excitement and interest. Then the question is if I'm going to migrate why migrate to MongoDB. Well, people see it's a much more modern architecture, much more saleable, much more flexible, easier to iterate on. Not every app will go to MongoDB, and it's not like we need every of those thousands of apps to move to MongoDB. But a meaningful portion goes to MongoDB that will really drive long-term growth for our business. So we are very excited. Now the sales process has multiple stages. First, you have to prove you are we selling snake oil? Or is this real? So we go through a proof-of-concept process with the customer, typically scope somewhere roughly on 3 months, I'm not sure, some are longer, but that's roughly time to prove can we do actually what we're saying because people want to see on their app with their own developments, people and all that to make sure this is real. So in many cases, some of those POCs have actually stopped because they've seen enough evidence say, you don't show me more, I'm ready to go. The second stage then is like, okay, which -- how quickly do we start? Depending on the app, like for example, we have a large global insurance provider who wants to rewrite their whole underwriting platform. And so they're starting because it's a global platform and runs in every -- almost every country they're in, they're starting with some countries in Southeast Asia, making sure that, that works before they deploy it to Europe and North America so that will be a multiyear process, but we should start seeing revenue from that in the next 6 to 9 months, if not sooner. There are some other apps that are smaller that we may see revenue sooner or may take longer depending on the variability of the app and how long it takes to migrate, we're seeing a high demand from large enterprises, financial services firms, insurance firms, telecom companies, everyone is saying this is a big, big problem. And so we have a high conviction that this is a big opportunity for us, and this unlocks a big part of the TAM that we really could never go after because the cost of switching was just too onerous for companies. We had lots of customers migrate apps, but like there's some apps that people just felt like it's just going to be too hard to do that with GenAI that's taken that off the table.

And I heard that from the industry as well that like database migrations are going to be so much more easy. Like how much can you influence that in terms of providing the GenAI and the tools to that? Or are you just basically an outcome like and then you need to pick a database.

So one of the things customers like is -- and is that they -- incentives drives behavior. Our incentive is to move that app of the legacy platform and run on MongoDB. Our incentive is not to have some long elongated services engagement where we bring in the army of people so customers like that they are motivated and modernized as fast as possible. So are we. Obviously, we'll see an uptick in services, but that's not why we're doing this. We're doing this to drive more incremental ARR from these legacy applications and so customers are like that. We will obviously use a combination of our own services people and partners because we just can't build out capacity that quickly.

I meant more on the tooling side, like on the GenAI tool. I mean, are they like I get conceptually that you can use GenAI for that, but like are we -- where are we...

So we are using a combination of open source tooling and third-party tooling. We've looked at all the -- we've valued a number of the code generation tools. We've gotten feedback, the code generation companies are super excited because this is one of a very compelling use case like decomposing an Oracle app with Oracle store procedures is not for the faint of heart. And they're realizing, okay, this is hard, but it's also going to be a big, big opportunity. And so we're working with a bunch of them, and we're obviously pick and choosing which tool makes sense for which engagement. On top of that, we're building our own tooling because, obviously, we're optimizing it to migrate to MongoDB, so either we're using those tools and train those tools optimized for MongoDB or using open source ourselves. And so we have a whole engineering team focused on this endeavor. We have some field engineering people who are also working with our services people and the people on site to understand the learnings. You have to understand that this is a wide big but wide highly diverse problem. There's multiple database types, versions, libraries, programming languages, development techniques that can run the gamut. So it will be impossible for this to be like a 1 easy button, press this button and code is regenerated. There will be a combination of services on top of that. But over time, that services component should come down.

And then going back, Michael, now I put you on the spot, like my patch project or not my first one was like last year, we started talking about EA actually being stronger than you had guided and then was part of that was people wanted to start modernizing? Is that -- like if you think about what's going to happen more now? Is that going to be like an Atlas or EA or both? Like how do you think that?

Yes. I think we see it in both, and we've been talking about for several quarters now to sort of move up market. I think some of that will be in Atlas for sure, but some of that will be in EA as well. And so we've continued to see strength in the EA business for the last few years. Obviously, there is some variability with the multiyear, and we'll keep close and call that out. But a lot of the work on app modernization is in the cloud is Atlas. But as much as we talk about cloud and things like that in conferences like this, the reality is there are a huge number of organizations that have most of their applications still in a self-managed or on-prem environment. And so I think it will show up in both sides.

Yes. I mean, to that point, I mean, a lot of European banks have been very slow to move to cloud. So if they're migrating, they're probably migrating to EA so that's 1 example.

Yes. Okay. Let's shift gear a little bit on -- let's talk about Atlas a little bit. So like if you look at the industry, we have like Datadog coming after you, et cetera, like all the guys that are kind of like cloud, cloud needs and their offering, all kind of slowed down somewhat in the downturn and it's like optimization, less traffic for some of the digital needs, et cetera. If you think about your Atlas business, like I saw it more positively because you kind of almost -- we're kind of stabilizing in the growth rate. And yes, Michael is still guiding for slightly slower growth in the coming quarter. But like how do you think about the Atlas kind of story for you?

Yes. So I think this is a tendency to think about or try to think about patterns and do pattern recognition as investors -- yes, exactly. And people hear the word consumption and they say, okay, all these companies must be the same or must have the same dynamic. And to your point, the dynamic is a little bit different. And so it's obviously easiest for us to talk about what we see in our business. And obviously, to the extent we could be helpful in comparing addressing what our best assessment of what others because we do try to pay attention including to help inform or stitch these threads together. So what we see is we see an incredibly tight correlation, incredibly tight relationship between our consumption and the underlying end user activity of the applications built on our platform. So let me elaborate on a couple of those things. When I talk about consumption, we talk about consumption growth, we talk about consumption trends. What we're talking about is the week-over-week growth in the underlying Atlas MRR basically, right, or ARR, however you want to think about it. And that, as I said, very closely matches the underlying -- obviously, there's some variability, but the underlying reason rights in the database. right? And so the activity is driven based on how I'll use a generic word, but how popular the application is and whether that's an internally facing app with a customer, whether that's a revenue-generating app, whether that's a partner-based app, it will be that interaction with the database, those reads and rights that will affect and drive the underlying growth. And so what we've talked about we're probably 1.5 years now is we saw a step down related to the macroeconomic environment of slower growth in those reason rights, right? And that's really what's driving our behavior and what we see.

And then the -- I want to get to go-to-market changes a little bit. Like -- but you talked a little bit so that's the existing customers doing more with or more or less depending on where their business is going. But then you can further influence it by kind of adding new workloads.

Yes, right. That's the dynamic of an existing workload and the way we talk about the business is there's new business that we win and kind of each quarter, and despite any of the macro challenges that I think we've done a really good job of kind of threat and that shows up both in EA and in Atlas. And we've had successful execution pretty consistently in winning new business. The dynamic that I was talking about in terms of that consumption growth that's the existing workloads that are once on the platform. And the reality is very little that we can do about that. The other thing that we've talked about, and maybe this is helpful in the compare contrast category versus sort of some of the other players that have consumption dynamics is -- for some of those, if you have -- we kind of put ourselves in the shoes of the customer, right, if you have a runaway bill in some of those other players, my first instinct is how do I optimize that, right? How do I improve? How do I reduce my spend, et cetera, et cetera, where is the more typical dynamic in MongoDB if you had a runaway bill on Atlas, it would be because your application was very successful. That would be sort of the typical pattern, and that's part of the way that our dynamic, particularly as a consumption player is different.

And so if I summarize it, so basically, you have 2 components. You have the existing and they are the workload, not the workload, the growth within the existing wasn't. The new is basically there was no change basically consistently kept that in.

And again, maybe it's too simplistic of a framework, but we've talked about it this way with you all before, which is sort of like the things that we can control are the winning of the new business, right? How the application grows after that isn't -- there's not a lot that we can do to make someone's internally facing app more successful or the revenue generating app more successful. It's kind of like how we've talked about the AI applications that we have on the platform, like not -- a lot of them are struggling to find the product market fit because we're still early on in that cycle. That's not something we can help them with.

And then so at the beginning of the year, you talked about like kind of headwinds you guys were facing and there was -- one of them was when you kind of started to compensate your sales guys. That was, I think, the year before on consumption. So then like if growth slows down, everyone tries to find an excuse or like find an explanation and sort of with a lot of like kind of focusing on that go-to-market changes or compensation changes. Can you speak to that? Like is that kind of what program there?

Yes. Let me just explain. So when we originally kind of went to kind of what we call all-in on consumption, which is really encouraging our salespeople to find as many workloads as possible. We assumed a portfolio theory of like as long as they acquire a large number of workloads, there will always be some workloads that start growing very quickly and be net positive. As we examined our results from last year, we realized that the reps do have some influence about what workloads they can go after, sometimes a more complex workload will take longer to sell, but that may have higher growth prospects than just another workload. So we made some slight modifications in the comp plan to put more weight on the net new ARR component of the workload versus just winning the workload itself like there was a net new era, but we just weighted it slightly more. And we are seeing, it's early days because you don't really see the full trajectory of these workloads after a couple of quarters, but we are seeing that the size of the workloads we're getting this year are better than prior years. And so -- but it remains to be seen of how they grow. And as Michael talked about, a big part of that is how the underlying usage of those applications grow. So that was one change. What we announced in terms of go-to-market changes was, I think there's a lot of investors who thought they were more disruptive than really are. Obviously, with Michael's pending departure, we moved a part of his COO functions under Cedric Pech who was our CRO. And we basically elevated his title so that he now owns really 2 more functions. One is the presales engineering team and the professional services team. And under him, there's a gentleman who ran North America and Europe who are -- we're not promoting to CRO will own all the global sales teams. So that's really the change. And to me, this makes sense given moving some of the COO functions under Cedric and just the way we're organized going forward. So I think people overinterpret that there's some big change in our go-to-market.

Yes. I would just add to that because the other thing that we came up was we were giving people an update on the priorities we laid out at the beginning of the year, one of which included moving more upmarket or prioritizing dollars upmarket. And I think people read that as an in-quarter or a prospective change and didn't understand that, that was something we were kind of just checking in on a couple of quarters in from something we've said beginning of the year. And so I just underscores what Dev's saying is there hasn't been some sort of major pivot in the way that we've picked up a little bit over these last 1.5 days or so.

And then the other question that came up is like at the beginning of the year, I think you talked about $40 million of headwinds. And now the question right, I guess, is right. But it's like if I kind of adjust for that out like so how is Atlas growth doing if I kind of adjust that out. I don't know if you want to speak to that.

Yes. No, I'll try and tackle that and at least do a little bit of marketing that to market and then also recognizing that we obviously won't give fiscal '26 guidance yet. I know people are sort of updating their models and so it can at least give like a couple of markers for like how we're thinking about it and things to sort of pay attention to. So in the fiscal '25 guide, you're correct, we really talk about and quantify 2 specific headwinds. One was in the move away from upfront commitments, we expected to have about $40 million less, i.e., 40 going to 0 or near 0 of unused commitments kind of going away that we benefited from in fiscal '24 that we weren't expecting to in fiscal '25. And so that has been playing out as expected, and that will be a headwind that gets removed when we go into fiscal '26. The other headwind for fiscal '25 that we quantified was roughly $40 million. Unfortunately, it's basically the same number, which is mildly irritating but because it leads to some potential confusion, but was -- we recognized roughly $40 million more of multiyear deals in fiscal '24 relative to fiscal '23. We talked about the surprise in strength of multiyear deals in fiscal '24 and driving some of the outperformance that we saw in fiscal '24. And so our assumption coming into fiscal '25 was at fiscal '25 would look more like fiscal '23. What we talked about just on Monday's call was we've continued to see success of EA, yes, broadly, but also specifically on multiyear, and we talked about seeing more than $15 million of more multiyear in Q3 of this year than we did last year. And so if you're sort of kind of marking that to market. That basically means the $40 million headwind is more like $25 million and then as that relates to fiscal '26, we'll kind of have to see how that goes as we finish the quarter and everything else. The third thing I'd call out is we have talked about Atlas consumption, right? And again, that's sort of the week over week, and so it ignores the unused commitments and everything else, not a revenue number, but it's a consumption number, has been decelerating, right, is lower on a year-over-year basis, and it will be -- and our expectation is it will be lower in Q4. And so that's a factor to keep in mind for fiscal '26. And then the last thing I think sometimes people forget about, but it's quite important is now we have the performance on Atlas, the consumption growth of what do we see in Q4? How does this holiday season compare to other holiday seasons, we typically see a slowdown and so the way that the consumption results for Atlas in Q4 play out will be important because that really sets up the starting ARR of fiscal '26. So those are kind of some of the things to think about.

Yes, yes, You still didn't give me a '26, but okay. Yes. Fair enough. Okay. So we can all adjust that. Dev, now that we have you here, we need to talk about AI a little bit or GenAI a little bit. If you think about it, like there's a big debate like how does it impact your industry and maybe I'll start extra debt broadly, and then we can kind of narrow it down like from your perspective, you're a database vendor, what should it mean to you?

Right. So I think generally, and I'm thinking like zooming out, I would say AI, by definition, will be a tailwind for our business for a couple of reasons. One is that if you look at every platform shift, the cost of building applications come down. So that from mainframe to client server, client server to Internet and cloud and then mobile. So we just saw this explosion of apps. The more apps you have, the more databases you need. So that's one. Two, we think that architecturally, we are the ideal database for GenAI applications. Why? One GenAI applications need to be able to query rich and complex data structures like semi structured, structured and unstructured data, we're optimized through that. GenAI workflows need to elastically scale, we're designed to do that. They need to perform at a high level. We're designed to do that. They need to be able to make changes very quickly. We have a very flexible and agile schema. We're designed to do that. We can -- we have very sophisticated ways to do aggregations and very sophisticated indexing mechanisms. We do that. We bundled in vector functionality into -- we don't have a standalone vector database. Vector is bundled into our platform. So as you need Vector embeddings and be able to search and do nearest neighbor kind of queries using vectors that's built into our platform. So as 1 customer said, rather than having an OLTP engine, a search database, a vector database and maybe a caching database, I could do everything in MongoDB. So architecturally, we think we are well positioned. And the other thing is also real time, right? So a simple example would be, say, you have an AI chatbot, you just put it in order. You never got a confirmation that the order went through. You go to a chatbot saying, "Hey, what's the status of my order," that chatbot needs to have access to real-time information, not historical information from weeks ago, but literally what you did minutes ago. And so the real-time nature also we're designed to do that. So from -- and then we are the world's most popular modern database, developers love using MongoDB. So given all those things together, we think we're well set up. And the third vector is no pun intended, is going after legacy app monetization, right? Because that was, again, a part of the market that was structurally hard for us to go after just because the switching costs are so high. We just talked about this. But that we think was going to -- GenAI is going to unlock that market opportunity for us.

For us, it's difficult because you have a lot of techie guys and because it's a new world, everyone can make bold claims. And so it's -- and for us, we're sitting here and we don't know. How do you think of like obviously, the one with the boldest claims at the moment, like -- and actually, they are mostly tiny little startups, it's like postgres that comes up a lot. How should we -- what should we look at? Or like how do you see this going and play out?

So one thing I would say is one of the things postgres is the beneficiary of is that people are standardizing on Postgres, off Oracle of SQL Server and of MySQL. So Postgres is kind of becoming the standard relational database. But relational databases have 2 intrinsic challenges. One, the data model is not very agile. So it's not -- because it's hard to make changes because you have to use this very tabular structure. And it's not very natural in terms of how you work with data because you have to decompose programming objects and your programming language to data across a bunch of different tables. And that's a cognitive low, is called an ORM process that developers have to deal with. The second challenge is that relational databases are not designed for performance and scale because they're designed to be single node systems. So in the old days, you just buy bigger and bigger machines. Now people do some funky things to kind of make it more scalable, but it basically says like there's a constraint architecturally. MongoDB addresses both those issues. That being said, we don't view like Postgres has to die for MongoDB to succeed. It's not a zero-sum game. The market is huge. We're seeing a fair share of business. Obviously, if you're a SQL developer and all you know SQL, you're going to probably have bias to postgres. What we found is that even in our largest accounts, it's kind of eye-opening for me over the last 6 months was that, I'll give you a simple example. We had a financial services customer who grew from $1 million 2 years ago to $22 million in about 24 months. So pretty impressive growth, but when I was talking to an account team, there's still a very small percentage of developers in that account who know MongoDB, right? It was just shocking to me. And it just tells us that the wallet share we have in these large enterprises are still very, very small. And so the more education we do, the more we help them think about like for the next application, how they can model that in MongoDB versus relational, it unlocks more workloads. So that's part of the move-up market is to deploy not necessarily all quota-carrying resources but more technical resources to just accelerate that education and enablement effort on MongoDB and so the point being is that we see a big, big opportunity and I don't expect every workload to go to MongoDB, but the workloads that require a lot of agility, a lot of innovation, maybe performance and scale, there are ideal use cases for MongoDB.

Perfect. And I think our time is up. That's a good closing statement. Thank you Dev, Michael.

Thank you.

Thank you.