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

Good morning, everybody. Day 2 of Communacopia and Technology Conference. Welcome to day 2, but it's just the beginning of day 2 and a couple more days and a real delight to kick off day 2 with one of my favorite companies and one of my favorite CEOs. I'm going to embarrass him a little bit. I know you look very young, but we met in 2006 when you were taking your first company public. And it's been an absolute delight to -- although I didn't work with you every year during your journey, but I think I've overlapped with you during the most momentous aspects of your career. So congratulations. Here we are. And cheers to the road ahead with MongoDB. And Mike Berry, the CFO of the company, who is, I think, new to the Goldman Sachs conference as a CFO of MongoDB, right?

Yes, been here many times first time with Mongo.

Okay. Excellent. And of course, the one and only Matt MongoDB -- Martino. Matt is telling me that this is one of my favorite coolest companies. I'm just so excited by being here on stage. So with that introduction out of the way, Dave, congrats. What a journey. I mean, that quarter was incredible. What's ahead for Mongo? So I keep asking you the same question. I think this is the fourth year in a row we're doing this together. What is ahead? And what has changed in your assessment as to where MongoDB is going in the next 4 to 5 years? What's the landing point?

Yes. So obviously, we can double-click in many facets of the business. But the first point I'd like to make is we're going after a very large market. This is not a winner-take-all market. And we only have -- if you think the market is roughly about $100 billion, we only have 2% share. And if we increase that share just to 5%, we're a $5 billion revenue company. So we have a massive TAM opportunity, and we don't need to make any kind of weird pivots or anything to go after that TAM. Two, I think our core business is growing well. Our quarter that we announced a couple of weeks ago was not driven by any AI cohort or some AI outliers. So customers are using MongoDB to run and transform their business day-to-day. And the third thing I would say is that we do feel like we're well positioned for the coming AI wave. I've said on the call and other conferences that we still see it being quite early in the enterprise segment in terms of adoption of AI. Most of the adoption is either through third-party ISVs focused predominantly on end user productivity, whether it's developers with code gen tools or business users with office productivity kind of tooling. And -- but that being said, when you think about -- and this may be where you want to take the conversation, we feel like we have the right architecture for what people need to do to build sophisticated transformative AI applications or agentic applications, if you want to call them that, that will really transform the business and we can get into what role the database layer plays in those applications.

Yes, that was going to be -- you've read my mind. That was going to be the next question. So the past 10 years have been all about pivoting to the cloud, large-scale transaction systems that people thought NoSQL databases were not the best optimized for, but then you got over that and we were asset compliant and transactionally every bit as tolerant, scalable as any other prehistoric relational database. So the next chapter, do you -- what do you think about the opportunities and the risks presented by AI? Not every company, you and I have been through a couple of tech cycles and transitions. People from the old cycle, not just -- I mean, it's unfair to say that they don't make it, but they kind of make it at different points in time, so Oracle, SAP, Microsoft, they all got on the clone back at different points in time, cloud bandwagon is it that too quickly. How do you see MongoDB poised for the AI cycle opportunities and risks-wise?

