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

Good morning, everyone. I'm Brad Reback with the Stifel software research team. Thanks again for joining us in the room and on the webcast with us. Next up is Mongo, Michael Gordon, COO and CFO; and Serge Tanjga, SVP of Finance. Gentlemen, thank you.

Thanks for having us. Great to be here.

Thank you.

Thank you. So since you guys hosted an Analyst Day yesterday, which unfortunately I couldn't be there in person.

Understand, of course.

Maybe for the group who probably also couldn't be there in person here in the room, you could highlight a few of the key takeaways that you thought were most pertinent.

Sure. Yes. So first of all, it's just great to have everyone back in person. Obviously, we had a live stream to that as well, but it was sort of a packed house at the Javits Center, which is sort of a step up in terms of audience in attendance and the enthusiasm was great and sort of the developer angle, and I think it's first year we had an executive track as well. So it was really just wonderful to sort of be together. A whole host of product announcements, obviously happy to get into any of those and as many of those as we want. But really, the macro backdrop is the database market and what we introduced at the user conference is a sort of developer data platform, is a little bit different than most markets in software. And so if you think about it and with sort of my investor hat on or potential investor hat on and you all are sort of experts at pattern recognition and looking at software markets, the database market is a little bit different. It's less monolithic than most markets, right, if you're an HRIS or a CRM or an ERP, you sort of win the whole account and your unit of competition is the account, is the customer, and it's sort of binary, they're a customer or they're not. And you're sort of locked out of the account until the next renewal cycle, and you hope to have a shot to get in. And databases are different, right? Every application has its own database that's sort of the core. And so you have this much more opportunities to sort of compete for workloads and the basis for competition really is that application or is that workload. And so with that as backdrop, a lot of what we announced at MongoDB World and part of the reason why we're so excited about it is making it easier to win more and more workloads within an account. So we talked about expanding the use case footprint -- and so going -- further extending our reach in terms of search and time series. We talked about relational migrations, right, and winning incremental relational migrations. And then we also talked about winning -- making sure that MongoDB is kind of continuing to evolve as a platform as new architecture approach has come out. So we talked about serverless and edge computing as well. And then within new workloads, we have talked about analytics. So a wide range of things that were all like pretty exciting because for those who don't know the story, we're going after this massive addressable market, one of the largest in all of software, $85 billion in 2022 per IDC's estimates. And so while we're now over $1 billion from a run rate perspective, we've kind of just crossed 1% market share. So a lot of opportunity ahead. And so that was sort of part of the kind of macro theme of everything.

So a couple of questions from there. Just broadly, as you sort of talked about all these product enhancements, as you look at your product road map, is there a 3- to 5-year plan? Is it a 1- to 3-year plan? How far out do you sort of sketch that?

Yes. So it's a multiyear plan, although we don't always broadcast all the components of the plan. And we're constantly iterating on what it is in sort of making various trade-offs. I think one of the great things about having this large market opportunity is we get a lot of customer feedback, right? And when you think about the core database, we'll probably never be done with that, right? I mean, Oracle's 40-plus years old and still continuing to add and innovate. So there's certainly lots of work to do there. But what we've really done is we've been customer-driven in terms of the feedback. And so if you think about our evolution into areas like search and time series and things like that, that's coming in analytics and everything else. It's coming from direct customer pull them saying like, "Hey, this is great what you've done for me, but can you do more? " Right, and trying to respond to that and continue to evolve the road map. And so we've been very thoughtful and intentional about that. Then obviously, we revise and test and iterate on our thinking around that. That's sort of a multiyear view and vision that we have for where we're going.

That's great. One of the announcements I thought was pretty permanent yesterday was this relational migration tool. Obviously, since before the IPO, you guys have talked about a segment of the business, maybe 1/4 plus or minus, if I remember correctly, coming from that. Can this accelerate that? And what are the pain points? Do I have to rewrite the app as well, et cetera?

