My name is Koji Ikeda. I'm one of the Software Analysts here at Bank of America. Thanks for coming to day two of our tech conference. I am absolutely thrilled to have MongoDB here with us today. We have CFO Mike Berry and Ben Cefalo, Chief Product Officer. Thanks so much for being here. Appreciate it.
Thanks for having us.
Thanks for having us.
Yep. You guys reported results. Let's just kick it off right off.
Okay.
You guys reported results last week, last Thursday. Maybe a question for you, Mike. Can you give us the key highlights? I guess most importantly, where were you getting the most questions? What topics around and how are you answering those questions post-results?
Sure. Thanks for the question. As we talked about in a lot of the different calls, hey, we had a strong Q1, fourth straight quarter for MongoDB Atlas growth, 29%+ . I think it was the fifth straight quarter where we added incrementally more MongoDB Atlas revenue year-over-year, which is a key thing for us. We rolled the beat for Q1 into the full year, and we raised the back half. Importantly, you folks all have your own models for us. Yes, we bumped up MongoDB Enterprise Advanced and Q2 because of what we see in the pipeline, but everything in the second half for us was a raise in MongoDB Atlas. We are starting to see some movement in enterprises as it relates to AI.
It's still early days, but a lot of the feedback we're getting from the sales team in terms of, hey, the work that's going on there, enterprises are all focused on it. There's still a lot that has to be done for them to actually roll it out en masse, but we're starting to see some movement, which is great, and we continue to feel good about driving durable growth as well as driving revenue and profitability growth. A small thing, second straight quarter where we were GAAP profitable, which is great. Biggest questions we're getting is durability of Atlas growth. We do get a lot of questions just in terms of, hey, EA and Atlas, and we just want to be clear, folks, and for us, this is an and not an or. We do not expect the EA growth to have an impact on Atlas growth.
They're different use cases. It's largely a different go-to-market motion. Of course, there's all the questions around AI.
Got it.
Ben?
Definitely.
Ben, since we have you're the product guy. Want to kind of go back to the core value proposition for MongoDB, especially in the fact that you guys are operating in such a dynamic and evolving world. For those investors in the room and those on the webcast that are just trying to get back to first principles on MongoDB, can you talk a little bit about what the core value is that MongoDB delivers today? Maybe more importantly, as we go forward, why are customers increasingly standardizing on MongoDB? What is that reason?
Yeah, thank you. It's a great question. The first principles-wise, from the very beginning of the birth of MongoDB, it was always about the document model in JSON, right, the JSON format. Either the founders, and I've been here nine years, but I wasn't part of the founding team. Either they were really smart or really lucky that all of the AI world has standardized on the JSON document model format. It provides great flexibility, it provides great performance. It allows you to really look at your data model in this unstructured world. The majority of data that exists today and all the new data that's being generated, the majority of it is completely unstructured. From the day one, built from the ground up, we natively support this. It's the only type of format we really do support.
We continually investing in that, as you saw when we released MongoDB 8.0, fastest release of the database that we've ever had. As much as we're investing in all of these other areas, we're still very much focused on making the database better and more scalable and more performant. The second thing, from just a value side is, and to answer your question more on the standardization, customers really agree with our strategy of if MongoDB is the system of record keeping, if you think about like a circle and the core data's in the middle, why do I want to have to copy that data for my search use case? Copy that data for a vector search use case? Copy that data out for an analytics use case? Whatever it might be.
Our strategy, especially when it comes to the Atlas platform, has always been we have your system of record data, and let's continually add more use cases, but not via bolting on plugins by actually building out new value-added services, but do all the wiring for you behind the scenes, as well as keeping the querying and the developer experience exactly the same. We've done that with Atlas Search. We did that with Vector Search. When we acquired Voyage last year, we've done the same thing with that. It's really about keeping the developer-user experience in mind at all times, so the developer doesn't have to query multiple different systems for a singular use case. I would say those two things are really why people are standardizing on us and why they find a lot of value in Mongo.
Ben, you mentioned something about 8.0 being the fastest release ever.
Yep.
Can you talk about that a little bit? What drove that to be the fastest release ever? Something you're doing on the R&D side, maybe customers pushing you hard for new features. I mean, why was that the fastest release ever, and could we expect 9.0 to be even faster than that?
We always can go faster, and we're always going to be investing in the core technology, so that has not stopped. We have never taken our foot off the gas there. I think what caused it to be a big jump, really was one, around the same time we started development on 8.0, new CTO came in. Jim looked at different engineering principles and how he wanted to focus on and really got back to first principles of how he came from that massive database background, and he just simply said, "We can do better. We can make the bars better." We just put a high focus and investment in that area, and obviously the results paid off.
When I think about Atlas specifically around the core offering, Vector, Voyage, all the other features that are around it, how important is this all-in-one platform for customers today? Is it one of their key topics or key focuses, and how does that keep being a key focus for customers in the future?
I think it shows up a couple different ways. First of all, customers do want less vendors that they have to deal with. I think secondarily, what makes us really unique, and something we don't talk about publicly a lot, is that we're not locked into any one deployment model. Whether you want to be in a hyperscaler, whether you want to run it inside your own four walls, whether you want to run it in a Neo-cloud, whether you want to run it in a sovereign cloud in Germany, we have different form factors that meet the customer's demand, right? Being able to give them that true portability is something that no other database vendor, I would say modern database vendor, can do and certainly not something you're going to get from the hyperscalers.
I think all of those things added up is one reason why our customers really love us and are choosing to standardize on us.
If I could on that, Koji, we talked about it last week. Now, about 45% of our customers over $100,000 in ARR use more than two products within Atlas. For us, the way we monetize that is it's more Atlas consumption. It's revenue because you get it included in Atlas. For us, that's a good thing, and we certainly see the customers adopting multiple features.
Mike, remind me, on the two-plus front.
Yeah
What are the most common add-on products that are driving that two plus for the Atlas?
Vector and Vector Search.
Okay. Okay.
Search and Vector Search, sorry.
Last week on the call, you guys called out a couple of big, some AI customers that you won, and I remember when we were discussing on the callback and even on the call, one of the reasons why these customers were looking at you was, one, just Atlas, period, but also the interoperability between hyperscalers. How big of a differentiator is that for you guys? How should we think about the capacity constraints at hyperscalers being a good driver for you guys for the next several years?
Do you want to do the multi-cloud?
Yeah.
I'll do capacity.
When we say we run anywhere, it goes back to what I was just saying a minute ago about customers really have their choice. What we don't, I think, do the best job at marketing this feature, and I'm working on fixing that, is actually what we mean by run anywhere and multi-cloud is that it's not just you get to pick what cloud you want to run on, you can actually extend a singular cluster across multiple clouds at the exact same time. You just can't do that with DocDB, Cosmos, Dynamo, because they're just native hyperscaler services. Back into whatever else is going on in a particular region, capacity could be something. This could be that this app is slated for this cloud provider, this app's slated for that cloud provider.
It gives the customer a lot of flexibility to just say, "Oh, cool, I'm just going to add a couple nodes of this cluster to GCP now," even though it was running on AWS. It provides the customer a lot of flexibility. Depending on what's happening in that particular region, it gives them an out to move into other cloud providers if they had to.
Capacity so far has not been an issue. There's obviously a lot going on with memory and everything else in all the hardware piece of the world. We have long-term agreements with all of them, so we feel comfortable there. Hey, it's a multifaceted relationship. Certainly, we buy from them. There's co-sell that goes on there. They're certainly competitors as well. There's a lot that goes into that. We watch it every day. We have conversations with them. It has not been an issue yet, but we're certainly keeping our eye on it.
I know you guys get the Mongo versus competitor A, B, C, D. Why Mongo versus all these competitors? Maybe a question for Ben. If we could dig down into the technology of Mongo, what are maybe the top three reasons from a technological aspect of why customers like to choose Mongo over the competition out there?
First of all, it's what I was saying earlier with the JSON document model. We're built from the ground up. Our storage engine, how we actually write the bits to disk or to memory is all native JSON from the very first line of MongoDB, right? 17 years old, 18 years old now. Again, first principle from the very beginning. Number two, the way we scale is vastly different from a performance and price perspective than how you would have to scale a relational database, and that goes for all of them. Third is really around the portability, and allows the customer to have all that different levers about how they need to deploy. If they want to start out, we still have an open source database, right? We still invested in that as well.
We still get customers that started out there, and they scaled to a point of now they need to have the different performance that they want us to manage it for them inside of Atlas. That portability gives a lot of people comfort in choosing us as a technology.
When you talk about scale, the performance, and price. What's the one-liner on how you guys are able to do that, offer such good performance and price?
We scale differently. We don't just need to scale vertically, which is either more machines or bigger machines. We can scale different things independently. You can have different storages. Your workload might be perfectly fine on a subset of, I would say, this tier 1 of compute, but you need more storage because your data size is bigger. We allow you to either add more storage or you can scale out horizontally, where it's the same type of box. We call it sharding. We do our own data routing inside of MongoDB's distributed system. It's just a different way of doing it, but we're able to do that at a lower cost because the smaller boxes are cheaper than the bigger boxes or bare metal from the cloud provider.
Most of the time, scale of economies, you can have a lot more smaller boxes than you can have a couple of larger boxes.
Was that something that Mongo was founded on originally, way back when, this type of architecture, or was that something that had to be built in later as you guys got bigger?
I've been here nine years. It was the sharding technology that we've built existed when I got here, but if I'm rewinding the whole clock, I don't think it existed in the first release of Mongo, but we developed it over time.
Okay. Something that you had to do because of the success that.
Yeah. Exactly.
Enterprise Advanced, something that has become much more topical for you guys. I guess first question for Mike, on the nice guide for the second quarter, can you just talk about that a little bit? What is the visibility that you have? Is it big contract? What's going on with the second quarter guide in EA?
Sure. Let's back up for a second on EA. As we all know, this is a standard license support model, and we said this last September. If you look at the $500+ million, about 70% of that, folks, is support coming off the balance sheet. That's most of what's sitting in deferred revenue, and we're going to get it whether we come into work or not. There's a big piece of that that's ratable. The license piece is either a one-year deal or a multi-year deal, where the hard part for us to forecast are the multi-year deals. Customers really don't know, because it's based on their budget. Are they going to do a one-year deal? Are they going to do a three or even a five-year deal?
That's the part where we try to be candidly conservative/pragmatic on. We're not going to lean over our skis on those. Entering Q2, we know what's coming off the balance sheet. We expect to see what's going to renew, and then there's already been deals that have been booked as multi-year that we know we're going to recognize. That's what's in the Q2 number. Keep in mind, too, that in the second half, it's a very tough compare versus last Q4. Remember, EA went up quite a bit. What we said is, hey, for the full year, we expect somewhere around 5% growth, understanding that, hey, if more multi-year deals come in at the back half of the year, great. We're not going to include them in guidance.
Again, the activity we've seen and the momentum there has not been at the expense of Atlas. These are customers saying, "Hey, I was going to do something else. Now I'm going to deploy." I know hopefully your next question to Ben's going to be what are you putting in there as it relates to AI? This is the part where I scratch my head a little bit, which is, hey, today, yes, you can see the growth in AI through Atlas. The future's going to be you're going to see it in Atlas and EA. Companies are going to deploy AI internally in their own data centers, and they're going to use EA to do that.
Mike, you got your question.
Yeah.
I'm sorry, Ben, you got your question from Mike.
Yeah. As Mike said, this is an and, it's not an or. For various reasons, we're seeing customers continually invest their own deployments of EA for various reasons. Could be data sovereignty, residency, manufacturing use cases where they need to be inside the facility, hospital use cases where they just need to protect themselves against from a hurricane or anything like that. There's all these reasons why EA is a great business, and again, we're still investing in the core technology. We've said that we're working on, from a roadmap perspective, bringing not full parity from Atlas into EA, but where it makes sense and also based on what our customers' demands are, we're going to be adding more functionality that exists in Atlas only today into EA for those use cases. Because customers want to be able to have true hybrid workloads.
Hybrid multi-cloud is something that a good chunk of enterprises I've talked to over the last three months is really top of mind for them. They want to have that flexibility. To have that flexibility, the same core functionality that they've built on inside of Atlas, if they ever needed to pull that back, or they're going into another geographic region where there is no cloud provider region or something, so they're going to run Enterprise Advanced themselves, that they want to make sure that they don't have to change their application.
If I could on this, two big pieces. Hey, it's over 20% of the business, that's high margins. It generates a bunch of profit and cash. I love that. That's a big piece of it. The other thing is, in the past, I think we've done this to ourselves. We call the business Atlas and non-Atlas. We've changed that, folks. It's Atlas, and it's EA and other. It's a meaningful piece. Biggest customers in the world buy it. It's a big driver of the financials, and that's how we're going to talk about it going forward.
I'm going to ask you guys one more question, then I do want to open it up to the audience to see if you guys have any questions out there. I know you guys like to introduce new products around .local events.
As much as you could without telling us everything. Which MongoDB.locals should we be really paying attention to? I pay attention to all of them, but is there one or another that we should be honing in on when we see it on our calendar?
You should pay attention to all of them. We've reduced the number of .locals to a smaller number. The big ones are San Francisco's always a big one just because of what's going on there with AI. Our biggest event is .local New York, and CJ talked about it. We'll have our next investor day right around that as well. Those are probably the biggest ones. London was a good one as well. I think India, I think there was a lot of good stuff. Really, New York and San Francisco are probably the biggest ones, but we've also shrunk that population to make them all more meaningful.
Got it. Any questions from the audience? I got a lot. It's all good.
Okay. You're going to fill in?
I got it. One thing that has been coming up more with Mongo is how to attach Mongo to the code gen vibe coding tools out there to become that either default database of choice or one of the top three or whatever it may be. What exactly is going on there with that? Is there something that needs to happen from a technological aspect to get that initial default database, or is it just like a partnership agreement? Help me understand that a little bit.
Yeah. It's actually neither, to be honest.
Okay.
It's not a partnership, it's not technology. We're not missing technology. We actually have more functionality. There's a big thing in the industry right now around AEO for agent optimization. There's a lot of things that we're doing just from a content generation perspective, even little things, making our website even just easier for agents to read, which is a whole new skill set on its own, new profile of worker. The reality is MongoDB came out in, what, 2010-ish, right? PostgreSQL has been around since 1996. SQL came out a lot longer before that. There's 50 years of content related to relational in SQL Server. We're playing catch up there. The LLMs, regardless of the vibe coding platform, they're all using something else behind the scenes as their model. They're trained on public internet data.
We're just in a content game right now with how much content is out there versus how much content is out there about MongoDB. We're obviously working on that. Number 2, we have done things to make agents like us better. We have MCP servers. We're publishing all of our own skills. We've released an architectural center last year on the documentation page, and so we're hyper-focused on all of these different avenues, but to drive that awareness. It's a work in progress, and I think it's going to be a work in progress for a while, but I think that's just the macro of how fast things are moving. It's not just a Mongo problem.
For an application that was built on something else other than Mongo from an AI native startup, whatever it may be, how easy is it for them to transfer what they had over to Mongo for the future?
There's two different flavors of this, right? Even with what I was just saying, the funny thing that the LLMs are doing is that they're modeling the data properly, meaning that the data model is JSON or the document model. They're just picking some PostgreSQL flavor with JSONB, to say the least. That's the most common one that we've seen. When they do that migration's really simple, and I'm not even talking about from the data side. We're really good at moving data. We've always had a migration practice inside of Mongo ever since the beginning. We're very good at moving data from PostgreSQL to MongoDB. We do that all the time. What makes it easy is if their application is already thinking in the document model perspective, it's on the easier side to then tweak that application, use our driver, and then start using Mongo.
It's both flavors of it, is if they start out with something else but still on the JSON model, that's on the easiest side. Even if they didn't model their application using JSON and it's more of relational or they're using key value, whatever the case may be, that is something that we've done all the time, too. Nothing about this AI generational shift has made it harder or easier to migrate into Mongo. We have a really good migration practice that focuses on that.
Got it. Got a question for you on Voyage.
Sure.
Two weeks ago, I spent a lot of time trying to understand what Voyage is and why maybe you guys bought it. I realized I had you on the stage in two weeks, and I said, "Forget it. I'm just going to ask you.
Yep.
What is it specifically about Voyage that makes it so important for the Mongo strategy?
Yeah. I have an answer. I will admit I am not the expert on Voyage, but I know enough to get myself into trouble. A couple of reasons why this made a lot of sense. Number one, as we were talking about earlier, about really focusing on the Bay, we've announced a lot of with MongoDB.local San Francisco and the focus of what we've been calling Reclaim the Bay. Somewhere between before COVID into now, I think we lost a little of the coolness factor in the Bay Area, right? One, Voyage had an amazing brand. The technology's amazing too. We also were thinking of it from a brand perspective, and we wanted a way to make sure we had credibility and a coolness factor in the Bay. That had something to do with it, but the technology is stellar.
We're investing heavily in there. When we bought them, they were the number one embedding model on Hugging Face. They're still a number one embedding model on Hugging Face. The Frontier labs actually suggest customers use Voyage embedding models. That was obviously really important to us. Third, if you look at what the value prop of Atlas has always been and what we've been building as a platform is we don't want customers to have to stitch together all of these different things. Even though we had Vector Search for a really long time, the customer had to bring their own embedding models, and we still support that today, right? You can use Amazon Bedrock or whatever else you want to do to embed your data.
Now having it inside of our ecosystem, directly inside of our platform, it's something else the customer doesn't have to worry about. They can just start using it, right? Having the re-ranking models there, at the same time is also super important because then we can continually keep those embeddings up to date. The last piece that customers are really gravitating towards is they like that it's all with inside of the MongoDB ecosystem. As Mike said earlier about security and governance and reasons why the enterprises are typically slower to adopt any new technology, they already trust us. They don't need to go get another contract to use some other random embedding model, that it's all part of our ecosystem. All of those things combined were why Voyage was an important acquisition for us.
Maybe a follow-up question for you or Mike. Clearly embedding and re-ranking models are important. That's why you guys bought it. Good technology. When I did my work, you guys always were top notch with Voyage. If it's so important, why doesn't the embedding and re-ranking side get more competitive? Is this something we need to watch out for from a competition front?
I think it's something that, hey, it always will. We've seen that. We've seen other folks join. We welcome all that because it makes us better as well. It is something that we watch. I think what Ben talked about is, it's more imperative for us to make sure that we are continuing to evolve the product, and that's a big piece of it. We also talked on last earnings call. The number of Voyage customers doubled quarter-over-quarter last quarter. Now year-over-year, quarter-over-quarter. It's still a small revenue contribution, but that's a great driver. We also talked about in the 2,500 net new customers, we actually saw Voyage become a bigger piece of that as well. Yes, it certainly will become more competitive. It's incumbent upon us to keep adding functionality. We're seeing great traction.
I'm going to ask you guys the when AI tailwind question here. Maybe in a different flavor. Not looking specifically at MongoDB financials as the indicator or the trigger. For those in the room and those in the webcast, what should everybody be looking for as signals broadly that the enterprise AI tailwind that should benefit MongoDB is really inflecting higher? Is there something to look at? Some sort of demand signal that we all should be focusing on?
I guess the way I look at it is, hey, all of us, the enterprises, we're their customers as well. I think you started to see them roll it out in things like chatbots, right? You can't talk to a human today if you tried. You're going to see some of that incrementally move. I think for us it is when you start to see actually things like your bank is telling you, "Here's the stocks you should buy." When your insurance company, it's now a virtual agent, not a physical agent. When you're starting to see AI actually impact what you do every day outside of doing, "Hey, what's a new recipe?" on ChatGPT. I think that's when you're going to start to see the inflection point, when enterprises are actually going to their end customers using AI to drive their business.
Thinking about Atlas and EA, two core products, two different line items. How do we think about the durability of growth or maybe even the mix of growth of these two products as a composition of total revenue over the next five years? Is that something we could even think about right now, or do we just have to wait to see how it plays out?
Yeah. Great question. We'll talk about this again in September.
Yeah.
Last September, what we talked about was, hey, expectation for, again, three to five years, not next quarter, Atlas growth continuing to be north of 20%. Then at that point, we said total revenue growth in the upper teens. That basically embeds, you can do the math, says that, hey, EA is, call it a low single-digit grower. I think what we've seen is we continue to be very excited about Atlas. To the extent that all the investment and what we've seen from a customer perspective can bump EA up, maybe that moves it up. We'd love to talk, and we guided this year for 20% total company growth. No matter what, Atlas growing where it is, 75% of the business will continue to be the biggest piece and the biggest driver of growth. I don't think it ever goes to 100%.
At some point, it's going to asymptotically stop. Where is that 85/15? Is it 90/10? We'll have to see. I think a lot of that depends on how do enterprises want to deploy AI between the public cloud and on-prem.
Coming up on time here, I'm going to ask you the growth and profitability question. I think it's become more interesting after this second quarter earnings cycle, where we've seen a bunch of infrastructure software companies prove out the growth and prove out the strategy. Mike, last question for you. How do you think about that balance between growth? Because clearly the growth is there, but profitability matters. How do you think about it?
Yeah, it's a great question. This is one of the things when I started, almost a year ago now. I didn't realize the efficiency of the model. What we talked about last year was we took a little bit of a step back on OpEx. We said, "Hey, let's make sure that we see a return on all those dollars." We've started now to increase the investment in fiscal 2027, and you see it in our guide. OpEx is still growing upper teens. The focus for us is where can we put investment in that's going to drive revenue growth, that's going to go to the bottom line. It's a great model, and that's how we're going to drive margin expansion by growing the revenue line. We're not in the game of cutting heads at this point.
We're in the game of where can we get efficiencies, invest more in product and in quota-carrying reps, most importantly, that then we can touch and feel and say, "There's a return there. There's incremental revenue, and boom, that's going to go down to the operating line." It's a great model. It's very efficient, and that's the goal now. We look very hard at incremental investment needs to drive incremental growth, but where we see that, we will absolutely make it.
Got it. We're all out of time. Ben, Mike, thanks so much for doing this.