Yes. So you mentioned the term NoSQL. That's a term I've come to actually [ aboard ]. And one -- I used to like it because it contrasted us against relational databases, but the challenge is that everyone just buckets all NoSQL vendors into one bucket, which is a kind of very superficial view of the market. We are the only modern database that provides full transaction support. So we can support strongly consistent use cases like transaction-intensive use cases like for financial application, trading application, billing application. But we also support eventually consistent use cases like time series applications where you don't necessarily care about any individual data point, you're more trying to understand the trends of data over time, and you want to be able to collect and process that information very, very quickly. And most people think of NoSQL as eventually consistent. They don't realize that we can really serve the needs of the most demanding transaction-intensive use cases. In terms of your question about AI, when you think about what is the role of the database in the AI era, I would argue that one of the key roles we will play is managing state and also managing memory, right? So if you think about what's going on in your system, think about like if you think your LLM is your brain, your brain needs to get feedback on what's happening to its body, right? If you touch something, you such a hot plate, you need to know, okay, I need to remove my hand because I'm going to burn my hand if I don't remove it. So you need some feedback mechanism. If you're feeling tired, you need to sit down. If you're getting hot, you need to sweat. Similarly, like modern applications need some mechanism to understand what is going on. And the place where you have real-time information about what's going on in your business is your operational data store or your OLTP platform. That's where you really understand what's going in the business. So then you can react and reason about what's going on and maybe act on things or change things. The second thing you need to so essentially, you need to know the state of things. Then you need to decide, okay, what do I need to do based on the state to drive certain outcomes. They need -- you obviously need to plan and then you need to invoke actions, right? Being able to -- an LLM may tell you to do something, but it still has to invoke an action. And typically, that's done through some software layer built on top of an OLTP platform. So we believe that we're really -- we're going to play an important role in these new agentic use cases. Then if you ask yourself, what is a modern database for the AI world look like? One, I would argue, one, you need to support JSON. JSON is the best way to model the messiness, the complicated nature, the evolving nature, the hierarchical nature, the interdependent nature of data. You can't superimpose that on a tabular structure. Two, you need to have sophisticated techniques on finding and retrieving information very, very quickly. So we not only support traditional queries, we have a lexical search engine. We have a semantic search engine with a vector store. And we also now have embedding models, which are ranked best in the industry. So that's a quality of signal because embedding models are the bridge between your private data and the LLM. And what people are starting to realize is the way I reason about my private data is very important to get the quality of the outputs I want. I use a simple example, the word pitch can be -- have so many different connotations. It could be a baseball pitch. It could be at soccer field, which is called the pitch. It could be an investor pitch. It could be the pitch of a plane. It could be the pitch of a roof. It could be the pitch of your voice. So if you don't understand...

It could be the pitch on a cricket field.

I'm sorry.

A pitch of a cricket field.

Yes, exactly. And so if you don't understand the context and meaning of your data, then how the LLMs reason about that data becomes much more challenging. So the quality of the embedding models has a huge effect in terms of how LLMs can reason about your private data. So when you marry -- and then on top of that, if you think about agents, agents don't go home for dinner, they don't take vacations, they take lunch off. So the intensity of usage with agents will require a massively scalable platform and you need a distributed architecture to support that environment. When you start breaking down what is the future database of the AI era look like, it starts looking awfully like MongoDB.

Is it just luck or thoughtful planning that the database architecture had evolved in such a way that you could take on AI, because generationally speaking, databases that made it in the clients that were on [ Primera ]were suited and you had hyperscalers with their database and you had your database. So is it just good fortune or some thoughtfulness?

Yes. I mean, obviously give the credit to the founders. You have to remember, the founders were -- had built one of the first web-scale applications that started a company called DoubleClick. And that was one of the first web-scale applications. And obviously, even today, Google uses DoubleClick technology to drive billions of dollars of revenue -- of ad revenue. And what they saw was clearly that the -- and this is now in the early 2000s, they saw the inherent challenges of trying to manage massive amounts of data, much of it also unstructured data to be able to on a tabular architecture. And because of that, they said, rather than trying to constantly jury-rig, and they're very talented, they could constantly work around the constraints. They said, I'm tired of working around these constraints. I want to build something that I would want to use that it's a much more natural and intuitive way. So JSON is another way of saying a document database. So the document database, we believe, is the best way to work with an organized data. And you could argue they were efficient or maybe a little lucky, but we're happy at the outcome.

See, these are things we don't pick up on an earnings call. I mean people don't ask these kinds of questions. That's why these firesides, I hope they happen more than once a year, but we got once a year, and thank you for that. So Matt wants to put Mike on the spot.

Mike, welcome to Communacopia. You came from NetApp, where you had a lot of success driving leverage in the business. You have 2 quarters under your belt at Mongo. When you look at the business today, where do you see the most opportunities to drive efficiency?