Yes. So a couple of different thoughts. So just contextually for folks, so that $85 billion that I talked about, obviously, the vast majority of that is relational today. But also, we should be clear that not every dollar of that $85 billion is doing an RFP every year, right? And so these relational migrations and the way that things work is applications have a natural life cycle. The challenge with relational is ultimately it becomes too brittle and too cumbersome, right, too unwieldy for you as the application owner to iterate and innovate in the way that you want to. And so it ultimately hobbles your ability to compete, detract some of your competitive advantage. And so ultimately, you say, I need to rebuild this application much like if you're working with a spreadsheet and a financial model and you're covering Microsoft or whomever and the IBM and they change their segment reporting or they acquire a business to divest a business and you're doing a bunch of stuff on the side with your Excel spreadsheet to kind of make it all work. But at some point, it doesn't work, that spreadsheet is an example and a direct analog to a relational database, at some point that just becomes too cumbersome and unwieldy and so you want to rewrite it. And so there isn't a auto-magical button that you hit and all of a sudden, your application moves from a relational application of MongoDB which is based on a document model. But what Relational Migrator will do is meaningfully simplify that process. Initially, what we've talked about is putting that as a tool in the hands of our technically oriented customer-facing folks. So not a self-serve process to manage on your own, but an easier way to imagine it. And part of what this is really trying to address is there is a paradigm shift, right? Relational has been the standard. That's what -- if you were studying databases and application development 20, 30 years ago, like that's what you were steeped in, and there wasn't an alternative. And so that's what people are comfortable with, and doing things in a document model is a different way and try to think about how do you optimize and leverage the benefits of the document model aren't necessarily intuitive. And sometimes, we've seen people who are migrating from relational are re-creating their same relational tables and schema data structure in a document model, missing the whole point of getting the benefit of a more modern, agile scalable platform. And so one of the things that Relational Migrator can do, and I think we demoed this in during Mark's, Mark is our CTO, keynote in the afternoon was this visual representation, right, of a relational database that has all these -- this schema that these tables of rows and columns and the schema diagrams can get quite crazy. It's like your worst nightmare of like a subway map or some sort of transit complexity. And how that maps the document model and then the streamlining and the simplification that happens, you can see that. And then once someone can kind of visualize what it looks like under the document model, it sort of like lessens the anxiety or the sort of perception of its different kind of things. So it should help in that regard. Obviously, over time, we will add things that will make that even easier for customers to do themselves. But I think initially, it's just sort of to help bridge that gap.

That's excellent and should definitely ease the process there. As we think about easing the process, over the last 5 years, how has the application that a customer has written on top of Mongo evolved?

Yes. I think it definitely has evolved over time. I think if you think about the customer base, it's very diverse in terms of geography, industry, size of customer, et cetera, et cetera. I think one of the things that's really changed, particularly with Atlas, which is our managed offering, our Database as a Service product, really the core of the developer data platform. Atlas is now 60% of revenue. Atlas started off as either cloud-native applications or just sort of smaller, less strategic applications. What we've seen over time is that that's been like a little mini microcosm of the MongoDB trajectory where there were sort of initial apps or you're trying to experiment with something, you understand that relational has got a problem, but you're not going to take your most critical, most strategic application and migrate it off of Oracle or Sybase or DB2 or whatever it's on, you're going to start with a lower risk application. And what we've seen over the last many years now is just the dramatic increase in the number of core mission-critical applications that are running on MongoDB, whether that be on Atlas, in the cloud, or whether that be in a self-managed environment, so you think about critical telco applications, utility billing applications and banking transaction applications, kind of core essential applications. During our Investor Day yesterday, I moderated the customer panel, and we had people talking about the different critical applications and media company talking about basically everything being built within theirs -- Boots, the large U.K. retailer, talking about everything, but their e-commerce application, either built on or being migrated to MongoDB. So we started to see that sort of level of consistency and sort of the mission criticality or the ready for prime-timeness, I'm sure there's some good better word for it, but something like that.

Given that backdrop, would it be correct to assume that there's less sales friction now because you don't have to walk in and convince a customer that you can run a mission-critical app as you can point them to 5 or 10 peers that are doing it?

Yes, but I think it's important for people just to understand this, is we talk about our land and expand and given that market dynamic that I described and the fact that it's not the sort of monolithic market, the expand for us means winning more workloads, which is why these announcements that we announced yesterday, everything else are sort of important in the grand scheme of things. And each subsequent application and workload gets easier, right? You measure it, you can see it kind of shorter cycle times and everything else. And so yes, but it is different than some other models. And again, I think it's important to see that and you can kind of see that reflected in some of our financials. But as opposed to a more monolithic business where the land and expand, the expand part is just simply I've grown and I've added more seats, right? So if I'm Workday and I am the HRSM, the system of record for your HR data, yes, I know they've got additional products that they're trying to cross-sell, upsell. But fundamentally, what the expand is there really comes from, "Oh, you grew your headcount, you have more seats. " And so a renewal like we can have that conversation. That's a very different conversation than convincing new application owners to do that. And so you can see that therefore, that requires the investment that we're doing on sales and marketing in addition to generally just growing out our sales and marketing footprint. So it definitely gets easier, but it's not sit back and let the orders flow in.

