Product of, or Chief Product Officer of Core Products. They cannot hear. They cannot hear you. He has- Hear me now? Maybe make the mic a little. Wait for the door to close. All right. CJ, let's start with you. You've now had nearly a year in the role, hundreds of customer conversations. What's become clear to you about the role MongoDB can play, and how has that changed your ambition for the company? Absolutely. First, it's great to be here. Thanks for inviting us. I would say, yes, on an average, the customer meetings I do tends to be around 10- 12 a week. Really trying to understand how do customers see us today and where do they see us in the future, right? This is across AI natives, digital natives or Fortune 500 or Global 2000. The biggest learning I had is that we are definitely seen as a very modern database that can scale significantly for massive workloads, right? To give an example, one of the Fortune 100 firms in North America told me that after they moved multiple of their workloads on MongoDB, they have now created us as a standard that any new application, unless proven otherwise, should be on MongoDB. Okay? Which is a massive thing in a highly competitive database world, as you know. So one is that it is the most modern database. It is the right data platform when you think about creating AI workloads that are real-time. Seems like it is a great technology or great foundation. So that's my learning number one. Learning number two is the modernization opportunity that Dave and the team have talked about in the past that is real as people are trying to get AI-ready. I know we are early, and we said that this year, Mike and I shared with you guys that we are focusing on creating the right product and product-focused approach versus services-focused approach. But that opportunity, specifically in Fortune 100 and Global 2000, is very real for MongoDB as customers prepare themselves for AI. The third thing that I would share is my learning has been as MongoDB grew phenomenally workload by workload over the last many years now, including Atlas, the awareness in the C-suite has been low. So that's the, I would say, the thing that we can improve on is what I realized in having this conversation. The AI decisions, what is the AI architecture for the workloads, where do they fit, say, MongoDB in, those are usually top-down decision made by a chief data officer or chief AI officer or enterprise architect. My realization was when I would tell them, "Hey, we are now vector integrated fully. We have this great best-in-class embedding model, so you should build your agents on top of MongoDB," they're like, "Gee, we didn't know that." With one very large financial services company, 6 weeks ago, I had the conversation, and now they are doing a POC on top of Vector, Voyage AI, and Mongo together. I found that the awareness was low in the C-suite on MongoDB. Yeah. I think since day one, you've talked about maybe driving more top-down engagement. I guess, where are we in that journey over the last kind of 12 months? Like how much higher is engagement around winning some of those newer workloads? Yes. Sales cycles, when you go top-down, tend to be always long. But it is early, but it's working. We are having a lot more strategic conversations with a large telecommunications firm or a large retail firm in Europe, and they are saying, "Okay, we will standardize." One of the Fortune 100 companies in Texas, once we engaged, they said, "CJ, the reason developers love MongoDB, but you have not served us in the past, so you are not one of the standards on our marketplace. Let's fix that so that people can start building on MongoDB." So early, but the signs are very encouraging, and we are getting opportunity for newer workloads, including AI, through those top-down conversations. Okay, great. Mike, let's bring you into the conversation. Atlas has been sustaining around 29% growth the last few quarters. Seems to be largely led by large customers, while the newer AI cohorts remain a bit earlier. What is different about the workloads you're landing today, and how does that shape your view of the durability of the current trajectory and its potential to even strengthen over time? Sure. Thanks for having us, Matt. Let's talk about the workload growth as it relates to the durability. In answer to your first question, we've not seen very much. There hasn't been a big difference between the workloads that we signed historically versus today. There's always some nuances by geo or by sector. What's really driving the growth is three things. One is as we've continued to increase our go-to-market focus on the larger enterprises, as those workloads grow, we have two jobs. One is to get more workloads, and the more MongoDB we have in there, it gives us the ability to expand our workloads. That's number one. Number two is the cross-sell, especially related to Vector Search and now embeddings. While almost half of our large customers have multiple products, the revenue contribution from that is still quite a bit lower, so that's the job to drive it up. What underpins all of that, Matt, is, hey, Jim Scharf and team have done a great job on the reliability and the performance of Atlas, and that has enabled us to limit the churn and contraction in that base. We expect all of that to continue, which is why it gives us confidence in the durable growth. Again, not much difference in the workload trajectory, but that's really what's driving the growth in those large enterprises. Okay. CJ and Mike, for you guys, AI demand is clearly building across the frontier labs, AI natives, and a little bit on the large enterprise side as well, but each of them are on a different adoption curve. Can you walk us through the pace of new workload acquisition across those separate cohorts, and how you see each of those beginning to influence Atlas consumption? Yeah, I'll start and then Mike can contextualize in terms of how we think about the durability of it and what does it mean is even some of the examples that I have publicly used with the permission, so for example, ElevenLabs. ElevenLabs is doing phenomenal. They started originally with a first-party service from a hyperscaler that could not scale as their number of agents were scaling. AI is their business on speech-to-text and text-to-speech, and then one of the founding engineers realized that this is not scaling the agentic workload for ElevenLabs, which is now doing north of $500 million in ARR, very successful company, and switched to MongoDB. That was the call made by the founding engineer in Europe. What they shared were two things. Number one is having search, Vector Search integrated into the operational layer made it simpler for them to scale. Before, they were taking this data out of this first-party database, putting it somewhere else for search, data pipeline, fragmentation, all kinds of performance issue and outages issue. So one is now they have peace of mind. If you talk to Marty and the team, they say MongoDB just works. That's one. Second thing on your question, a year ago, they were not even a customer. Including some of the Frontier Labs example that I have shared, a year ago exactly September, they were not a customer. So we are early, and that's why Mike and I continue to say that we are early, we are optimistic, and we see that some of these folks don't start with us, and some of the folks do start with us, but that's a minority. Most when they hit scale issues with Postgres or relational flavor, whichever they are using, then they switch over to MongoDB. So that's why we continue to say, including the remarks last week, that we are early. Yeah, and just to add to that, thank you, CJ. We've talked about the growth vectors here. AI natives, we love that. Lots of customers still early in the process. The labs, the same thing, very large customers. Our goal is to continue to increase that. For us, the big inflection point is when enterprises start to deploy AI and scale. So this is growing still relatively small, but we've seen great traction, and we do think it will continue to be a driver of growth. It's really that enterprise piece, which is the inflection. Yeah. And I think one last thing I do want to touch on is what really encouraged me over last couple of quarters since I've been here is the new customer acquisition. When we look at Voyage, predominantly that acquisition is coming via coding agents, right? Whether you go to Claude Code or Codex and you say, "What's the best-in-class embedding model?" Even though OpenAI has their embedding model, the answer typically almost always is Voyage AI, which is helping us on the top of the funnel to be able to upsell and cross-sell Atlas. That's number one. Number two, getting 2,900 net new customers in Q2. This will become future customers of Atlas in a meaningful way, some of them. The Voyage piece is important because the Voyage is almost always an AI workload. Yeah. That's why they are using us, obviously, the embedding model for. That we'll see how that plays out because Voyage acquisition only happened 18 months ago. But the number of logos and the quality of logos that I see that are signing up with Voyage is high. Okay, great. Ben, let's bring you in. CJ just referenced how Voyage is actually generating a lot of activity vis-à-vis the coding agents. But I think when you look at the broader ecosystem of new applications, a lot of that seems to be defaulting to Postgres, right? How much progress has Mongo made in getting considered from day one, and are you seeing that translate into more greenfield wins? Yeah. Thanks for the question. I think, couple things. A few weeks ago, we had our Build Fest down here in San Francisco. We just announced another integration yesterday with Vercel, but what we announced a few weeks ago was we've always had an MCP server, and the MCP is really like a gateway for the agent to talk to something else, right? We made that significantly better to where the friction between the sign-up provisioning and then actual usage now doesn't exist. When we announced that a few weeks ago as well as what we did yesterday, now the ability for the model or a coding agent to not only select us because it's the right technology decision, but we also will get benefit of the fact that there's no friction into that process. That's really going to be a big, I think, driver from a discoverability perspective. Now we are there in the same spot as some other players. But at the end of the day, the models are making two decisions when they make a tech stack decision. The data model and then technology. They're making the right decision on the data model. It's all JSON. They're making the wrong decision on the technology, and that's the content game that we've been talking about over the last few months, and there's a lot of investment going into Reclaim the Bay you've heard us talk about, and we're going to continue investing in that awareness activity. Yeah. I would say, just we shared this on the callbacks last week, is we currently between August 13 as Ben outlined, and today is September 10. The data seems encouraging once we have this managed MCP across Codex, Claude, and Grok build. Our intent is if we get more data points to be able to share at Investor Day, but this was critical piece of integration that we had to do with coding agents for them to know MongoDB as much as humans do. Okay, great. The last thing I'll just add just real quick, our MCP is unique in a sense where a lot of MCPs for databases just provide data access. Yeah. Ours actually allows you to do the data access, but also allows the coding agent to do provisioning of clusters. By having the MCP be able to do both, it opens the door up for that frictionless experience. It's pretty unique in that case. Okay, perfect. CJ, one of the more interesting examples this quarter was a frontier lab using Atlas as the memory layer for inference. Yeah. As agents become more persistent and personalized, how significant could memory become as a distinct new workload for MongoDB? I would say first, when I really understood the use case with one of the labs, they started with one product to use us as a both short-term and long-term conversational memory that got saved in MongoDB. MongoDB from unstructured data perspective is the best place to save it. It kind of makes sense both across read and writes. The same lab for another emerging product also is using us for the same use case. This is something that customer drove the demand in this case, and now we are using that with enterprises to say, "Here is how a particular lab for this particular use case uses us for memory." We are, I would say, early in positioning that correctly, and then depending on the customer, they understand it. I was with a large insurance firm and we said, "This is how MongoDB is used as a conversational memory, and this particular lab is using it." And they said, "Oh, we have the exact same problem. The current solution we have is not working well. Let us do a POC on that." Emerging use case, we'll share more at the Investor Day around this whole memory phenomena, but that is definitely a clear MongoDB advantage right now. Okay, I want to switch gears to EA. It seems for years the infrastructure conversation was only moving in one direction toward public cloud. More companies are now looking at self-hosted and sovereign environments as deliberate choices. It's not MongoDB specific. We're seeing this across the broader software ecosystem. CJ, I guess the question for you is what's driving that change and how durable do you think that'll be? Yeah. Mike and I speak about this all the time in what is driving this demand? That's the question we also got last week because 36% growth in a long time across industries on Enterprise Advanced, self-managed was phenomenal. For the first time, as you saw, we raised the guidance in double digits for EA, 11% that we have not done in three years, right? Last two years was 7%. One thing is we do want to meet customers where they are. I would start there first. In my early days with MongoDB, the customer feedback, whether it's related to a customer, say, in France or the U.K., or whether it's in the United States or even Canada for that matter, was for a variety of reasons, whether there were public cloud-related constraints or whether they wanted to build the AI layer in-house on-prem, because if the memory prices are going up, clouds are going to charge you more, economics may not work. I'm going to now run this in on-prem, and our ability to run anywhere was a clear advantage. But what changed in 2026 from my standpoint, we are nine months in, is confluence of three things. One is public clouds definitely have capacity issues that they're talking to even regulated industries, whether it's banks and other places. Number two is certain workloads, because of the cost-related issues besides the capacity-related issues, they want to run on-prem now. Then specific to AI, getting these workloads AI ready, they would rather run it in-house. From a database standpoint and a modern database standpoint, we are the only one who can say that you can run that. One last example I would share, a large financial services firm right here on the U.S. West Coast told me they will move even more workload to Atlas if we can do a proper failover between Atlas and EA. This is not coming at expense of Atlas. This is also helping us with Atlas because certain workloads will go to Atlas, but certain workloads, they like that we have this option. That's how I see it. The initial demand is high. Ben and the team got search and Vector Search done on June 30th, which has now created pipeline robust for AI workloads in self-managed environment. That's why Mike and I felt comfortable last week to say we will grow double digit for the year. Mike, you want to add anything? Yeah, Mike, maybe let me just double-click on this because I think if self-managed demand is becoming more structural than, let's say, episodic, how is that going to change the longer-term profile of MongoDB? We think it will have a material impact on the growth. In the past, if you look back a couple of years ago, again, we'll talk about EA ARR to get the duration out of there. If that was growing in low single digits, now what we're talking about is ARR three straight quarters above 10%. It's not 29%. We understand that the ARR growth is significant. We now look at it that we have two durable growth drivers between Atlas and EA, or self-managed, and we do expect that to continue all the things that CJ just talked about. The other thing I want to make sure, we get this question a lot, which is, if a customer uses EA, does it come at the expense of Atlas? Our answer to that is a definitive no. If you look at the EA population, a good percentage of those also have Atlas, especially in the larger customers. If you look at the Atlas consumption growth in that cohort that has EA, it is actually higher than the total company. That is what CJ is talking about. More Mongo is good. More Mongo, either Atlas or self-managed, we do not see it cannibalizing Atlas. We actually see it contributing to that growth. At some point, do some of those workloads move to the cloud? Possibly. We will see what happens, but we want more Mongo to drive both EA and Atlas, and that is what we are seeing in that cohort. Okay. CJ, let us move to modernization. You talked about this at the top of the discussion. We are beginning to hear examples of AI compressing legacy migration timelines. Yep. Are you seeing the same thing, and how much could it accelerate the pace at which customers move to MongoDB? Yeah. Mike and I shared in the beginning of the fiscal year that we have asked our engineering teams to focus this year on making sure we get the product right. Here is what I mean by the product, is that the original approach that was taken, rightfully so, was a very people-centric delivery approach. We will look at the workload, and then we will move it to MongoDB, whether it is EA or Atlas or whatever the case might be. The team, we gave the team the investment needed for them to focus on the product that does leverage AI, whether we leverage Claude or whether we leverage Devin, it does not really matter. We will use AI, and our intent for this product team was very simple. Please work with 10+ customers that they are currently working right now, with 10+ customers. Create a great product by end of this fiscal year, which they are working on today. We want to reduce the modernization timeline from years- to- months, and months- to- weeks. If you look at a workload, hey, originally, it may have taken 18-24 weeks. Can we compress that to 4-8 weeks to fully modernize database as well as the app layer? On the app layer, because that is a lot of code, sometimes the code is in PL/SQL at Oracle. I wrote a lot of PL/SQL procedures when I was at Oracle. That is a code that works really well within Oracle's physical boundary. Can we move that over to whatever the customer wants to move that over? Right now, we are seeing encouraging signs on leveraging AI to be able to get to the destination. Of course, we want the destination. If the customer wants from architectural perspective Atlas, then it could be Atlas. If they want one of the sovereign customers who is doing that in EA, that is fine too, because that is their decision. This year is about creating a great product so that we can reduce the timelines from years-t o- months, and months- to-weeks. Then we are going to ensure that is something that Mike will figure out with the team. How do we articulate that opportunity when the next fiscal year starts? Mike, what do you say thus far? No, I would agree with that. A lot of this is, hey, folks, we have done migrations since the beginning of Mongo. This is all about building the product and the tooling to actually help with the modernization of the applications. To CJ's point, we want that to be more tooling, less people, and also a lot faster so that not only customers see benefit, but we do as well. So we took a step back in 2027 to make the investment, and we certainly hope to see that as we go into 2028. All right, Ben, let us shift to you. AI gets most of the attention, but the core database has also become substantially faster and more efficient. Are those gains changing the kinds of workloads customers are willing to put on MongoDB? I wouldn't say it's changing the type of workloads. We're always getting absolute critical workloads from any type of industry, whether it's financial service or insurance or any other regulated industry. We have the real revenue-driving keys to the kingdom, credit card applications, swipes of transactions coast to coast. But what it is allowing them to do is provide a couple different things. One, it gives them the flexibility to have a more available capacity so they can handle their own spikiness in some sort of workload. But number 2, as enterprises are experimenting with how they're using their own AI experiences, whether it's chatbots or customer service apps and everything else, there's more activity that is hitting the database, hence why we are so big on the real-time data access and the real-time data needs of AI. It gives them the flexibility to experiment and prototype what these experiences could be against that operational data without having to spin up playgrounds or move data around or have data pipelines off, and then it becomes stale again. So that performance is really not about how much they spend on us. It's more about the fact that they are driving more utilization and more use cases using the same sets of data. Okay. CJ, let's shift to competition because I think what we seem to be seeing in the market right now is a lot of the analytical platforms are now encroaching on sort of the operational database category. So to the extent these categories do start to converge, where do you think customers will consolidate, and where will they continue to value an independent platform? Oh, absolutely. So it is very clear that analytical players see huge TAM on OLTP side. That has always existed, but they see TAM on the OLTP side, and then they come up with a hybrid architecture to say, "Here is how we can do. If you want to build your AI agents, you want transactional data, you want analytical data, batch data, doesn't really matter, we'll give you that answer." Even in my early days at Oracle, this was there. Oracle was great for OLTP, and we tried to go after analytical workloads, late 1990s, didn't succeed, so ended up buying multiple companies in that space. So this whole thing of OLTP folks trying to do OLAP force has been around, as you know- for a long time. The way it plays out in customer conversation, which is where it matters to us the most, is that where we are the standard or one of the standards, whether it's retail, manufacturing, healthcare, or financial services, that doesn't come up as often to say, "CJ, we are going to move this massive workload on payments at a bank in Spain," real example, "to something from this analytical player because we use that analytical database for data warehouse." It's not playing out in that sense. Where it potentially plays out is somebody wants to just spin up a quick instance on OLTP to be able to do that because it comes from that particular company. That's where I see it playing out. Ben and I speak to customers a lot, and nobody has come and say, "Hey, because of their, this HTAP architecture," or whatever you want to call it, "now we are thinking of moving from MongoDB to another version of Postgres that these analytical players have. Okay. Because those have existed. You agree with that? Yeah, I agree. I just think the stakes are different. I think OLAP has its place for sure, especially long-term archival needs and everything like that, but the stakes are different. That's why if we remember the early days of cloud when we first launched Atlas, I've been here nine years, we launched it 10 years ago. Some of the first customer conversations I remember having about when we were selling into Atlas, it was so frustrating because they were using Snowflake and they're like, "We don't put data in the cloud." I'm like, "But you are." They're like, "Yeah, but that's OLAP data. This is critical OLTP data." So I just think the stakes are different. So I think maybe as CJ said, like for playgrounds and things like that, sure. But what really matters to be powering these agentic applications or these experience that all of our customers want to be able to provide, they need access to the same data the actual application is driving. And that's high stakes critical infrastructure for that application that could be generating billions of dollars for that company. Yeah. CJ, let's talk about Voyage for a moment. I'd love to get your perspective on what the pairing of Voyage's retrieval models with Atlas made that acquisition strategically compelling, and how do you see that combination changing the workloads MongoDB can win and the way customers can expand on the platform? And Ben, obviously you were here for Voyage, so I would love to get your perspective as well. Yeah. Why don't you start and I'll tell you where we are with it? Sure. So we actually launched the public preview of Vector Search before ChatGPT launched. So we were looking forward as far as where the industry was going from an AI perspective, and that's why we built the Vector Search. And before we even thought about acquiring Voyage, we supported whatever embedding model that you wanted to bring in. What made Voyage strategic for us was a couple different things. One, from an AI awareness brand perspective, Voyage was obviously super hot. They had the top-ranked embedding models. They still do. We're investing a lot there. But what we were also learning from our customers, which was really the same thesis that we always had with Atlas and why we added Atlas Search the way we did, why we added Vector Search the way we did, is it's a singular platform with the same interface, with no data pipelines, no copying data for just same use cases. Our thought was, could we do the same thing for vectors, and could we do the same thing for AI? So why would they want to go out of the platform to actually do the embeddings? So the main thesis for acquiring Voyage AI was, let's get this into the platform and then instead of the data leaving the boundary, and again, we're dealing with an insurance company, they don't want their proprietary data being moved all over the place. They want to have it stored and located into a singular place that they can trust. So bringing Voyage AI into the fold, that entire closed loop, the entire use case, including re-ranking now, is all built in and automatic in the same platform. Yeah. The way I see it playing out with customers right now is we talked about a lot of self-service Voyage AI customer growth is coming via Claude Code and Codex, period, full stop. We are getting some through our sales team, but the new customer growth on Voyage AI is mainly coming from coding agents, which is excellent because like Ben said, these are the best-in-class embedding model. We are still ranked the top, and people do their testing. Now I'll say how it is playing out in the enterprise, which is our bread and butter, is I'll take two examples. One large media company that I spoke to and one large healthcare company, all in the Fortune 50 range, is they said, "Hey, we needed to vectorize the data. We needed the right embedding models. Of course, OpenAI recommended this. We use them for LLMs and so on." So besides retrieval and accuracy, which embedding models help, it also simplifies our data estate that Ben was talking about because all of this is in Atlas. We really like that, and we have done all kinds of testing. Anthropic doesn't have it, they recommend us as in Voyage AI. But OpenAI by default will originally recommend theirs. Then basically embedding models, Vector Search or semantic search, and operational data all working really well together with not many moving parts makes performance great, and that's why we used the example last week in the print about Financial Times. It completely changed. Then our Atlas grew, our vector grew there, and of course, they are now using embedding models. So that's how it's playing out. In the enterprises right now, we have one of the largest healthcare companies running an AI workload using Voyage, and one of the largest media company is running their media workload using Voyage. Okay, I am going to try and sneak two quick ones in in the last three minutes we have got here. Mike, for you have shown the model can deliver meaningful leverage. As you look ahead, where is it most important to keep investing, and how do you balance that against continued margin expansion? Yeah. So thankyou. So margins, not an unimportant topic. So in fiscal 2026, and this is really in operating expense, we took a step back and said, "Hey, we need to rightsize and make sure we are spending it in the right place." We did a small restructuring in sales to be ready for that. In fiscal 2027, we have continued to invest mostly in engineering, embedded in the guidance, and the margin expansion is almost a 30% increase there. You are going to see a lot of the fruits of that labor in a couple of weeks when we get to Investor Day. Sales and marketing, we have continued to invest in quota-carrying sales as well as marketing awareness, largely call it growing in that middle teens. As we go forward, you will see us probably spend a little bit more on sales and marketing in really three areas. One is we need to drive quota-carrying reps. They have done a great job driving productivity, but we need to support that group. Also, as Voyage gets bigger and AI natives get bigger, we need a better team to go drive that growth. Folks, we have a great partner network, but we can do better, and we want to make sure to invest in that. Super clear. You will see R&D continue to grow, probably at a lower percentage. That is really where AI will help as well. All of this within the margin constructs we have given you. The business model allows us to invest a ton of money because of the growth in the business as well as the gross margins and still drive margin improvement. And that's why we made the point last week quickly, Matt, is that the growth of self-managed EA also helps us to invest because that straight flows to the bottom line, and we absolutely love that. That also helps us with the total revenue growth, which is accelerating for a second year in a row. Great. CJ, with the last minute we have here, as you look across everything we've discussed, what's the most important thing MongoDB still needs to prove to become the platform you believe it can be? I think it's pretty simple. So one, what I would end with, MongoDB still has massive potential in a large growing market. So that's number one. We are the most modern database, but when I look at the data platform with Vector Search integrated, now embedding, and few of the other exciting announcements that Ben and Pablo will make on September 29th, feel really good about the product because it has to be a great product or a great platform. Three things I'm watching out for is besides the growth in core and the AI natives that we just talked about, this managed MCP offering that we launched on August 13th, we must have agents, coding agents love MongoDB, and be able to work in Atlas the whole time through those coding agents. So that was the first right step in the right direction, and the team will do more. Then the third piece is how do we approach modernization using AI? This is a long-term strategic statement. It's also very important because many of these large customers of ours do want our help to modernize their workloads. Excellent. That's a great place to leave it. Thank you so much for joining us all today. Thanks for having us. Thank you, Matt.