So Kash, Matt, thanks for having us. So when I started a couple of months ago, I felt this way, I would tell you I feel even more so now. So when you look at Mongo, it all starts with the business model and the fact that we generate such great revenue growth, and then that cascades down to gross profit, we have a ton of opportunity to invest. We'll stop there. As we look going forward, it's really 3 areas. One is we've largely built the infrastructure for the company, where everywhere we need to be from a sales and marketing perspective, we have direct sales, we have sales engineers. We have partners. Where everywhere in the world. So you don't have this step function. Most of the new investment will be incremental to drive growth. The second piece is, hey, Atlas is almost a $2 billion business now. The scale affords us a lot of flexibility to drive efficiencies through all the rest of the groups. And then number three, where all the fun starts is, hey, productivity. We have, what, 5,500 employees. We already have the base that we need to grow to drive the growth that we expect in the future. So now it's all about, okay, driving productivity. We haven't had any benefits from AI, for instance, in the company. We need to push a lot more offshoring. So that productivity piece will be where we'll focus across all the different teams. So we feel very good about being able to drive growth not only in revenue, but then the flywheel cascades down to margin. So -- and you've seen that in our new guidance. We'll talk about it a lot next week. You'll hear us say, come see us next week at Investor Day in terms of our confidence in being able to drive durable growth and margin expansion.

Mike, a lot of companies at the conference have been talking about AI productivity gains in terms of driving efficiencies in their cost base. So where do you see the most opportunity from an AI perspective to drive efficiency?

Yes, it's a great question, and Dave talks about this a lot. I think what you've seen so far is companies focus largely on customer support and then in coding, where there's been real -- well, not, I would say, material, but real advantages with AI. And I talked to a lot of the CFOs, and you can ask them here, Matt. I don't think, for instance, there's any killer use case yet with AI in finance, but it's coming. We focused a lot not only on productivity, but also machine learning and AI for our forecasting, especially in the consumption business, the ability to take all that external data and build it into your forecasting is super important. There's been all the RPA and everything else that's happened. I do think that there'll be benefits in AI, but it's coming over the next couple of years.

That's great. And I want to touch on the Atlas acceleration you guys have seen over the last 2 quarters. What are the structural drivers behind the reacceleration? And how sustainable is that trajectory over the medium term?

Yes, great question. So we do think it's sustainable. You saw that in our new guidance. So I would focus on 3 areas as it relates to Atlas. The first thing is our move upmarket. And a lot of this was in the past, we had focused -- asked the sales team to focus a lot more on the quantity of workloads versus the quality. And what we did 6, 9 months ago is we asked them to focus more on enterprise. Our self-service, our wonderful self-service, which we'll talk about again next week, can really fill in, in that lower mid-market. And we've asked them to focus more on the quality of those workloads and the size and also tweak the comp plans a little bit to say, hey, go get more ARR. That's what we all want versus the quantity. So that's number one. The push up market has helped as well. And we also saw strength in some of our larger older customers where we saw some of those workloads grow for longer than we had seen in the past. And -- so while there's not a perfect correlation, we do think that, that's driven a lot of it. And from a sustainability perspective, we do expect that to continue to grow for the rest of the year. You saw that in our new guidance when we upped the numbers.

And Dave, this higher for longer enterprise workload growth that you're observing, I mean, what's driving that? Is that the mission criticality of the workloads you're not landing in really the last 12 months, with respect to some of these older customer cohorts.

Yes. To touch on -- just double-click on what Mike just said, originally, our original thesis was that let's encourage our reps to acquire as many workloads as possible, because it's truly not easy to understand which workloads are going to grow -- become the biggest or grow the longest. And so we assumed the portfolio theory and say the more workloads you acquire, you have a better chance of finding those, let's call it, mega workloads or just a cohort of really high-growth workloads. With the benefit of hindsight, we realized that because we are indexing so much on volume, our reps are focusing on more tactical workloads where they could quickly close them versus the more strategic workloads that required more selling, more engagement, more technical kind of deliberation. And so consequently, we were kind of skimming off the top of the workloads versus going after really some of the more crown jewel workloads for lack of a better kind of framing. And so when we made that comp plan change, combined with the move up market, one, we always saw the highest productivity of our reps at the high end of the market. And two, when we made that tweaks to the comp plan, we have definitely seen a much -- a better focus on closing more strategic workloads, which is, I think, driving the growth. Obviously, the workloads we closed in Q2 have a de minimis impact in the current quarter. So we hope that we'll see similar kind of behaviors 2 to 4 to 6 quarters from now.