You've talked about Atlas. There's Enterprise Advanced. Maybe you can help the audience understand the 2 products -- I mean the 1 product sold in 2 different ways, right? And who the target is there and how that will continue to evolve?

Yes. In terms of -- for us, the -- while we talk about the products and they have different financial characteristics, and we think it's important, particularly given the 606 revenue implications of Enterprise Advanced. We don't really think about approaching the market from a product perspective. We really approach the market from a channel perspective. And ultimately, what determines whether a customer picks Atlas or managed offering or whether they're taking Enterprise Advanced and managing it themselves, whether they're managing it in the cloud or on-premises is really just where are they in their own public cloud journey and public cloud adoption. And so our goal is to make it easier for folks to use MongoDB regardless of where they are from a public cloud perspective. So typically, what that means is large companies, often in regulated industries that haven't convinced themselves that unrelated to MongoDB, that the cloud is secure and things like that tend to be the folks where Enterprise Advanced is more relevant. We tend not to sell a lot of new Enterprise Advanced, right? If you're just starting to adopt MongoDB now, you're probably either a new company or sort of pretty far along in your public cloud adoption and so you'd probably just start with Atlas. And so most of the sales of Enterprise Advanced really are coming from existing customers, and we try and sort of walk folks through that. The other thing I'd say is that the financial differences have narrowed over time. When we went public, of course, there was the 606 difference where because Enterprise Advanced has a term license component that comes out and we've talked about that. But there was also a fairly significant margin difference at the time, right? Atlas includes the underlying storage and compute. And you may want to talk about margins later, but just to sort of give people the broad picture, and so therefore, it's a lower-margin product. We've made a lot of progress on the margin front. And so that difference has narrowed significantly. And so the bigger impact now in terms of just sort of transparency and thought process and guidance and just understanding the company tends to be more on the revenue piece and the fact that 606 introduces that sort of increased volatility and kind of reduced comparability period-to-period whether sequentially or year-over-year that we're just trying to help people understand.

On the margin front, since you went there, I think it was 2 quarters ago, during an earnings call, you had talked about if someone had said that Atlas would be this profitable, I'll use the word [ tariff ] raise a little bit. You would be surprised. So as you think about the journey over the last few years, how much of it's been the scale you've achieved in being able to get leverage with the likes of AWS and Azure versus the internal efficiencies from architecting the product in a more efficient way?

Yes, there's some of both. I think the -- we have gotten a lot out of the kind of size, buying power, efficiencies, whatever you want to call it, that has a couple of different flavors. The biggest, most obvious flavor to your point, is just you can go to the different cloud, but you say, look, we're buying a lot, we deserve a bigger discount, right, and that sort of reflects through. So that tends to be a more step function, chunky, lumpier piece around that, and we've certainly benefited from that over time. But once you do that, you kind of have to grow into it. These are not deals that you're renegotiating every 3 months, and you've been very astute and attentive to our filings in the 10-Ks and everything else where you've called out some of those things. And so I think that's sort of one of the factors. There's this other factor that's a little more operational, maybe a little bit more in the weeds than we typically go into this audience, but maybe it's helpful is generally what I refer to as a route density, right? So as you think about separate from by big macro deal with any of the big cloud players, you can incrementally buy committed capacity and get discounts on those, right? And then you've got discounts on top of that, but like as opposed to just sort of spot buying basically. That can happen at a fairly granular level, and as you think about instance types in a specific geography, et cetera, et cetera, as you build out your routes as Atlas gets bigger and bigger, you can start to say, okay, we now have enough workloads in this region that I feel comfortable committing to x capacity as opposed to, well, there's not that much activity in this instance family, in this geo out of this availability zone or whatever it is. And therefore, I don't want to commit to the capacity, if I'm not confident that the underlying usage is going to be there, right? And so as you build out that right density, you also pick up stuff kind of from an incremental basis. We also have done things internally both from an architectural standpoint as well as from a support standpoint. So I think that's been helpful. And then the last piece of the puzzle ties back to one of my earlier comments around the uptake of enterprises and how quickly and successfully they've responded to the Atlas offering because they tend to buy the more premium packages. And as you think about the premium packages, those tend to have other attributes on top of just the storage and compute and the database layer, including things that have more software-like margins. And so that's also accretive to the overall picture.