Great. And Dave, I want to move back to the AI piece just for one question here. You talked about kind of the advantages of having vector search, traditional search as well as the vector embedding model. I think when we look at the landscape, where you guys are a bit differentiated is the vector embedding models, right? So can you talk about how advantageous that can be in terms of field execution going out there and landing new workloads, and you have 8,000 AI start-ups on.

Yes, I'll give you some story. I met with the CIO of a very large health care company. And as you imagine, health care data is very proprietary, but also has all these nuances in terms of nomenclature, acronyms, syntax and so on and so forth. So for an LLM to reason about all that data becomes very challenging. So one of the things that they start talking to us about is potentially building a custom embedding model just for their business because by definition, that would give them a higher quality signal about their private data that the LLMs could reason about. No enterprise is ever going to give OpenAI or Anthropic all their private data. So the embedding models are essentially the bridge between your private data and the LLM and the quality of the embedding model has a direct correlation to the quality of the output. It's that example I used again with the word pitch. There's so many nuances. Context is very important. And then the other advantage we have is that we can combine lexical search or keyword search along with semantic search. So the sophistication of the queries you can do is all about finding the right information. I'll give you a simple example. If you hired Albert Einstein as your intern and said, "Hey, I want you to do research on this hot company that I just found out about." Albert still needs to do some research. He's not just going to go through osmosis, know anything about this company, right? And he could read every book he go to the library and read every book on every company in the world, but that would not be very efficient, right? So what an embedding model says is go to this section of the library, go to this shelf, go to this row, go to this book. And in this chapter and this page is the exact information you need to reason about the company.

That's definition of an embedding model that I'm going to use it.

So the point is that you want to find an effective way for Einstein to basically find the right information to then reason and decide what to do with that information and make a recommendation, whether it's to buy, sell or do something else. So the embedding model is just think of it as a way to have extremely high fidelity on your private data so that LMs can quickly find and retrieve the right information to make the best decision possible. The ability for us to do that all in one platform, one unified developer interface, all the data stays in one place, all the data can be backed up in one place. You don't have to stitch together multiple things. And a lot of people have compared us to Postgres, but actually that's a false comparison. This is really Postgres versus Pinecone, who, by the way, was first trying to sell themselves, just got a leadership change, then like Elastic and then like an embedding model from like Cohere or someone else, stitching all that together is very painful for people. And the benefit we have is that out of the box, you get all that with MongoDB.

Yes. You touched on Postgres a little bit, competition with Postgres, the hyperscalers. It's nothing new to MongoDB, but it comes up quite a bit. What are the most common misconceptions about MongoDB? And what do you believe are the platform's enduring architectural advantages relative to some of these [ models. ]

Yes. I think there's many in this room when our growth starts slowing down, many in this room made the causal connection that, hey, Postgres must be taking more share because it's ending up being somewhat like a two-horse race. There's some niche databases, but it's really us and Postgres. And I'd make a couple of points. One, I think while we obviously have been dealing with competition, as you outlined since day 1, we think a lot of the slowing growth was our own execution, which hopefully, we've not declare victory too early, but we feel like we've made a lot of progress again. Two is that I think it's interesting to note that Postgres, which is built -- just so everyone understands, Postgres is derived from the name post ingress. So it's built on an old technology that obviously people are trying to continue to improve upon. But what's interesting is that Postgres now supports jsonb. So a lot of the objection said, well, is Postgres good enough that maybe they don't need something like a [ good ] Ferrari like MongoDB. Well, when you really dig under the covers, jsonb is a very rudimentary support of Postgres. Any document over 2 kilobytes in size starts creating a performance overhead. So what Postgres has to do is called off-road storage. There's a term called TOAST, The Oversized-Attribute Storage Technique, where Postgres has to go through to process these JSON Blobs And again, why does it support JSON? Because it's a tacit admission that you cannot pre-superimpose this very ordered tabular architecture on a messy, complicated world that has multiple modalities of data. It just doesn't make sense. So that's why Postgres supports JSON. So second problem Postgres has is that the data model is very brittle. So it's very, very hard to make changes. and a world that's only escalating in terms of velocity, people responding to new opportunities, new threats, building new capabilities, et cetera, you need a platform that enables lots of change very, very quickly. It's very easy to make changes on MongoDB. And the third thing is that Postgres was designed to be a single node system and you hear all these people saying, we have -- they're working on re-architecting Postgres to make it more scalable. My engineers call it sapless when it comes to scaling. But essentially, we are built on a distributed data architecture from day 1, so that the most basic configuration of MongoDB is what's called a 3-node replica set means you have 3 copies of your data. And should there be any network systems failure, your application is always up and running. So architecturally, we believe that we are well positioned. But that being said, Postgres does not need to die. If you have a traditional use case, the data model doesn't change, it's very alpha numeric information. Do you need to run a MongoDB? No, you don't. We have a lot of customers who do that. You have those kind of use cases, but it's not like the world is going to end if you don't use MongoDB. So the market is very big. Postgres does not need to die for us to win. And obviously, we think that even just a couple of points of share could be very transformative for us.

I love the way this conversation is going because we're getting into it the details of it. At a point in time when we're between 2 cycles, the cloud cycle and the next AI cycle, these kinds of questions and the discussion, the depth of discussion we're having, we've barely got to 3 or 4 questions here. But that's super important if you were to paint the case for a durable growth company over the next 7 to 8 years. If you get certain things right at the front end of the cycle, you got -- then the questions in the next few years will be consumption patterns, quarter-to-quarter, net expansion lands. But if you get this criticality at this point in time, right, I think it's just a really good story. So I wanted to -- so I want to be a little humorous. Maybe poster should be called pre-JSON. Okay. So I want to come back to a point you made earlier about how this health care company, they have their own lexicon lingo, which is a reinforcement that the value of enterprise data is very high. And if I take that at face value, it would be super hard for the LLMs, foundation models without naming any one by name because we're going to have a couple of the executives at the conference here. Why would they be successful in SaaS? Why should investors believe that foundation models are going to be a slam dunk in SaaS? And because what you said, the value of the data, right, it's very private, and it should not be accessible to the public world outside.

Yes. So I try to take a first principle approach. So a common question I ask when I meet with customers is what are you doing in AI? And invariably, it's some end user productivity initiatives. And then maybe they're starting playing around with some agentic-based approaches typically in the back office first. And then I ask, say, a financial service executive, are you implementing any AI use case that's customer-facing or public facing -- they said absolutely not. Why? Because of the risk of hallucination, right? We are still not comfortable that we can guarantee the quality of the outputs. So God forbid, some customer makes a buy or sell decision based on some recommendation from an AI-based system, that could be quite disaster for us. Same with health care companies. And so people are still quite nervous that AI systems are probabilistic in nature, so you can't guarantee the outputs. And you see some data points. GPT-5 was not this magical breakthrough where we're getting closer to AGI. Dario, who I've spoke to a number of times, has talked about how 6 months ago, said 90% of coding will be done by coding agents. I mean, cloud code is great, but 90% of the code is not being done by AI. So I think we are, again, in the very, very early innings of AI adoption. I think what they're doing in terms of the research breakthroughs are really impressive, but I think we still need algorithmic breakthroughs to kind of get the next layer of kind of intelligence in place. And I think Alex Karp has -- when I listen to what he says, I kind of align with what he says is that think of AI as this raw material and you need some sort of ontology architecture around it where you need to understand entities and relationships and concepts and rules to put the scaffolding around this raw material to provide guardrails to produce the output that you can generate. And I think that's what you're going to start seeing as people start deploying agents is there will be lots of guardrails around these agentic platforms. Think about agents, you have to control what permissions do they have. I don't want an agent to see something that agent should not be seeing. You also have to understand governance. I don't want one agent contradicting what another agent is doing. I want to understand what are my agents doing in general, like are they generating the outputs that I really want. So that whole governance scaffolding infrastructure, we're still in the very, very early innings. And I think that all has to come to place before you really see people really transforming the business with AI.

Got it. Matt?

Yes, Dave, 2 large analytics platforms recently acquired Postgres companies. On the last call, you noted that this reinforces OLTP as the strategic high ground for AI. I thought that was an interesting comment. Do you see AI shifting more of the value to database platforms like MongoDB in the future?