And on the premium pricing, maybe just extending that, would it be correct to assume that while Atlas is a consumption model, a lot of that is under at least a year commit or a multiyear commit as opposed to month-to-month?

Yes. So the most customers, certainly most direct customers, I think all direct customers, sign annual contracts, obviously, of varying commitment amounts. Self-service customers, which are a little over 20%, are month-to-month credit card in arrears. And so -- but most of the business is transacted with [indiscernible] and almost all VA is with direct sales customers who are signing annual contracts. People tend to commit to less than they would expect to consume just because given the nature of the commitment, it's a hard and fast commitment. And so I probably want to have some confidence that I'm going to use everything I've committed to.

Got it. Talking about self-service customers, obviously, in the most recent earnings call, you highlighted some of the slowing -- moderate slowing in European and then so maybe highlight that. And then just one thing, given your comment on the arrears portion, since it occurred in April, a bigger impact to the month of May than it would have been to the month of April, the slowing. Would that be correct?

Do you want to...

Yes, let me take that. First, as Michael was saying, we look at the business on a channel basis and usually and in our filings, as you know, we talk about the direct business and in the self-serve business. But occasionally, it's sort of helpful to additionally split the direct business into the mid-market segment and sort of the true enterprise. And so -- and then sort of the other lens to think about it is ability to add new workloads as well as the expansion of existing workloads on the platform. And then ability to add new workloads is the driver over the medium term, past 3 quarters, that's the majority of the growth. Whereas in the near term in any given quarter, most of the growth comes from expansion of existing workloads. And ultimately, the expansion of existing workloads is a function of the underlying application and how it's doing because we're really well correlated with the customer. Their success is our success. And so if an application is successful and growing, they are paying us more, and they're generally okay with that. So back to what we said. So obviously, we look at the business at a very granular level and try to see how the existing portfolio applications is doing. And we call that out when it's helpful to investors. So for example, in Q3, we said that we had exceptional growth in existing applications, which we frankly didn't think was the beginning of the new trend. We were just saying there's a distribution of these things. This was at the high end. So that's the reason why Q3 and Q4 were strong. What we saw in Q1 was generally strong expansion across the board, but with some pockets of weakness, which frankly wouldn't merit disclosure, but for 2 reasons. Number one is they feel to be macro related and secondly, all the questions that we get from all of you are about macros. We might as well skate to where the puck is going. And so specifically, what we saw was in self-serve and in mid-market, primarily in Europe in Q1, towards the end of Q1, slower-than-normal growth of existing applications. And we see it that the applications themselves are growing more slowly, and therefore, the spend of customers with us is growing more slowly. So the general sort of trend in relationship is holding. And -- but it is very broad-based across every subregion in Europe and industries. And so therefore, it's a macro phenomenon. And so we saw that in Q1, again, primarily in Europe, self-serve and mid-market. We also saw it in self-serve in the U.S. in May. And because we believe it's a macro slowdown because it's starting sort of where you would expect it to start, which is at the low end of the market, we wanted to be transparent with investors and frankly get into the month-to-month details, which we usually don't do, but these are unusual times, and this is important. And then we use that as sort of the data as well as our prior experience to sort of form a macro framework that then we use to apply to our guidance and how we think about the rest of the year.

That's super helpful. And Michael, as we think about the financial -- the margin profile of the business, it's been quite strong in the last few quarters even with the reopening occurring. So how should we think about the really significant gross profit dollars that you guys are starting to generate flowing through the OpEx?

Yes. So we've definitely had to the margin conversation, very strong gross margins. We're continuing to invest significantly in both sales and marketing and in R&D and obviously, scaling the rest of the business. We have talked about the continued steady progress that we've made from like an overall kind of operating loss income profile perspective. This past quarter was the first time we were positive from an operating income standpoint on a non-GAAP basis, less as a purposeful effort or engineering or statement or reaction to the market or anything else but more just a fact of the strength of the underlying unit economics kind of clearly making themselves evident. We have talked about how in the second half of the year, really actually starting Q2, we had, and we think we said this in the March call that we assumed a normalization of activity, in-person travel as evidenced by events like this. And we quantified that to the tune of $45 million to $55 million of sort of incremental expenses in fiscal '23. I think even kind of including that, I think what you'll see is a couple of hundred basis points of margin improvement for fiscal '23 based on the midpoint of our guidance. And so I think it's -- what we're trying to do and the approach that we've taken really from the beginning is this sort of balanced growth, sustainable growth, whatever you want to call it. We've been very clear and very deliberate to -- we've never been a growth-at-all-costs company. I think Dev and I and the team have enough years and enough cycles where that was sort of never the approach. We measure and monitor the returns at an extremely granular level when we think about capital allocation and investment. We are though pursuing, as I said, this very large $85 plus billion TAM. And so given that we have this incredibly strong product market fit and we really like and are getting excellent returns on our investment, continuing to invest does make sense, but we've been doing that at sort of a measured and sustainable pace, and you see that flowing through the numbers.