Yes. So I want to be clear. With AI, there's 2 things. There's training and there's this inference, right? So OLAP technologies are great for training and data prep and you have already the built-in permission structure of the data. So the LLMs know what data they have access to and who should see what, et cetera. So that's all great. And obviously, Snowflake and Databricks are great companies. But the fact that they had to make acquisitions in the OLTP space is acknowledgment, again, acknowledging their part that OLAP is not the strategic high ground for inference. To do inference, all the points I made earlier, you need to have access to real-time information, what product shipped? What is my supply chain looking like? What are the prices of X, Y and Z goods that I may want to buy or sell? Like you can't get that from an OLAP system. You need real-time access to that system to be able to make essentially some decision about that. And so the fact that they made these acquisitions, I think, basically indicate a couple of things. I remember when Frank Slootman was running Snowflake, who I respect a lot, but he said we have this Unistore architecture, and we're going to come out with our next-generation OLTP platform. Obviously, the fact that they bought Crunchy Data was admission that, that didn't go anywhere. Then you had Ali also saying that he has the best data engineers in the world, and he's going to come out with his next-generation OLTP platform. The fact they bought Neon, basically a vibe coding platform for hobbyists, and by the way, that a big outage, so it's not enterprise grade. It speaks volumes about the fact that building an OLTP engine that's battle-tested, enterprise grade that addresses the security, the durability, the availability and the performance requirements of a customer like Goldman Sachs or a big telco or a big industrial manufacturing company is not easy. I mean we still consider ourselves kind of teenagers in this database market but we're 18 years old, right? And we've gone through the knocks with nearly 60,000 customers. We've seen almost every use case across almost every geography, across almost every customer segment. So that -- there's no compression algorithm for experience. So I think that speaks to the fact that we believe that we're well positioned just from both experience and the enterprise-grade infrastructure as well architecturally from the fact that we're native JSON database that naturally embeds lexical and vector search as well as the embedded model.

Dave, I want to switch to the relational opportunity. Displacing legacy relational systems has always been an attractive opportunity for MongoDB. But I once heard that when the world ends, the only 2 things left standing will be relational databases and plastic. So can you talk to us about the relational migrator tool because that's intended to make that lift and shift a little bit easier. What are some of the advancements you're driving through AI?

Yes, we're going to have a discussion on this next week for those of you who plan to attend our Investor Day in New York. But essentially, when I took the company public in 2017, we had called out in our S-1 that 30% of our new business was relational migrations from relational databases to MongoDB, which we thought was an important data point because most people thought we're just going after new-fangled and use cases. Obviously, our cloud business soared, and that was predominantly new, but we still saw a lot of relational migrations. I constantly went to my engineers and said, why can't we do more to win more of this? And the constant refrain I got from my team was that, hey, remapping the schema is not that hard, moving the data is not that hard. rewriting the app code is hard, painful, long and costly. And so unless the customer is under a lot of pain, no one wants to start rewriting their app. So fast forward then, obviously, 8 years later or frankly, when OpenAI announced ChatGPT, all of a sudden now said, wait a minute, we could potentially now use AI to refactor this code. And that's essentially what we are doing is building a tooling platform to automate the migration process from relational to MongoDB. Now we'll get into details live next week. But just to explain why do customers care? One, there's a ton of technical debt on these platforms. Like for example, if you want to AI enable these legacy applications, like, for example, I want to marry metadata to -- metadata is basically data about data, right? I want to marry metadata to this data, so I can reason about what data I have, so I can obviously make good decisions. You can't do that on a legacy platform. The data model is incredibly brittle. You have end-of-life issues. My base is going end-of-life. You have regulatory risk if you're a financial services and health care company saying -- they were saying, you're running your crown jewels on a platform that's very old, you've got to get off these platforms. And by the way, the tax of running on these platforms is very, very high. So for a confluence of reasons, people saying, I got to do something. So we have a lot of demand. And then the obvious question is we're trying to figure out is what's the best way for us to build. We want to take a product approach to this, not a services or like a systems integration approach. So there'll be some combination of product and services because there are lots of variability, but we'll get into a lot of this next week at Investor Day.

Any questions? Yes [indiscernible]. Yes. All right. Before the mic gets over to you, just speak loudly.

[indiscernible] Thank you. As we move into thinking about agentic apps, one of the things that they tend to try to do is taking your digital footprint -- or sorry, your physical footprint and making it more digitized, right? That's how they eat into labor budgets. Naturally, that's multimodal, like the way that we interact. And so as such, the complexity with these apps starts to exponentially just starts to rip, for a lack of a better word. Curious on your thought process around when and what use cases you really see like a more SQL approach breaking versus a multimodal having to interact with all sorts of different parts of the world because that to me was one of the best validations that, hey, as we look forward, you just really can't think about the Postgres and like Mongo debate as much as you did just about 90 days ago, I'd say.

Yes. So I would just say -- answer the question 3 ways. Why do customers choose MongoDB over Postgres. One is data model kind of flexibility. To your point, being able to handle multimodal data is so much easier in MongoDB than on the tabular architecture. Two, data model agility. I need to be able to change the data, like the interdependencies and relationships with data may constantly evolve. That's going to happen a lot in AI. And so I need to be able to constantly adjust my schema. A lot of people think we're schema less. That's not true. We have a flexible schema. We can have governance around that schema, but we can also change the schema quickly when you need to. The third reason is being able to support this very sophisticated, what I call hybrid search techniques where you need to be able to do both lexical and semantic search to find information very, very fast. And then the fourth reason is the platform scalability, right, being able to basically massive scale out is the point I made, like agents don't go back -- don't go home to sleep, right? Agents constantly chug away. They don't take coffee breaks. They don't stop for lunch. So you need a platform that can scale because the intensity...

But they need GPUs, it's more expensive than coffee.

They need compute. That is definitely true. But the intensity of usage will be much higher when you're replacing potentially humans with agents because by definition, they can work harder and longer.

Time for maybe one more question, really good one. [indiscernible] There's a good one.

Sorry, we already had a mic. Good to see you, Dave. Maybe for Mike, just in terms of the CFO philosophy, I would have described kind of the first chapter of MongoDB's public history from a margin perspective as very incremental, like growth first, explosive growth and incremental margin expansion when the company was public, non-GAAP operating margins were deeply negative. What's your philosophy at this point? Like is it -- is that kind of step -- incremental increase in margins, how we should think about things going forward? Or is there an opportunity for more of like a larger step-up and GAAP operating margins getting to a more normalized level?

Yes. So great question. And I'll answer the question, but come next week, we'll give you a little bit more. So my view of this is at the time when Mongo was growing and the company did a great job, it was all about growth. And when you're growing 30%, 40%, 50%, great, you should invest and you should drive that growth. Now where we are with the scaled business, with a business that generates a bunch of gross profit, we can do both. And so the expectation is we can grow and have durable revenue at the top line, but there's no reason why we also can't drive margins. And as I talked about a little bit before, we're still going to invest in growth. The things we've talked about, R&D, products, marketing, developer awareness, all of those things, the product-led growth, we will continue to invest, but we don't need to invest like we've done in the past. So I've been pretty clear, which is we can do both, drive sustainable, durable growth, especially in Atlas, but also be able to drive margin growth. And then the third piece was it in your question is, hey, folks, we're a business, we need to generate cash as well. So also the conversion of profit to cash. So you should expect to see continued growth. There's no reason for us to pull back on the lever and say, hey, we don't need to spend here. We're just going to spend a little bit smarter, reallocate dollars and be able to drive growth. And hopefully, you've seen it in what I've done in the past. Hey, folks, we're going to be pretty transparent. Here's the goals. Here's what we're going to do. Here's the drivers of the business, and we'll walk you through that in more detail next week.

On that note, Dave, congrats on the great milestones at Mongo. And databases used to be very boring when I started on the sell side, and you made it exciting. You're the steward of the transaction database ready for the AI world. So thank you for all the great work you're doing for the industry, for our investors. Mike pleasure to meet you.

Thank you.

And let me be the first to welcome you back to 2026 Communacopia.

Thank you, Kash, and congrats on your retirement, and thank you for having us.

Thank you so much.

Thank you.