Great. Let's see if there are any questions in the audience. Okay. I don't know if complex is the right word, but you have an interesting relationship with your hyperscale peers. Maybe you can just sort of review that coopetition. Obviously, we all know the rumors of your demise were greatly exaggerated a few years ago. So maybe help us understand the history and where you are today.

Sure. So the -- it's definitely complicated or nuanced or multifaceted relationship for sure. I don't know what the best adjective is, but somewhere in that genre. But I think the reality has been, while it's gone through some phases, both imagined and real, I think we're at an exceptionally strong point in our different relationships with the cloud players. I think that they act certainly much more as partners than they do as competitors, not to suggest that there's not a competitive angle because, of course, there is with each of the 3. But I think as they've looked at MongoDB, they've seen the success of MongoDB. They've ultimately realized that sort of partnering is most effective. If I think about the evolution, MongoDB has been very popular and sort of consistently the database developers most want to work with. And if you think about not just the download data, but just our developer mind share and the developer fondness is incredibly high. So high, in fact, that both Amazon and Microsoft decided to create imitation knockoff products to capitalize on the popularity of MongoDB. And certainly a few years ago when those were announced back to your kind of rumors of our demise comment, there was a lot of concern. I think in addition to the clear product superiority that we have, I think there are also a bunch of structural reasons why companies, particularly enterprise companies, are very concerned about developing -- basically a vendor lock-in, right? So they're very concerned about developing on proprietary cloud vendor databases. And I think the cloud players obviously saw our continued success, and we have internal data around our -- when we're head-to-head with those players, our win rates are exceptionally high. And ultimately, I think everyone sort of came to agree that their battle is more with each other than with us. And if they can successfully use us as a point of differentiation and the ability to lock someone into their cloud and they get all the pull-through for the rest of the value stack or chain, right, the attach is effectively incredibly high. In addition to the fact that they don't lose the entirety of the data platform application, data platform stream because we do pay them some of the underlying storage and compute that the relationships have really strengthened. I think Google was very kind of proactive in identifying the opportunity to differentiate and pick best-of-breed solutions. And so they were one of the first to sort of say, "Hey, we're not going to create an imitation offering. We want to give our customers the real deal, the authentic product. " Amazon, an intense competitor, but also, I think, did a good -- reasonably pragmatic about things. And I think they've seen the success we've had and we don't hear a lot about DocumentDB as much as we did a few years ago, and they've been great partners on the go-to-market side, on the technical partnership side, and that's been great to watch the evolution of that relationship. Microsoft, probably somewhere more in the middle, clearly has a competing offering. We're working to improve the collaboration and the efficacy kind of in market on the go-to-market side, but have had a number of encouraging joint wins with their customer base as well. And so we sort of never -- you can't take your eye off the competitive angle, and this is certainly not a thing to be complacent about, but I think in general, both sides or all sides in the interconnectedness have worked really hard to mostly find the cooperation angles, and it's been very effective.

You can all make money.

Exactly.

With that a quick follow-up. Who would you actually describe as your main competitor?

Yes. So from a main competitor standpoint, there are 3 big buckets. There are traditional legacy players, right, sort of Oracle, et. al. They're the cloud players. And then they're -- we're not the only company to observe the fact that there's a large $85 billion market that mostly looks unchanged relative to what it did 20, 30 years ago. Those are kind of rare. And so you're good [indiscernible] capitalistic views to suggest that that should attract capital as it did, a bunch of companies like MongoDB and others kind of 10-plus years ago. I think we've really separated ourselves from that pack. So the competition at this point tends to be the incumbents, which is where the wallet share is and then the cloud players. And the issue on the cloud player side is we win pretty consistently at overwhelming rates on the head-to-head. It's more just our footprint coverage is so thin relative to them. They have sort of this natural slip stream of activity given their ecosystems, and that's why some of these partnerships have been so effective.

That's great. Out of time, we'll wrap it up there.

Thanks for having me, Brad.

Yes.