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

Please welcome MongoDB President and CEO, Dev Ittycheria.

Thank you. It's great to be back here in New York City at MongoDB.local NYC. And I'm really grateful for all of you to spend time with us today. I know all of you have super busy schedules. So it means a lot that you want to devote today to be with us. I also want to take a moment to thank all our incredible sponsors, especially our global sponsors, AWS, Google Cloud and Microsoft as well as our gold sponsors, Accenture, IBM and Infosys and all the other sponsors who really made this day come together. Please take a moment during breaks to go to their booths and get a sense of how they're using MongoDB to partner and build better solutions for all of you. We have a fantastic day ahead. There's over 50 sessions, deep dives around the technology, customer case studies, hands-on workshops, and there's multiple opportunities for you to earn skill badges throughout the day. And to make most of the day, if you haven't already done so, I recommend you scan this QR code to really understand what's all going on -- happening on this floor and the floor upstairs, so you can make sure you can go to the events that are most -- and activities that are most important to you. Just to put things in context, this is MongoDB.local NYC and we do this all around the world. So this is going to be one of over 20 events we do in North America, Europe, Asia and Latin America. So our goal is really to meet our customers where they are. We run a truly global business. And since the last time we were on this stage, we've had tens of thousands of people attend these events all around the world. And now we're back here in New York. This year has been marked by some great milestones. I just want to give you a couple in terms of giving some sense of our business. When I first joined MongoDB, we're a fairly small company, still with a decent name, but still unproven. And we had roughly 1,000 customers, and we were doing a little under $40 million that year. Just to put things in perspective, now we have nearly 60,000 customers who -- and Wall Street estimates that we'll do about $2.4 billion in revenue this year. To put that in perspective, we do now in 1 week more than we did when I joined 11 years ago. That gives you a sense of our growth. And the point is that our growth is as much about you as is about us. It's really a reflection of all the incredible work you're doing to use MongoDB to run and transform your business. And to give you a sense of the kinds of companies we have, we have companies of all shapes and sizes for all kinds of use cases across almost every industry and every geography using MongoDB, including over 70% of the Fortune 500 as well as AI-native startups you may have heard of and even some you have not heard of. And they've all recognized that the relational database is not best suited for today's modern requirements. Companies like Toyota Connected that powers critical vehicle safety systems around the world, McKesson that manages highly regulated pharmaceutical supply chains, Coinbase that operates reliably through immense market volatility and electronic arts that delivers always-on gaming experiences. These companies realize they need a modern, highly flexible and scalable solution for today's challenges. So I think it's not hubris to say that we are the world's most popular modern database, and we're consistently ranked at the top of developer surveys that highlight this. Now the reason for our popularity is that the alternative out there is the relational database. And you have to remind everyone that this was originally conceived over 50 years ago when the world was a very different place. And not many people know this, but the founders of MongoDB were also the founders of a company called DoubleClick. DoubleClick was one of the first web-scale apps that have to serve billions of ads per day to consequently that to deal with massive amounts of data. So they observed the constraints and limitations of the relational model firsthand over 20 years ago. The first constraint is that the relational model is incredibly rigid. It's designed for a world that was very uniform and very predictable. Well, we know that's not the case today. It's also very brittle. It's hard to make changes when your business needs to respond to new opportunities or new threats, and it's awfully challenging to scale. So the MongoDB founders became tired of investing more and more time and money and effort to work around these constraints. So they said this got to be a better way. And that epiphany was what we call the document model. The document model built on JSON as we believe, we would argue, is the easiest way to organize and work with data. It allows you to model and represent the messiness, the high interdependence, the constantly evolving nature of data of the modern world. It has the flexibility to handle a wide range of data types, which is so important when 70% of the world's data is unstructured. It offers agility to easily make changes as your data model and your business do the -- your data model, as your business changes, and it also enables you to do that when the pace of change is only accelerating. And because Mongo is built on a distributed architecture, it offers unparallel scalability and performance. And we think that the pace of change is high today, it's only going to get faster with AI. If your business is built on a technology that doesn't adapt well to change, you simply will not be able to keep up with the competition. So the principles of the document model are even more relevant today as we transition to a world powered by AI. So at the risk of being trader being a cliche, we are entering into a new era of how everyone will use this technology to transform their business. And hopefully, what I'll try to do is explain why the database you choose matters more now than it ever did before. And the first generation of AI tools have been really focused on what I call end user productivity, making developers more productive with code-gen tools, making customers support personnel, more productive with conversational chatbots, making business users more productive by summarizing documents, synthesizing them and creating new documents but this is just the beginning. The next wave of AI applications are all about agents. And instead of single-purpose chatbots or autocomplete on steroids, agents are most similar to the way humans actually think. We focus on an outcome, and then we decide what are the process and steps and tasks we need to take to get there and agents operate the same way. So they won't just make us more productive, they'll actually drive true business and industry transformation. . So just to level set of what an agent does, we should use this -- I use these definitions. I believe agents can be understood as systems that perceive, decide and act in a continuous loop of desired outcomes. They could be a simple shopping agents, a travel planner, a financial analyst, a legal assistant or anything you can imagine across a wide variety of domains. And so while a large language model provides the reasoning, it is the database that gives the agent memory and state. So in the perception phase, this database supplies the agent with context such as user preferences, prior actions, constraints and enabling it to understand more than just the immediate input. In the decision phase, the database helps with planning by providing accurate facts so that the LLM can help the agent decide what to do. And in the act phase, the database captures the outcomes of the new state of things. Consequently, the database is the agent's memory and source of truth, allowing it to operate coherently across multiple cycles and even coordinate with other agents. So to make this come to life, I'm going to give you an example that I think everyone could understand. Imagine you and your partner want to go on a vacation, you decide, you know what, we want to go to the Amalfi coast and we want to take some time and enjoy the scenery there. So you use your AI agent to define what are your budget constraints and what are the dates that you want to travel, and then you start the process to book your vacation. Now the agent may also know that you prefer boutique hotels, restaurants may be off the beaten path that you like morning flights and that you tend to favor water excursions over long car drives. With this context, the agent builds a tailored plan that fits your constraints and your preferences really without your involvement. And as the itinerary takes shape, the database acts as the ledger, recording the actions have been taken, the cost and timing of flight to Naples, the booking of a hotel in Positano and a dinner reservation in Rabelo. These are all log the database. And because all the state is stored, the agent can reason clearly about what remains, how much budget I have left what days are already committed and what choices have already been made. So the database is not only the memory of the past but also drives the constraints so that each new decision fits into the overall plan. Now God forbid, if that Naples flight is canceled, the agent will immediately see what other flights are available, understand the existing itinerary and replan around those immovable or important events or if a coveted restaurant table suddenly becomes available, it secures the reservation and reshuffles the itinerary accordingly. So the point here is the database is at the center of making that agent adaptive and proactive turning what used to be a brittle booking engine into a capable and responsive travel manager that can orchestrate an enjoyable vacation within time constraints, budget constraints and even factor in challenges in any unanticipated events. So you can see how memory, context, state and real-time data enable you to build a powerful agent that can transform your business or even your life. Now obviously, I've shown you a very simple example, but as the technology matures, there's no question that agents will transform every industry and every company. But the funny thing is, given all this promise, this hasn't happened yet. In fact, in a recent MIT study, it highlighted that 90% of corporations have failed with their AI projects. And the interesting thing is not because of the LLMs but because of the lack of the ability to use memory for complicated AI use cases, being able to store and retrieve memories and applying that context to problem solving and decision-making is a massive factor for delivering high-value and transformative use cases. So if memory is so crucial, you need to think very, very hard about the database that can deliver on these capabilities. So then the obvious question is, what does the ideal database for AI look like? Well, let's go through the requirements. It obviously has to model the complicated nature of the modern world and the world that's constantly changing. It needs to perform sophisticated search and retrieval across raw data, metadata, embeddings, et cetera, to find the right information quickly and easily. And none of this matters if you can't trust your database. It needs to support an environment where the intensity of usage is far higher than ever before as agents don't take breaks, they don't go to lunch, they don't go home at night and they certainly don't go on vacation. So these would be massively performant and scalable and incredibly secure. So given these requirements, let's take a look. Well, we know that JSON is the best way to model the real world. And this is what MongoDB delivers. We are a native JSON database, the ability to handle all types of data and adapt and change very, very quickly. But what's also interesting is that JSON has become the language of AI. LLMs are trained on JSON. MCP emits and consumes JSON. Other adjacent technologies use JSON. So bring this kind of dynamic data into MongoDB is so easy and so seamless. Second, our advanced search and retrieval methods go far beyond simple queries. We use both keyword and exact matching, but also you can search on meaning and intent. So you can do a hybrid query of vector similarity search, a keyword search and search on metadata filters, all in one pass. So this means that developers can build AI-powered agenetic applications without having to stitch together multiple separate databases or search engines. So this is a far simpler path to more relevant and accurate search results. And then embedding something that people have only started to appreciate now are the bridge between a customer's private data and the LLMs. And what's clear is that the higher the quality of the embedding models, the better the LLMs can reason to improve their output. . And through our acquisition of Voyage AI at the end of last year, we are providing the industry's leading embedding and reranking models by optimizing most contextually rich domain optimized embedding. So what said in another very simple way, MongoDB sits at the gateway of meeting of an AI system. And last but not least, as we said, we have thousands of customers. Our platform is battle tested, pushing on performance, on availability, on security. And I mentioned earlier that over 70% of the Fortune 500 rely on MongoDB. And that's not by accident. That's not something a new company or a new technology can replicate overnight. It takes years of investment, a focus and experience to do that. So what's interesting is you can see MongoDB doesn't just check the box on the list of requirements, it actually defines them. And what's clear is that our architecture wasn't retrofitted to meet the requirements of the modern agentic world because we were actually built that way from the start based on the document model. So if I go back to my original question, if you ask AI, what's the ideal database that will power the monogenetic world? And I encourage all of you to ask your favorite frontier model, I think it will look an awfully lot like MongoDB. . And these are just a few of the thousands of customers who are putting us at the center of their AI journeys from large incumbents to native AI start-ups. And you'll hear from some of them today. So companies of all sizes are building their AI future with MongoDB. And again, I want to emphasize that memory and state are key to developing transformative agentic AI applications and think of the right database is even more critical today than ever before. So we have a great day planned for you. What you're going to hear today is about all about our latest release, MongoDB 8.2, it's our most feature-rich and performance release yet. And you're also going to hear about the next generation of encryption, we call queryable encryption, which is an industry-first security capability that no other platform has. You'll also hear about Voyage's leading embedding models, natively integrated into MongoDB, delivering state-of-the-art accurate and trustworthy models to build more reliable applications. And our new application modernization platform is something we're super excited about. It's engineered to help customers cut the risk, cost and time of updating and migrating legacy applications. So our approach is an agentic approach to leverage it to transform code and schemas. And we believe enterprises will be able to move 2 to 3x faster from their legacy system to MongoDB using this new approach that we call it app. So there's obviously a lot of us very excited about what we're doing here today. So what I'd like to do next is to welcome who I affectionately call the wizard, one of our most senior product leaders [ Oz Olivier ] and he is going to give you a lot of detail about the foundation that we're building that talks about MongoDB 8.2. Os?

Thank you, Dev. Now I'm a little biased because I've seen firsthand what our teams have put into the database. But I generally do believe MongoDB is the strongest foundation you could have for the agentic future Dev just described. MongoDB 8.0 shipped just last October, and it's already become our fastest-adopted release ever. More than half of Atlas clusters are already running it. That's because 8.0 delivered more of what your applications need now and what they will need in the AI era. Compared to our previous release, 8.0 achieved 36% more read throughput for read-only workloads 59% higher throughput for bulk updates. And for common time series workloads, we're seeing an incredible 200% faster time series reads, thanks to advanced block processing. But 8.0 wasn't just about performance. We made the database easier to operate at scale as well. For this, we've added new insights into how queries run so you'll see bottlenecks before they ever slow you down. And once you shorted, we've made it easier to keep up with your applications by making re-shorting up to 50x faster. And if that's not enough, in 8.0, we also optimize the database across concurrency, memory management and query execution. So every application will run better just by upgrading. 8.0 set a new bar. So of course, we couldn't wait to raise it again. That's why today, we're announcing MongoDB 8.2. As we enter an agentic world, performance isn't just about pleasing human users. It's about machines talking to machines, applications calling agents, agents calling other agents, all in real time. Not only do agents not take lunch, they never sleep. It's an unforgiving workload where every millisecond, every throughput gain matters more than ever. MongoDB 8.2 takes another big step forward in performance to meet the challenges of this new era. In 8.2, unindexed queries are up to 42% faster, which means even when requests are unpredictable, responses will stay quick and reliable. Rate reversals, the kinds of queries that dig into more complex data structures are about 20% faster, making operations smoother end to end. And time series bulk inserts run nearly 3x faster, so you can ingest massive streams of machine-generated data without hitting a wall. We're also, as always, focused on security. And we steadily advanced queryable encryption, a true industry first. The enterprise-grade security technology protects sensitive data at every point in its journey. Most database vendors only protect data at rest or in transit over the network. But when data is in use and being processed, it's often left exposed to administrators and service operators. Unique to MongoDB, queryable encryption closes that loop. It's the first fully integrated database technology that keeps data encrypted, not just when it's at rest and in transit, but also -- and here's where the big difference is, while it's actually in use in memory. With queryable encryption, MongoDB ensures your data can only be viewed by the authorized application while still remaining searchable with expressive query types. With 8.2, we've expanded what queryable encryption can do. We started with support for exact match of quality queries and expressive range queries across numbers and dates. Now in 8.2, we've added substring support, letting you search encrypted data with prefix, suffix and partial matches. Imagine the possibilities. A doctor or a nurse searches by patient name and autocomplete finds the records, but the data behind it never leaves its encrypted state. A bank analyst flags accounts by the last 4 digits of a social security number without ever exposing the value in memory. This is a breakthrough that keeps your most sensitive data secure at every single step. Across performance and security, these are all really exciting improvements. And we know many of you want access to them right away, even if you're not building on Atlas. Bleeding edge builders don't have the time to wait. So starting with 8.2, every incremental release will now be available across Atlas, Community and Enterprise Advanced. This gives you the freedom to put new and advanced capabilities to work the moment they're ready. And for those applications that are sensitive to change, I need to stay on a release longer, we've got you back here, too. Currently, major releases are supported for 3 years. Starting with MongoDB 8.0, I'm very excited to announce that we're extending long-term support from 3 to 5 years. It will give you more stability when you need it and the freedom to innovate on your own schedules. Having great upgrade options does not only apply to new features. It also applies to where and how you want to run MongoDB. Because with MongoDB, you don't just get a database. You get a consistent foundation that runs and everywhere your applications need to be, whether you're developing on a laptop, running in a data center or using Atlas in the cloud. It's the same skills, the same features and the same experience. You only needed to learn one database, you only need to learn one API. Now if you choose to run in Atlas, you can run on AWS, Azure or Google Cloud. Atlas has more than 120 supported regions worldwide across all 3 major hyperscalers. You can keep data close to your customers, meet governance requirements and integrate with native cloud services wherever you operate. But Atlas can do a lot more than just run on different clouds. Atlas supports a single cluster spanning across multiple clouds. So you can leverage each provider's unique features and specialized infrastructure from a single deployment. This is especially important today when it comes to the fast-evolving AI landscape. This flexibility ensures you can always take advantage of new AI capabilities regardless of what cloud they're available in. So whether you're managing MongoDB yourself or relying on Atlas as a fully managed service, you stay in control, free to deploy, move and scale in the way that best supports your growth today and in the future. With MongoDB, you get the foundation you can count on with performance to power demanding applications, security that protects your most sensitive data and the flexibility to run anywhere. There's so much more to tell you. So please attend the session later today to learn more. Performance and reliability aren't just features of our latest releases, they're the nonnegotiables our customers depend on. So let's hear from one of them now. McKesson is a leading pharmaceutical distributor who provides prescriptions for over 1/3 of North America. The applications that they run on MongoDB play a vital role in making sure essential medications reach the patients they need. Please join me in welcoming [ Brian Schmidt, Pendrick O'Carney ] in conversation with MongoDB's very own Melissa Plunkett.

McKesson has been called the largest health care service provider that you've never heard of Upendra, can you give us a sense of McKesson's scale and impact and your individual roles in the mission.

Absolutely. Thank you for this opportunity. McKesson is the largest drug distributor within the United States. We serve about 40% of the Rx products within the United States. 1/3 of the medication is supplied by McKesson across the North America. And within McKesson, I work as a principal product manager, and I have been with the company for about 15 years. .

Brian Schmidt, principal IT architect. I've been working with the DSCSA systems, which is one of the systems we're going to talk about today, but -- in addition to McKesson being the largest, we're one of the oldest too, well over 200 years old, which is kind of astounding in today's market, right, where you have all these new up and coming companies. We've been around for a very long time in this industry, and we continue to be successful.

Fantastic. Thank you so much. Now there was a regulation passed in 2013, the Drug Supply Chain Security Act or DSCSA, that you just mentioned, Brian, for those unfamiliar with it, what does this regulation require? And at a high level, without getting into a lot of technical details just yet. What kind of challenges does that create for a company like McKesson?

Yes. I think -- so DSCSA is a new regulation to help patient safety. Back in 2013, the states were starting to organize around coming up with ways to protect counterfeit drugs. And so a coalition formed at the federal level to help us make sure we had a unified market in the space. And really, what it means is every pharmaceutical product drug every bottle has a unique serial number within the globe. So if I get a particular bottle, I can scan that and authenticate that drug all the way back to the manufacturer, if I needed to, enhancing the patient safety and the efficacy of the drug. .

Fantastic. Now I understand that this is a pretty massive scale. We're talking 1.2 billion serial numbers, and I believe that is annually. So it's billions of drug bottles where accuracy is critical because as I understand it, even small errors could impact patients. Is that correct?

That's correct. So for DSCSA, one of the regulations is that the supplier has to send us not only the product, but the data. And if the 2 don't match, the challenge is that product is now as if it didn't exist in the supply chain. So you can think of a lot of drugs where we've had shortages over the last decade or so. Every bottle matters and when you come to a pharmaceutical supply chain. And so not only that, but when we send our product to our customers, we have the same responsibility. So our dispensers cannot receive or use that product unless we send them the accurate information. And it kind of changes the mindset because now you have a product in the data is just as important as the product itself to be usable.

Amazing. So now I understand the McKesson's first approach involved a specialized SAP compliance system together with PostgreSQL. But that setup couldn't serve your use case at scale. So we'll get to how MongoDB comes into play in a moment. But Brian, do you first walk us through at a high level what the limitations were and what kind of solution you ultimately had to build.

Yes. So we attempted at first that come up with 1 system to solve all of our problems. And what we realized at our size and scale -- it was almost -- it was -- it just became impossible. Once we started overlaying all of our use cases from receiving, picking, packing shipping and then trying to service our customer with the data that they're required, all the use cases just started to combine, and we couldn't scale on the platform. And so that's where we pivoted and moved to federating our information to be able to take our warehousing information, put that on its own repository and also take our customer information to put that on its own repository to help alleviate that bottleneck in that scaling.

Fantastic. Now as I understand it, you built 2 repositories. So you had this central data repository or CDR, and then DSR which is the distributed serial repository. So with the pain points for that first approach, what led you to go with that dual system?

Yes. So part of it was we had lots of requirements, so let me step back. DSCSA was a very new information, new regulatory requirement. We are out to build something that didn't exist. There's no off-the-shelf software that can go and buy or look at. So with this, all the new challenges in. We went with DSR to help break down the recalls from our warehouse management. So we have about 60 warehouses across the nation. We do about 2 million verification calls every evening in the supply chain. And with all those -- all that activity, we decided to go ahead and put a distribution-facing system to be able to handle those calls. . On the customer side, we have customer use cases where we have to supply information to 350,000-plus customers every day. And all that activity, unfortunately, happens all in the morning. So any time from 7 a.m. to noon is when everybody is wanting their information. And so it made sense to help separate that -- those systems out to individual use cases to make sure that we're able to be successful. .

Fantastic. So now you've decided on the CDR, DSR approach. So what tipped the scale toward MongoDB?

So a couple of different things, right? One of the key things was our data in the DSCSA world is very hierarchical in nature. And obviously, the document database fits that model very, very nicely. It was a very good fit. We also took a look at some of the performance metrics between MongoDB and other systems. And with our access patterns, and I want to make that key as access patterns is key here. We were able to get much more performance-related metrics out of the MongoDB platform than some of the others that are out there. In addition, we have requirements to also have on-prem systems as well as in the cloud systems. So allow our developers to go ahead and code once and deploy anywhere we needed to in order to make our business successful.

Fantastic. So now Upendra, systems built big day. So once you went live, how did it actually perform in the real world? .

I think it's kind of overwhelming and the kind of scale that we achieved, I think a big thank you to MongoDB as a partner, along with our partners as well. The GoLab has been as smooth as it can get. I think it's a moment that we all should be incredibly a bit proud of because if you see DSCSA, it is all about trust. It is about protecting the integrity of the supply chain so that our people that rely on our medication to manage their chronic conditions or flight infections, can trust, feel safe that the medication that they're getting from is safe, it is authenticated and that one that they can trace back from the manufacturer all the way to the pharmacy. .

Fantastic. I mean that is a huge accomplishment. You're really serving your patients well. And an enormous jump in scale, I understand it's 300x what you expected with no disruption. And so that means a lot of your patients. What does it mean for the team?

What it means it's a good question because if you think about it, DSCSA, right, one, it is not just another regulatory project that we can just check market. It is about leading the way. It is about setting the standard for how pharmaceutical companies should approach compliance, that is with integrity, with innovation and with a deep sense of responsibility. So having had this opportunity to work on critical projects like this that serve kind of the humanity. It's an incredibly proud moment.

Fantastic.

And one of the things you mentioned is the success we've had with this platform. So if you imagine shipping 1/3 of the pharmaceutical medications across the U.S. every second counts in the middle of the night. We did a study where even 1/3 of a second would add an additional 15 people across the network. So if you have a system that cannot perform or be performing, it drastically impacts the operational perspective of actually meeting patient requirements and getting the pharmaceutical drugs there. On the CDR side, just to give some metrics around this, we went from servicing 1,000 requests, right, before we went live to the next day, go doing 300,000 requests in the next day. And MongoDB was so performant, we did even notice it. There's no blip on the map. The outlets performed fantastic. And we're very proud of the success and what we're able to achieve in that area. .

So glad we could partner with you in that. And I have to ask back looking at the journey that you've gone through with advice would you give your peers in the audience, Brian, if they're tackling similar large-scale mission-critical challenges like this.

Yes. When I think about the entire journey, I think one of the keys was for me was partnering with MongoDB because they not only took the time to understand us, but they were really there for our success. I think when I was working with our account manager, Daniel Johnson, he said, "Brian, I just want you to be successful. We're here to help you be successful. And that made a big difference because with the DSCSA project, we are working with lots of vendors, lots of different technology. And MongoDB partnership stood out because they were able to pivot when we wanted to pivot. They were able to accommodate and be able to provide that leadership when we need it. And it was -- is very good, and I highly recommend anybody else to engage with you guys.

I'm so glad to hear that. Now all of this is going. It's fantastic. But I have to ask you, what's next? Where do you see the system in the underlying technology expanding in the future?

Well, I think having accomplished, having met the FDA deadline of August 27, it is now about how can we future-proof our operations, how can we leverage the technology to meet those ever-growing challenges of the health care industry and the patients alike. And we have quite a few things that are lined up. We are embarking. We are about to complete a use case with the Mongo team on the GenAI use case. And then we have a few more use cases that are lined up, and we are so excited to start our journey of proofing our operations now.

Yes. I'd just like to add, Mongo was key for us to accelerating our AI journey at McKesson. Being in technology, I think we've all heard of blockchain, if anybody remember those days when it was very popular. Blockchain was going to save the world. AI was kind of seeing somewhat similar in our technology space, but being able to partner, you guys helped us accelerate and see real-world results. And that's the key is real world results that can speak to the business, and that's just -- that was just fantastic.

Fantastic. Thank you both so much for sharing your story with us. Upendra, Brian. Thank you, guys.

Thank you everyone.

It's not often than we get to hear about how large-scale technology choices filter all the way down to the individual patients. Many of us right here in this room, and there are our safety. We really appreciate McKesson sharing their story with us today. Now McKesson's journey shows what it takes to run mission-critical systems at massive scale. Now we want to show you how those same capabilities can extend even further into powering a new generation of intelligent AI-driven applications. Please welcome my friend and colleague, Frank Liu, MongoDB Staff Product Manager.

Thanks, Melissa. AI is a broad term. But if I were to define it with a single sentence, it would be something like this. AI helps us create applications capable of understanding the world as we humans do. And this will really bridge the gap between computers and people. What does that actually look like in practice? Let's start by taking a look at some different applications that leverage AI. First up is retrieval augmented generation or RAG for short. RAG finds the most relevant information in a knowledge store using vector-based retrieval. And that information is then fed to a large language mall to generate accurate grounded responses. The ability to chat with developer documentation is a great example of this. Next up, our recommendations. This is the ability for a system to intelligently surface content that a user would like to engage with. If I'm shopping on e-commerce websites and add a coffee machine to my shopping cart, a good recommendation system will recognize that. I might also like to buy some coffee beans and maybe a milk frother as well. Last but not least, we have agent memory. Now earlier, Dev talked about agents and how they are critical to unlocking transformational change with AI. These agents require memory to maintain context and adaptive feedback much like humans do. A real-world use case is an autonomous digital campaign marketing team. And in this scenario, a team of highly specialized independent agents, such as a VP of Marketing, a market researcher, a copywriter, graphic designer, et cetera, et cetera, collaborate, to plan, create and launch a complete marketing campaign from a single high-level prompt. They use both individual and shared memory to coordinate tasks, maintain brand consistency and learn from their results over time. Bringing any of these use cases to life depends on 1 critical component, and that is the quality of your embedding models and rerankers. This is often the difference between potential and production. And before we go any further, let's do a quick refresher on embeddings and reranking. And embedded model is used to convert everything from PDFs to images, to audio or even code into an array of floating point values that capture meaning for software to process. The key thing to note here is this -- two embeddings that are close to one another in a high-dimensional space correspond to data that is related. Now as for rerankers, they compare each retrieve document directly to the user's query. You can think about it this way. You first retrieve results using embeddings and a reranker then reorders those results to improve accuracy. Stronger embedding models and rerankers improve the quality of our retrieval. And this results in a more relevant and grounded results for RAG; b, recommendation systems that actually drive more engagement and improve user satisfaction; and c, agents that remember the contents of past conversations. So embedding models and rerankers are so important, where can I get great ones? Well, I'm glad you asked. MongoDB Voyage offers best-in-class embedding models and rerankers. We have your typical general purpose text embedding models, which turn pure text into embeddings. In this category, the Voyage 3.5 series outperforms competing models from the likes of OpenAI and Cohere, all while being more cost efficient. We also have powerful multimodal models where typical multimodal embedding models are only capable of vectorizing a single photo or a single text string, Voyage multimodal 3 is capable of vectorizing interleaved text and images. They can also capture key visual features from screenshots of PDFs, slides, tables, figures, you name it. And this eliminates the need for complex document in parsing while still maintaining retrieval accuracy. Innovation is the name of the game when it comes to AI, and embedding models, quite frankly, are no different. We recently released voyage-context-3, a breakthrough in precise chunk retrieval with global document context. This contextualized chunk model is the very first of its kind. Our model process is the entire document in a single pass and generates a distinct embedding for each chunk, delivering superior retrievable performance. . On the reranker side, our recent reranked 2.5 release sets an industry standard for reranking with instruction following capabilities. Voyage models are designed for high accuracy and quality. And when you start using them, I think you'll find that we've done a lot of work to make them as developer friendly as possible. And even though great embedding models and rerankers are critical for building grounded, reliable AI applications, you still need other components to bring AI to life. With other database providers, this is an extremely complex process. You had to have your source of data, a database for structured data and a vector database. You also have to feed that data into your embedding model and then be sure to update both data stores. Then you had to have your results reranked outside of the database. Now all this made for a very, very complex and multi-vendor environment. Now you can do everything with MongoDB. This native integrated experience reduces friction for you and accelerates your AI application development journey. Search and vector search have been in Atlas for a while, but we understand that a lot of development starts locally. And as such, I'm pleased to announce that search and vector search are now available for community server and enterprise server. With these 2 releases, we're opening up our text and vector search capabilities for development, testing and production in your own environments in addition to Atlas. . Now I'd love to show you all of this in action. Please welcome Apoorva Joshi to the stage to help me do that. All right. Apoorva, I heard you are a big fan of the movie, The Devil Wears Prada, is that right?

Guilty as charged, guilty as charged. I watched it way too many times for me to even admit. But I just can't get enough of Meryl Streep and her iconic stairs, like when she glares at Anne Hathaway at 32 minutes or oh, my favorite, cerulean sweater scene, you know what I'm talking about at 54 minutes, 11 seconds or...

Hold up. That's actually [indiscernible] you know the actual time stance. I mean you really have seen this movie a lot.

Well, I have to admit, I did have a little bit or a lot of help, right? All I really wanted was to find my favorite themes from all of my favorite movies. So I built an app for it, and AI app for it. It's why you do these days, right?

Of course, you did. Of course, you did. .

You want to see.

I would absolutely love to.

Let's do it.

But before you begin, I'm thinking maybe we shouldn't use The Devil Wears Prada since this is being live streamed and I really don't think we want MongoDB to get sued.

That's a good thing. That's a good point. Okay. So why don't I use the next best thing? Are you ready for it? Previous MongoDB.local keynotes. Are you really telling me you don't watch them all the time? What's better than curling up on your couch on a Friday night, watching Dev, our CEO talk about the greatest database of all time.

Look, you don't have to tell me twice. I do it every week, every weekend. So...

See -- so okay, jokes aside, there's this term that Dev always uses something like critical movement. So how about we see -- if he talks about that in last year's keynote. So here's my app. I already uploaded last year's keynote through it. So I'm just going to go ahead and select that and I can start searching for my favorite moments. In this case, we want to look for critical moment. It's crucible moment, my bad. But while we're here, how about we look at what that means in Dev's own terms, right? So I'm going to click on that top search result here. It has the time stamp for me to skip too. So let's see what Dev has to say about Crucible Moments.

The most well-known venture capital firms in the world, and it's also one of our earliest and largest investors in the company as a term they called a Crucible Moment. And they define a crucible moment as an inflection point where a choice you make today has an outsized bearing on the years and decades to come.

[indiscernible] in case this ends up being a crucible moment in my life.

Look, crucible moment aside, this demo is super impressive. Can you tell us a little bit more about how you built it? .

Sure. Yes. So the app contains a lot of the components that you were just talking about, right? I upload a video to it, and it first extracts frames from it, then it uses Voyage AI's latest multimodal embedding model to embed trim to capture what's happening within it. But can you believe that it took me, it costs me less than $1 to embed a whole 70-minute long video.

That is a great price point for a best-in-class embedding model.

Right? I think so, too. And these embeddings are what make these frames searchable without using the exact keywords in the frame descriptions. And as you can see, I'm even able to match a text query to text within a frame image, which is something typical multimodal embedding models often struggle with. I've then implemented hybrid search using MongoDB's latest rank fusion aggregation stage, which allows me to combine vector search on the frame embeddings and full-text search on the frame descriptions. So this really gives me the best of both worlds, which is semantic understanding from the embeddings and precise keyword matching from the full-text search. And this really helped me improve the search quality within this application that I built.

This is awesome, Apoorva. The demo itself looks really smooth, but I also imagine there's a lot of other things that are happening behind the scenes. Now could you tell us a little bit more about what makes this search so responsive?

Yes, 100%. So speed is the name of the game, right? And there's many MongoDB features that you can use to optimize the applications for not just real-time performance, but also massive scale. And one of my favorite features, something I use all the time is this feature called quantization, which essentially shrinks full precision float32 vectors into smaller, lower precision vectors consisting of int8 and binary values. So what does this mean? Where your vectors were initially taking 32 bits to store each dimension, can now only take 8 or even just one. And the coolest thing is you can retain most of the retrieval performance despite this compression. So you get a really good trade-off between accuracy and latency.

I absolutely love it. And to add a little bit more color to that, voyage-context-3, voyage-3-large and the voyage-3.5 series are all trained for what is called quantization awareness. So if you use it in conjunction with the quantization that Apoorva was just talking about, you'll be able to retain a lot of the accuracy when it comes to search and retrieval.

Awesome.

Thank you so much, Apoorva. One last thing, where can we get the code for this demo?

So there's a QR code right there, that should take you to our Gen AI showcase GitHub repo that has this app that I was just showing you and many others for you to check out after today.

Awesome. I love it.

Well, thank you, Frank, and I'm going to now go rewatch The Devil Wears Prada. Thanks, everyone.

Thank you, Apoorva. Now I know we've covered a lot, and many of you are ready to learn more. One area where I barely scratch the surface of is agents and agent memory. This is an incredibly exciting topic for me personally. Search and retrieval are essential components for agentic applications. And they are often the critical elements that take agents from prototype to production. Join us later today to learn more about using MongoDB for AI agent memory in this session. And also, Apoorva is hosting a hands-on workshop at 1:30 today. This workshop gives you the opportunity to earn one of the coveted MongoDB skill badges that Dev talked about at the start of the keynote. Skill badges are digital credentials that allow you to quickly learn and validate specific MongoDB skills. I've got this QR code to access opportunities online with MongoDB University. Attend one of today's workshops or if you only have 10 minutes to spare, look out for the flash badge sessions at the University booth or at the Skill Hub on the fourth floor during breaks. I hope at least one thing is clear by now. If you build on MongoDB, you'll have everything you need to bring AI to life in your applications. But what if you aren't just building new software? What if you have a long tail of existing applications? The obvious solution to this problem is to modernize off of those legacy estates. But how to do that has been a real challenge. So here to tell you more about our new groundbreaking approach to modernization, please welcome Shilpa Kolhar to the stage.

I'm not sure I would call modernization fun. However, I'm sure everyone here would agree with that. But I do love a challenge. And what I love more is how MongoDB is solving for this one. So let's kick this off with a question or maybe a few. How many legacy applications that you are running you think that they're working fine, but still keep you awake at night? Do you carry a lucky rabbit's foot?? Or do you throw a penny in a wishing well, every chance that you get? I have done that. And I can tell you there is a better way. We all know many of you are surrounded by a large estate of legacy applications, which we built decades ago, and they still run critical parts of your business. These applications stick around because even making the simplest of change is extremely risky. How many of you have heard this phrase, "don't touch it, it's mission-critical." These apps are draining budgets, risk and compliance failures, security breaches and ultimately slowing you down, slowing innovation. And very often, the developers who built these apps have moved on a long, long time ago. So you are now left with maintaining these applications, which can be challenging because of large estate of stored procedures. It's a ball of spaghetti, which is hardly documented and very convoluted to understand, okay? And then you have these outdated frameworks and run times, which are brittle and hard to upgrade, core that you might not understand that depends on technologies, which are outdated and you don't have time to learn it. There are no functional tests or unit test to guide even the simplest of changes. And then a gap in vendor support or security patches once the framework has reached end of life. The cost just to keep the lights on, on these applications can be enormous. But making the decision to rewrite, to rearchitect and modernize these applications can be overwhelming. And it's why so many companies postponed their modernization projects year after year. But I have a good news. MongoDB has worked on many such modernization projects. And through years of experience, we have prioritized and come up with a perfect platform that is structured around proven and repeatable framework so that modernization can be easier and faster. Introducing MongoDBs application modernization platform or AMP for short. AMP helps companies rapidly transform their legacy applications into modern scalable services on MongoDB. By combining AMP tooling with MongoDB's proven repeatable framework, customers have seen some of the tasks like code transformations speed up by 10x and overall modernization efforts by 2 to 3x faster. These modernized apps will land on MongoDB. So you are better prepared and positioned for the future. AMP includes primarily 3 things. We call them the 3 Ts, tools, techniques and talent. We have developed a set of AI powered and deterministic tools to perform specific modernization tasks from creating functional tests to transforming code to migrating data and so on. And these tools are paired with techniques and methodologies that we have created to address various modernization challenges. And then these are all put into action by our team of modernization experts. These are all designed to completely transform your applications from the data tier to the application tier so that you are in MongoDB and in the future, you can focus on building new capabilities and business differentiators and you are ready to embrace AI. You know what? Customers are already seeing the results. Lombard Odier, a 200-year-old Swiss bank successfully migrated key applications from its SQL database to MongoDB. This resulted in migrating code up to 60x faster and reducing the regression testing time from 3 days to just 3 hours. Intellect AI, one of the world's largest fintech platforms, it was faced with significant performance and scalability challenges on their existing stack, which was based on a monolithic architecture and with relational database. By working with MongoDB, Intellect reduced their onboarding workflow times by 85%. Their clients can access their portfolio and get insights much faster now. Also, the development life cycles were sped up by as much as 200%. And Australia's Bendigo Bank. They reduced the development time required to migrate one of their core banking applications from a legacy relational database to MongoDB Atlas by 90%. And with AI tooling, the bank was able to reduce time spent running their application test cases from over 80 hours to just under 5 minutes. These customers are all from a highly regulated industry. And if we can modernize with them, we can modernize for everyone. What we provide with AMP that has helped these customers and many others covers the entire life cycle of modernization. As you would expect, code conversion is a critical aspect. Now let me be clear. AMP is not about taking the legacy code base and throwing it into an LLM. Spoiler alert, that doesn't work. Trust me, we have tried it. Real applications have large and complex code bases that AI cannot handle effectively. And this is especially true for those applications centered around stored procedures. So our tooling enables us to break down this problem into smaller pieces and then work through the code base through an interactive iterative automated process. Even if you perform the conversion, a critical input is functional tests to prove that your converted application is functionally equivalent to your previous original application. And what we have built is tooling that assists both with static and dynamic analysis of your application to identify those areas of concerns in your code or figuring out all the complexities involved in this entire modernization project. Obviously, you don't want to get into any modernization effort without fully understanding your application code and the code base. For this, we have tooling that can perform static and dynamic analysis. And certainly, last but not the least, we want to get your converted application onto production. For this, we have tooling and methodologies to help you derisk that last mile of getting your application into production. So you can see we have covered you across all these areas with AMP. We have the tools that leverage AI, where needed. We have the methodologies to address and approach those modernization challenges. And we have our team of experts who will work with you to bring this all together. This is all designed to help you produce a modern and performant application running on MongoDB so that you can have no sleepless nights. I don't know, I can't say that thing, fewer sleepless nights and worrying about your legacy applications, like we don't want you to worry about it, and spend more productive hours developing the capabilities that your business needs. I hope that gives you an idea of what we can do to help with modernization. And there is so much more to show. For that, we have a full session today right after this keynote, where you can see AMP in action. We are very excited about how we can help you with your application modernization on MongoDB. From the release of MongoDB 8.2 to our breakthrough industry-leading AI capabilities, to MongoDB AMP, MongoDB is removing friction. So you can move faster, innovate more boldly and adapt with confidence. And while today has been about what we have delivered and what you can build right now, we know the pace of change isn't slowing down. So now let's explore our vision of that future. Please welcome my boss, CEO, Dev Ittycheria, back to the stage, that he will be in conversation with Voyage AI Founder, Tengyu Ma and CNBC's Jon Fortt. Thank you.

All right. Nice gathering you've got here, guys. Thanks for having me. I sort of want to set the stage for the future here, Dev. So tell me your business perspective on Agentic AI right now. In your career, you've seen a lot of these transitions PC to web, web to mobile and cloud. And there were certain, I think, practices attributes that allowed some businesses to effectively zoom ahead, some developers to effectively zoom ahead. What were those? And how do those apply here?

Sure. So I'm going to use the analogy with the SaaS or the cloud world. If you all remember, most people thought that when SaaS and cloud became very popular, every application was essentially a CRUD function on a database. But then people realize it didn't makes sense to recreate their own CRM or their own HRIS systems so that every customer end up implementing some version of Salesforce or some version of Workday or some of their equivalents. But that was really a competitive advantage that would have just made their business run more efficiently because your competitors could use Salesforce or Workday. What really provide a competitive advantage is the deep customization of software in terms of how companies engage with their customers, how they build new products, how they pursue new opportunities or respond to new threats or found other ways to drive the competitive advantage. And I think we're going to see the same thing with AI. And I think the way agentic use cases will come about is that people start building very custom agenetic use cases that truly transform the business in terms of seizing new opportunities, building new products, offering a very differentiated customer experience. And ultimately, that will show up in how they compete in their markets.

And allowing them, I guess, to really take advantage of AI capabilities in those advance. Now Tengyu, 10 years ago, I believe you were a grad student at Princeton and an intern at Google, congratulations on that retroactively, by the way. But now you made good use of the last 10 years. But back then, when you were a grad student studying neural networks, machine learning, is this how you thought the next 10 years would turn out?

I think we do expect some part of it, but I think I didn't really expect large language model wave 10 years ago. We saw the growth of deep learning starting from 2013, and there was a wave for AI like -- with like a vision models. And -- but large language model was really amazing. And -- yes.

So you didn't see the large language model kind of inflection point happening. It was like wait a long time and then all of a sudden...

Yes, I think so.

What's the lesson in that for technologists, for developers who are maybe have expectations about how much time they have to adapt to the technology that we're seeing on the scene to really take full advantage maybe of what MongoDB is putting out there today?

So I think the -- in some sense, I think the AI kind of like technology is changing the workforce, they're changing the way that we worked every day. So I think Anthropic has a blog post about this. At MongoDB, we also have seen this. The AI developers are using the tools they developed to build better tools, faster and more efficiently. So we are using code assistance. We are using our own models to help us to write new code to train the models, next generation of the models. So in some sense, there's a double acceleration here. And so we are faster and faster in developing new models.

So Dev, along those lines too, and the ways that you need to effectively lead a team today, whether you're at the CEO level or like most other people in the room at a more micro level, how is this agentic moment, changing the way you effectively build something, a human communication piece and then even the degree of understanding you need to have of your organization's mission, your customers' needs?

Yes, I have a pretty optimistic view of AI and Agentic use cases going forward and Agentic tooling. I don't believe that suddenly all these jobs are going to disappear. In fact, when I look at like our scale of our ambition, there's so much more we want to accomplish. It's not like you can say, because we have AI tooling, all of a sudden, we need less developers or less staff. We want to get more leverage out of them so we can actually do more things and do more things more quickly. And we're still investing in R&D. We're still investing in building more capacity in our organization. And I think we view that tooling will enable us to move that much faster and get more output from the resources we have. And like most other organizations, I would have to -- I think all -- every development organization probably has a backlog of things they want to do, but they just don't have the resources to do it. And I think now with AI tooling, you're going to see the scale of ambition just increase dramatically of what people want to accomplish. And I'm super excited about that -- what that says for us.

So about a year ago, I guess, maybe a little less you at MongoDB, bought Tengyu's company, Voyage. Tell me why and how some of those technologies that you picked up that his team is working on are really embedded into what folks are going to be learning about today?

Sure. So when we rolled out our back to the store, and we were really proud that we could offer companies ability to do this very -- and you heard it a little earlier about hybrid search, the Rank Fusion command that you can do very sophisticated searches. But customers, when they heard the story, say, yes, but I still have one problem. I still need to go embed my data because you can't use a vector store without embedding your data. And so we said, okay, that's a fair point. So we're creating like an extra step in the process. It wasn't a seamless developer experience. And so we said, okay, let's go try organically building our own embedding models because we realized that, that would take a long time, and we didn't necessarily have the expertise. And fortunately, through some venture connections that I had, we got connected to Tengyu and his team, and we were dazzled by what Tengyu and his team were doing. And I think at the same time, they were also thinking about maybe they should be part of a large organization. So we got -- had multiple conversations and discussions and realized it makes sense to do that. And what's really impressive is the Voyage models are really well -- I mean, Tengyu may not say this himself, but they're super well respected. The team -- Tengyu and his team are a bunch of rock stars, and they're really respected in the AI community and the Voyage models are ranked very high, so much so that Anthropic recommends Voyage models to all their customers. So we got really excited and that's why we ultimately decided to make voyage part of the MongoDB family.

Tengyu, why were you building that?

So because we believe that we have amazing kind of progress in the last few years for the AIs capabilities. But sometimes people forget or miss that these AI models off-the-shelf cannot access proprietary information the company or individual has. So these models are like smart brains, but you always have to connect them to the proprietary information so that they can have the context and backgrounds to make reliable accurate decisions or responses.

Otherwise, we're just kind of guessing, right? You got to read stuff or talk to people in order to -- no matter how intelligent you are really get practically smarter.

Exactly. For example, even you have a smart guy like Einstein joining MongoDB on the first day, that person needs to read MongoDB's documentation, internal documents to contribute to MongoDB. And embedding models is this tool that MongoDB built to make these kind of connections and ingesting massive data into large language model possible. In some sense, it's kind of like librarian, which help you find the most relevant book or book chapters in our library. So -- and in some time, this librarian is also beyond the traditional librarian who is using the call numbers, right? The call number is just 9 digits. But here, the embedded model actually generates thousands of numerical floating precision numbers to represent not only the book title, the books -- the year, the authors, but also every little details in that book up to the chapter, sentences or even annuities in the book. So that when you use this longer version of the call numbers, we call embeddings or vectors to search the relevant chapters, you can be much more accurate and much more efficient.

If I can just add. I think the thing that I think a lot of people don't appreciate is that the frontier models have scrapped all the public data. So they have basically indexed and scraped all that data. The real secret sauce for any company is their private information. So what the embedding models are truly a bridge between a company's private data and the LLM, and no company is just going to hand the private data to a frontier model. So the best way to essentially figure out how to leverage their private data is through the embedding model. So I think what the industry is starting to realize and value is that the quality of the embedding models and the reranking models are super important to build a reason and make good decisions about your own data, which is, frankly, what most customers have to do on a day-to-day basis. So that's why this element that was kind of viewed not as strategic or sexy a couple of years ago is now viewed as a super important to build, again, reliable and trustworthy AI applications.

Tengyu, game plan time for the folks here in the room. If you were getting ready to go out into these breakout sessions, interact with peers, whatever, how do you make the best use of your time today.

I would encourage people to understand and kind of get more familiar with our products. I think -- we -- I think one of the reasons, for example, that I believe that the vision and joined MongoDB is that we believe in the document model, which is what AI is all about because AI's data are unstructured, semi-structured. And sometimes it's fundamental because our brains don't store knowledge in rows and columns, but we store knowledge in some kind of unstructured, semi-structured way. And I do believe that MongoDB is uniquely suited for the new generation of the AI applications. There will be a massive replacement of the old traditional softwares by AI native softwares and all of them requires a database. And MongoDB can be the data base that is intelligent because you can search through the database with the embedding models, the rerankers and get most relevant information.

Well, let's let them get to it. Dev, Tengyu. Thanks for having me here, helping you kick it off.

You're our Rockstar from CNBC. So thank you for being here.

Well, I got to get to work.

Exactly. How the market is doing. So this concludes the keynote section of the day. We're going to take roughly a 15-minute break. The breakout sessions will start at 10:45. So refill your coffee cups, do whatever you need to. And the next session will start at 10:45. Thank you very much. [Break]

Good morning. Sorry to stop the music. I know everybody loves that great 80s song. Good morning to everybody. My name is Mike Berry, I'm the CFO at MongoDB, and I'm proud and honored to be the MC for today's event. So we're super excited about what we've put together for you. As you know, hey, folks, this is for you. This is our annual event where we will walk you through not only where we've gone, but most importantly, where we're going to go. So you're going to get a great event today. I'm going to go through a little bit of the logistical piece of it, and then I'll walk you through who's going to talk and what you're going to hear today. It's going to be a nice long event. So if you have to get up and take a break, go ahead, we'll put a break in there, but we have a lot on the calendar for you today. So a couple of housekeeping first. As I said, hey, folks plan on this probably going to 3:00. So that's about a 4-hour event. About 12:15 or so, we'll take a 15-minute break, have lunch boxes for you. So we will keep you nourished during that time. We will have a Q&A session at the end. So I would ask you to hold your questions until then. We don't want to interrupt the flow of the presentations. We will try to leave as much time as we can to take questions at the end. As you all know, this is a big event. It's -- and for us as well, I could thank a ton of people. There's 5,600 wonderful employees at MongoDB. There's a bunch of people that have spent a lot of time on this. And if you haven't met him yet, he's new here, Jess, would you please stand up our new Head of IR. There's Jess Lubert. There's 2 people and just started a couple of weeks ago, as I like to tell them, hey, but there is no shallow into the pool at Mongo, you're going to dive right in. Earnings Investor Day, but there's 2 people that really got us to where we are today. And they're not their numbers, they're mine, so you don't blame them. But [ Bridget and Austin ], would you please stand up? So [ Bridget and Austin ] on the finance team, hey, folks, they've done a ton of work. We're only here in front of you because they have herded the cats for 4 months. So [ Bridget and Austin ], thank you very much. The other big thank you, and they're not here yet and some of them may be in here, you're going to hear from some of our wonderful customers today. We are only here on MongoDB because of the support of our customers. You'll hear a lot from us, but we think it's much more valuable for you to hear from them, why they use us, why they trust us in their important infrastructure. So we're going to have a couple of customer panels. You'll also see a couple of testimonial videos as well because everybody couldn't make it in person. And I want to thank those customers as well. They're taking time out of their busy day running their own businesses to come talk to you about why they use Mongo. So we greatly appreciate obviously, not only the support of our customers, but the time they're giving as well. Okay. So this is important, and I do have to read this. So this is an investor event, and it's certainly covered by our safe harbor. So before we dive in, a couple of legal disclaimers. Our remarks today will include forward-looking statements, including statements related to our ability to capitalize on our market opportunity, financial goals, strategy and potential benefits of our products. These statements reflect our views as of today and are subject to a variety of risks that could cause actual results to differ materially from expectations. For a discussion of risks, please refer to our Form 10-Q for the quarter ended July 31, 2025, and other filings that we may make with the SEC. We will also discuss non-GAAP financial measures, which are reconciled to their most directly comparable GAAP financial measures in the appendix in the presentation, which will be available on the Investor Relations section of our website. Also, and there's a bunch of people joining, obviously, virtually, we will post a presentation on our IR website when we're done. You're going to see new metrics today, so you don't have to take out your camera and take a picture. We will provide you with those and we'll post them later. Okay. Here's the lineup for today. One of the great things about this, at least I think it's great versus last year, hey, there's 4 or 5 new people. There's only 1 that stayed here, which is obviously our CEO, Dev. So I will kick it off. I will hand it to Dev. You're going to hear from Jim Scharf, who is our CTO. You'll hear from Fred Roma, who runs our Atlas Data Services Business. You'll hear from May Petry, who's our Chief Marketing Officer, and then I'll come back and do the financial update. So here's the agenda for today. I will kick it off. I'll hand it to Dev. He's going to talk about key drivers for durable, profitable growth. You will hear a couple of things, probably 1,000 times today, durable, profitable growth. So when you leave here today at 3:01, there's a couple of things we want you to remember. That's 1 of them. Then we're going to have Jim come up and talk about our competitive positioning, mostly related to our core products. He'll also give you some view of AMP, which we introduced today as well. Then we'll have a customer panel, look at those names, Adobe and McKesson, great customers. They're going to talk about MongoDB versus your favorite subject, which is how do we compete against relational. Then we'll take a break, bring in lunch. Then Fred will come up and talk about our AI product strategy. And then we'll have another customer panel talking about us in the AI era, and you see those folks here, Cisco, DevRev and TinyFish. Then we're going to have May talk to you about and we talk about this a lot, our product-led growth in our self-serve model. It's a huge part of our go-to-market motion. So May is going to give you an overview of that. I will then come up and put everything together, how does this relate to our financial update. And yes, we will talk about long-term targets. So you're going to have to wait 2 hours and 30 minutes. Hopefully, it's worth the wait. And then we'll open it up for Q&A. All your presenters will come up and talk to you, okay? So those are all the housekeeping items. Again, folks, we'll post on the website and you'll have access to those charts. So without further ado, let's kick it off. I would like to introduce our CEO, Dev Ittycheria. Dev, take it away.

Thank you. Nice to be here. Thanks for making time today. We will focus on durable, profitable growth. Okay. Good. The first thing, I think what you should take away hopefully from today is a few points that we're going to really reinforce throughout the next 4 hours. One, we have a massive market we're going after. And that market is growing. Two, the AI transformation or platform shift or whatever you want to call it, we believe, significantly expands our market. Three, this is not a winner-take-all market. Our competitors don't need to die for us to win. And four, you've heard this new thing called AMP that we announced yesterday. If you saw the keynote, we talked a little bit about AMP and the keynote is basically our way of making it easier for customers to migrate off those thorny legacy applications onto MongoDB. So consequently, we believe that we have multiple tailwinds that will drive long-term durable growth. So just a couple of things on the market. These are all IDC numbers and the market today is estimated to be a little over $100 billion. And as you know, we only own 2% of that market. So even if you became a -- had 5% share, we would be a $5 billion revenue company. And what's really interesting is that there's not many markets that are this big that are growing this fast. IDC estimates that this market is growing by roughly 13% year-over-year for the next few years. So that speaks volumes about the fact that our market is large and it's still growing. So the second question is like why is AI a tailwind to our business. One, I would argue that AI is expanding the software universe. If you go back through every platform shift from PC to Internet to cloud and mobile and now to AI, the cost of building applications has come down. Consequently what happened? There was an explosion of applications that people use to express their business strategy and really run their business, either to seize new opportunities, respond to threats or drive more operational efficiency. The second thing that's also clear, the point there being is that AI will be no different. And we believe that the number of use cases that you will see with AI will be very, very different because in some way, you'll be using the reasoning capability of AI to address use cases you never could do before with deterministic software. The second point is that real-time data becomes far more critical. Data is critical for AI, how it's stored, retrieved and even kept fresh. And the OLTP layer or database is where memory and state are handled. And we believe that the OLTP is a strategic high ground for inference. Third, AI speaks JSON. Hopefully, you have seen enough evidence to recognize that JSON is the lingua franca for AI. All the LLMs are trained on JSON-based tokens, MCP the protocol that everyone uses to connect LLMs to other data sources is built on JSON, other adjacent technologies emit and consume JSON, it's all about JSON. We are a native JSON database, so the ability to seamlessly input or extract data from MongoDB is a core advantage for us. And last but not least, you need to do sophisticated search and retrieval. Now in the traditional way, you do search retrieval through like keyword matching, metadata filters, et cetera, and you would basically find information. But with AI, you need to do searches that really understand the meaning or intent of the information that's being produced. What MongoDB allows you to do is basically do those -- both those things effectively in one pass. And that becomes really, really important as you're doing things like RAG, as you're doing things like recommendations and obviously, as you want to deploy Agentic use cases. Now before we get into AI, I just want to give people a little bit of color of how we got here and just walk you through the phases of the company and how it transitioned. In the first phase, this is -- the founder started the company in 2007, they were the -- essentially, I talked about this in the keynote, but the founders were the founders of the company called DoubleClick. And DoubleClick was the first -- one of the first web scale apps that people saw. They used to serve billions of ads per day. And so consequently, they have to deal with the massive data challenges at that time. And this is like -- over 20 years ago. And they realized they were investing so much time working around the constraints of the relational database that at some point, they said, this is crazy. It just takes too much time, effort and money to do that. And so why don't we built something that we would want to do and that was the -- basically the genesis of the document model. So their goal in the early days was one, to obviously build product, nail product market fit and win some lighthouse accounts. I took over as CEO 11 years ago, and the Board had really chartered me at that time saying, can we build a durable business. There were a lot of questions about open source companies. And it was at that time, there weren't many open source companies that achieved meaningful scale. And so open source is great for generating value, but wasn't great for capturing value. And when I look at the business, I felt the best way for us to capture value was building a cloud service. So we launched Atlas in 2016. We took the company public in 2017. Atlas was 2% of revenue at the time. Today, it's 74% of revenue. So I think we've done a good job of capturing value, leveraging our technology. And the other thing we did was focus on both go-to-market excellence, really building a highly competitive, aggressive sales organization that could go out and compete and win against all the other players in the marketplace, and also build an enduring culture where great people want to come and stay and grow their careers. So then the question is, what's next? We're now entering what we call MongoDB 3.0, not confused with the product, the phase of the company. And we believe there's an opportunity to not to double or even triple this business, given this new big platform shift with AI. So the key challenges we recognize clearly in front of us is we want to overcome the bias for relational. There's clearly still -- relational has been around for over 50 years. And in many organizations, there's a predisposition to just stay with relational. We recognized to grow to $4 billion, $5 billion, $6 billion in size, we need to start winning strategic and bigger deals because you just can't win those workload by workload. And we also want to take a solutions orientation. What we've heard from customers is, yes, you're giving me nice tools, but I also want end solutions that I can kind of just go with that address the problems or the challenges they have in my business. And so that's kind of the priorities that we have in this next phase and obviously have the leadership team and the talent that can scale this business to that scale of growth. But through all these things, something stays very, very constant. Our underlying technology is the document model built on JSON. And all of you are very seasoned and savvy software investors and analysts, and you know that it's very hard to rearchitect a software product once you set the foundation. And we are fortunate that we have set a foundation that not only is good for today's world, but is also outstanding for tomorrow's world. And we believe the document model is even more relevant today and tomorrow than it was yesterday. And I think that's something that's starting to play out in the industry. And so the question is why? And first is that the document model or JSON is really the best way to model the messiness, the complicated, interdependent and highly evolving nature of data that we deal with today. And the second thing we can do is we can then unify all types of data, metadata, which is really data about data, embeddings which is really representations of the semantic meaning of information and real-time operational data that you're generating in your business to understand what's happening, what am I selling? What am I buying? What's happening with my customers, what's happening in my supply chain? All of that can be embedded and unified in the document model and JSON is the basis to do that. LLMs, as I said, MCP and other adjacent technologies are all emitting and consuming JSON. So JSON is well set up for that. Third is one of the things as you think the rate of change is only going to increase with the world of AI, and I definitely believe that, then you need a platform that can evolve and move quickly as your business changes. Again, responding to new opportunities, addressing new threats, building new capabilities, running your business in a different way, you need a platform that's highly agile and there's no better platform than MongoDB. And as I mentioned before, JSON is the basis by which all this happens. The other key thing is none of this is true about relational. The only advantage relational has is basically it's incumbency. Relational is not flexible. Relational is not easy to change. Relational doesn't easily support different data types. Lot of relational databases claimed to support JSON, but those claims or those I'd call retrofits, are really adjunct and kind of not very elegant. So for example, in Postgres, if you add JSONB support, any document over 2 kilobytes in size has to do something called off-road storage. Off-road storage really adds to performance overhead to Postgres. So there's limits to what these platforms could do because they were not architected from day 1 to be a native JSON database. So then when you think about, okay, what is the ideal database for AI look like? And how do you encourage you to ask ChatGPT this question, the answers are going to look very similar to this. One, you need a way to easily model the real world. JSON obviously does that. Two, you need to have a very effective and sophisticated way of retrieving and finding information quickly. And not only do we offer a semantic engine and lexical search engine, but we also offer world-class embedding and reranking models. And third, you also want to be trusted that you're going to essentially perform as expected, that you're secure, that you're available and your performing even in the most demanding use cases. And we're battle-tested. Some of you may have heard that some of these newfangled companies are having trouble scaling. We've been battle tested with over -- nearly 60,000 customers who understand this problem really, really well. So we are starting to see some traction from AI in our numbers. These are some examples of customers who are in our AI journey, and you'll hear from some customers later today. And the other stat I'll share with you is that 30% of our ARR are from customers who have at least one AI use case. That tells you that it's not just a few customers, but many, many of our customers are starting to use MongoDB for AI use cases. The other thing is that our market, while very, very large, we think there's an opportunity to address a big part of the market, which is the legacy relational market. When I took MongoDB public 7 years ago, we had called out in our S-1 that 30% of our new business was relational migrations from relational to MongoDB. And obviously, we grew that business very, very quickly over the last 7 years, but I was frustrated that, that part of the business did not grow as fast. And one of the reasons was that it was -- it's hard to do that. So then the question is why now? Why is this market suddenly opening up? Well, one, from a customer point of view, the technical debt, the tax or cost, the risk is just becoming untenable for these customers. Moreover, a lot of these customers want to use that proprietary data and be able to AI enable it, but it's very hard to apply metadata to all that data sitting in these old legacy platforms. Second, the biggest challenge in the migration process was rewriting the application code. Well, guess what, with AI, you can significantly reduce that time, not just by throwing that code to an LLM, but leveraging the LLM and building an ontology around the LLM or AI technology that enables us to chunk up that code, auto-generate test, refactor that code and run those same tests to make sure that the new code works as a functional equivalent to the old code. And then no, that's essentially what we did with AMP. And we recognize that AMP is just -- you're not just going to have an easy button, magically, the code is going to be migrated because these are very, very old, very, very complex systems. There's tons of variability in terms of versions of the tech stack they're using, the way each organization does codes their own -- writes code, et cetera. So there will always be some combination of product or tooling and services over time, that ratio will increase more on product or tooling. But that we recognize that, that our delivery model is going to be very differentiated. And then obviously, we're hiring very specialized people who know how to do this for a living. So then the question is why do we win? We believe that we win because one, again, architecturally, we're well set up to really migrate these to a much more modern architecture. Two, we're not an SI. We're not looking to -- one of the concerns customers have is, are you just a wolf in sheep's clothing because you're just going to come in and spend 3 years, you're migrating my apps. Our goal, we view this as a means to an end. The pot of gold at the end of the rainbow is getting those relational applications to MongoDB. And that's what we're motivated by and customers actually resonate with that. And three, we believe when we walk people through this, our architecture saying, not only are you migrating off legacy, but you're also well positioned for AI. Because what people don't want to do is lift and shift and then start incurring technical debt, the day that, that migration is over. So you're going to hear a lot of details on AMP and what we're doing here from Jim in his talk. So one of the other questions I get from many of you is competition. Obviously, this is a big market, and it's attracted all types of competitors. And that's really happened since the first day I joined the company. And when we first joined, the question was, hey, there's a bunch of NoSQL players, why do you win? These key value stores, there's graph databases, there's XML databases. There's in-memory databases, why do you guys win? I think, well, we prove that we're a very versatile and flexible platform that addresses a broad set of use cases, which is why I would argue that we are the "NoSQL" winner even though I hate that term. The second point is when we launched Atlas, I remember the IPO, a lot of investors saying, how do you expect to partner and compete with the hyperscalers. No one had really done that. No company of our scale has ever done that. And I think we proved that customers do care about best-of-breed solutions. Customers do care about not being locked into any one cloud. And customers do care about obviously ROI. And so we've been able to grow that business. You could argue, competing against some of the largest companies in the world. And then the third question that we're seeing now that we're hearing from a lot of you is, hey, isn't Postgres kind of the standard? And I would argue the reason Postgres is becoming more popular is not because of MongoDB is because there's a consolidation happening in the relational market. People want to get off Oracle, want to get off MySQL, want to get off SQL Server and Postgres is the easy answer. And obviously, the onus is on us to prove that we can compete, but we feel that given our track record that we've been able to prove all the doubters previously. So our differentiation against relational, I would argue, is real and durable. And so let's talk about why. So one, and if you saw the keynote, I'm just going to double-click on these points. Relational databases are essentially -- think of them as Excel spreadsheets on steroids. So they're basically designed for a world of uniformity and predictability. So the world has changed a lot over the last 50 years. Two, they're very brittle. Ask anyone how easy it is to make a schema change on relational database and some of their eyes will roll in the back of their head because it is a very, very difficult thing to do. And in a world that's constantly changing, that becomes super problematic. And third, Postgres and these relational databases were designed to be single node systems. Now what's interesting, and Jim will talk -- go into this, is there are a lot of customizations to make it essentially suck less at scaling, but then you're locked into their platform and you don't get the benefits of a true open platform. And then -- what I would say is the mistake a lot of people make is comparing us against, say, Postgres when the real comparison is us versus Postgres plus Elastic plus Pinecone plus something like Cohere. And as customers really start understanding this is a much more elegant developer experience. It's one API. All the data is stored in one place. I don't have to go and stitch together all these different piece parts. So the cost, complexity and agility of the platform is so far superior to everything else out there. So we talked to you about how we're expanding from being just a pure OLTP engine and offering other things. And that platform story is resonating. One, this is some new stats we're going to share. 70% of ARR is from coming from -- of Atlas ARR has come from customers who are using at least one additional capability beyond the OLTP engine. Two, there's 40% of those customers are direct customers. So these are large, meaningful customers. And three, what's also interesting is that the customers who use more than one capability are actually 5x larger than those who don't. So what we're seeing is that as people start really embracing our platform story, they start growing much, much more quickly. So that's, I think, just a few data points to give you a sense of the fact that the ability to marry an OLTP engine with a lexical or keyword search engine with a vector store and embedding and reranking models is starting to resonate in the marketplace. And I would argue we're still in the very, very early days. So we recognize that people either don't understand that or there's still some work we have to do. So we're working both to strengthen and communicate our differentiation. There's a lot of work, and you can hear from May, later today on how we're doing that with our community. We're doubling down and really making sure all the misunderstandings or misnomers about MongoDB are addressed, and we're finding that when people really get to understand the MongoDB story, it becomes a compelling story. Two, you'll hear a lot about it from Jim and Fred about what we're doing on the product side and how we're pushing the envelope in performance and scale as well as all the new features we're building. And three -- sorry, I can't go back. Thank you. Three, that we're continuing to focus on driving more impact through our go-to-market efforts. We've talked a lot about how we moved upmarket in the last year. We're also talking about how we're using our self-serve business to better serve our PLG business, to better serve the small and medium-sized customers. May is going to talk about that in a lot more detail. So why do we win? Again, the market is large and growing. AI significantly expands our market. AMP is an incremental growth opportunity that we're very excited about, and this is not a winner-take-all market. Our competitors don't have to die for us to win. So with that, I will reinforce Mike's point that we're very, very confident about our ability to drive profitable, durable growth. And now I'm going to hand the dice to Jim Scharf, our CTO. Thank you.

Okay. So thanks for being here today. I'm going to talk a bit about our competitive positioning versus relational. And I'm going to really try to walk you through some of the top areas that customers tell us why they select MongoDB versus other database technologies. And so first, I want to talk a little bit about our foundation because everything really builds upon that. As Dev mentioned, the foundation of our database and really our company is really the document model. And MongoDB is really the only database built from the foundation up to support documents. And then having that at our foundation enables us to scale our database horizontally, which I'll talk a bit more about later, and enables us to have the best performance with documents and unstructured JSON data, which as Dev said, is really the core to these AI workloads compared to Postgres or other relational who basically support JSON as a bolt-on data type. And then there's a bunch of limitations, including around performance and scale. Now MongoDB's invention of the document model helped it become well known with developers. But over the years, we've been fortunate enough to earn the workloads of a number of enterprise-grade customers who chose MongoDB. And these are banks, health care, government agencies. And so now we support some of the most demanding customers in the world. And these customers demand that their software and services exceed a very high bar on the dimensions of security, durability, availability and performance. And so MongoDB focuses on continuous improvement in each of these dimensions because in today's dynamic world, customer expectations continue to increase all the time. And if you attended the keynote, you heard of some of the improvements we've made and on some of these dimensions, including very notably performance. And these demands permeate both how we build the software, but as Dev said, 74% of our business is on Atlas also impacts how we operate the software. And this is important to think about if you were to take, say, an open source Postgres and try to make it your database platform as a customer, then you're responsible for ensuring you're meeting or exceeding the bar on all these dimensions. And there's a lot of work. And so I mentioned this because these areas are often not the shiny features that make the headlines. But we know from experience that this work is absolutely critical to earn and continue to earn the workloads from our largest enterprise customers. And the work we do here, we know, helps us earn trust and gives customers of all sizes confidence to develop even more mission-critical workloads at MongoDB. Okay. So if you saw our keynote earlier today, we talked about MongoDB 8.0 and some of the more powerful capabilities it provided customers. It highlighted that along with a number of feature additions, a very noticeable change with 8.0 was that it was the best performance release in MongoDB history. This matters for customers because it enables MongoDB to earn consideration for even more high scale and performance-sensitive applications. And I want to share here that uptake in this release has been stellar. Over -- so we released MongoDB 8.0 last October 1 and already over 2/3 of Atlas clusters are now running 8.0. So customers are really rapidly moving to this because the word of mouth is spreading and they're seeing the benefit that 8.0 provides. And just as a perspective, this adoption is over twice as fast than any previous release of MongoDB. And customer feedback has been consistent that 8.0 has been rock solid and has been our best release yet. So many customers have already adopted MongoDB 8.0. So I'll highlight a few. So Adobe, Coinbase, Cisco and Bosch. So just for example, Adobe, who will come and talk to us in a little bit more a little later today. In terms of performance, they saw database reads improved by as much as 30% and bulk rights improved as much as 50%. And then Coinbase, they basically -- after they upgraded to 8.0, they saw their latencies drop by 62%. And putting this in perspective, I met with their leadership team, they were basically preparing and reporting to their Board about their preparedness to maintain availability in event of large market spikes and fluctuations. And so the performance improvements we make here, taking down their latencies gives them confidence that they're prepared to meet wide swings in market demand. And today, we're very excited to announce that we've made even more major improvements and announced MongoDB 8.2, which is bringing both new features and yet more performance improvements. And we're really excited to put this in the hands of our customers today. So in the keynote, we talked about Queryable Encryption. And this is a powerful security capability that only MongoDB has. While in most databases, the data within the database itself remains in the clear so that it can still be queried, which means that anyone who has access to this database, administrators or employees can see all the data in clear text. Within MongoDB, we can encrypt that data but still have that be queryable for your applications, which means that people who have access to the database cannot see the encrypted data, but your application can still query it and make use of it. And so we -- today, we expanded -- in 8. 2, we expanded Queryable Encryption to add support for even more types of queries, prefix, suffix and substring. And so what that means is you can build an application now. So for example, let's say, I had a customer support application for a health care company. Now I can say in my application, let the support rep type in, okay, first name starts with Eliza B. The credit card number ends with 6789, and the medical note contains the word fever somewhere in there. Now all of those sensitive fields within MongoDB are encrypted in memory, offering security benefits, but the application can still pull up all of the records that meet those criteria and pull up maybe the few customers or probably with that one credit card, the one customer where that will match. So it's a really powerful capability that only we have. Now Queryable Encryption, you might say, okay, well, that's interesting. That's the future. But we introduced this in MongoDB 7.0. And so I thought I'd talk and highlight a couple of use cases of real customers who are already making use of it. We have customers spanning all these industries, technology, government, health and benefits and telecom. And so one example is a large global tech provider who serves both consumers and enterprises, founded in Palo Alto, California, has been -- has their entire consent management system consisted of billions of consent records powered by MongoDB Atlas and Queryable Encryption. Anytime one of their customers consents to anything, the data is stored in the consent management system using Queryable Encryption and systems across the company pull the system for consent records. Another example in telecom is Deutsche Telekom. And so this German telco provider powers their product and inventory management system that stores information related to mobile and landline contracts using Queryable Encryption. And so here, Queryable Encryption was a critical security requirement to handle the sensitive customer data such as customer contract and customer numbers, and it allows their system to pull up the records that it needs while still keeping the data underlying secure. And it was a game changer for eliminating the need for them to build their own encryption systems. So again, this is a powerful capability that only MongoDB has. So another thing we talked about is in our foundation, the document model and enables us to natively scale our database horizontally. And so if you look in the traditional relational databases, including Postgres, they primarily rely on vertical scaling. And this is really just tech euphemism for buy a bigger server. And so this approach has a number of issues. One, larger servers scale nonlinearly in cost. Two, as you are approaching the limits of that server, your performance typically degrades. And three, you'll always eventually reach a hard scaling ceiling. In contrast, MongoDB supports horizontal scaling, which is a bit more advanced technology-wise, but offers a number of benefits. So the first one is the cost of the servers -- you can use commodity servers and it scales linearly as you scale out. Two, you have predictable performance because you can always add more servers. And the third one is this is theoretically you can scale infinite or at least ahead of your workload needs and you don't reach a hard ceiling. And so as I mentioned earlier, horizontal scaling was built into our architecture from the very origin. This isn't true for Postgres or any of the relational databases. So you might say, but Jim, a lot of people do achieve scale using relational databases, how do they do that? Well, to obtain horizontal scaling, you either have to build a lot of complex, very hard-to-maintain machinery to scale your application horizontally across many databases. Or you -- some of the cloud providers provide their own variants where they basically layer stuff either above and/or below Postgres to get the scale and scale horizontally. Now that may seem compelling, but what a number of customers don't realize initially is that really then locks them in to that vendor solution. You might ask them, oh, what are you using? They might say Postgres. But if you're using some of the proprietary vendor solutions, you ask the next question, oh, well, how hard would it be then for you to move from that cloud vendor on-premises, that would become a very different story. So I think that's an important differentiation to think about. Another thing that I found very remarkable when coming to MongoDB is our ability to run anywhere. So I'm sure most of you know you can run MongoDB on your laptop. We have our Community Edition. McKesson will be up here in a little bit talking about how they run it in their fulfillment centers for medical fulfillment centers. And then a lot of people understand that MongoDB Atlas is a fully managed service. You can launch a database in, say, AWS in North America or Google Cloud in Europe or Azure in Asia. I think the thing that most -- a lot of people don't really realize is with just a few clicks of a button in Atlas, you can launch a single database that is spanning and replicate across all 3. And so not only are you taking advantage of that we support over 120 different geographic regions, but you also are taking advantage that with -- if you choose MongoDB, you have the optionality to move across the 3 largest hyperscaler cloud providers. And so we actually help customers span clouds. And this is something that, for obvious reasons, the hyperscalers are not helping customers with. And it's important to remember that MongoDB delivers the same database, APIs and features everywhere. No application rewrites, no workarounds and the same skill set lets customers operate across -- if they choose to, even across all these environments. And now spanning clouds is not simple as each has their own nuances and interfaces. We've actually had some large customers in the banking industry say that they're getting pressure now to -- they're on one cloud, and they're getting pressure to diversify. And they've actually been calling us because there are customers and they're saying, hey, Jim, how do you all approach this? Do you have any tips and tricks? And because it is a lot of hard work, but it's investment that MongoDB has made over the years in skill set and expertise and code. you might say, hey, why would customers want to run MongoDB across multiple cloud providers? And there are several reasons that we've heard from customers. So first, in a number of areas, including Australia and New Zealand, customers have regulations that mandate that they have a plan to show that they're not locked into a single cloud provider. A second reason, if you talk to any CIO or CTO, you often start out saying, well, this is going to be -- I'll choose my one cloud provider. But you fast forward a year or 2 and due to mergers and acquisitions, you're now -- you're running across multiple cloud providers. And now you have to say, okay, well, how do I do that? Do I have the skill set? Do I have the expertise to do that? Another example, which we might hear about from our -- some of our customers come up on stage is they -- if you have a customer that might want to dictate which cloud provider that you run their stuff on. And for example, it's well known that if you are lucky enough to earn Walmart as a customer, Walmart has opinions about whether or not you are going to run them atop Amazon's AWS cloud. And then the last one, which I think is kind of rising lately in the area of AI is really just having the optionality. So right now, if you ask a CIO or CTO, hey, can you predict which cloud provider is the right one for AI, could be availability hardware, NVIDIA chips or what have you or who's developing the best AI services, think the answer is it's not crystal clear how things are going to play out. So as a CIO or a CTO, you want the optionality to know that you could easily bring your data to the cloud where those services would be. And so with Atlas, we're happy to make all this easy for them, all with just a few clicks of a button, and that's part of the value that Atlas provides. So we just walked you through some of the reasons customers tell us they choose MongoDB over Postgres and other relational offerings, flexible data model, Queryable Encryption, run anywhere, fully managed offering in Atlas, multi-cloud and multi-region and native scaling horizontally and sharding. And it's important to think about Postgres -- so first of all, Postgres is a big broad umbrella, which really includes at least a couple of different variants. One, where we labeled here vanilla is if you take open source Postgres and you try to run it yourself, you could very -- you could argue, hey, I can run that anywhere, Jim, and that's definitely true. However, you won't be getting some of these other things like the flexible data models, bolt-on JSONB data type. You won't be getting native Queryable Encryption. It won't scale horizontally without a ton of work and effort that's a lot of complexity. And then you say, okay, well, I don't want to run it myself. I bought into Cloud Vision or what have you. So then you could say, okay, well, go to one of the cloud providers that provides a managed offering and so you get that. But now you're really locking yourself into one provider. So your run anywhere goes away, and you still don't get some of the other capabilities like native Queryable Encryption. So we think -- we're going to hear from customers of how they think about this, but this is some of the points of differentiation customers tell us about. Okay. So yesterday and earlier today, we announced our Application Modernization platform or AMP. And AMP is the result of several years of collaboration with our largest customers, helping them modernize and migrate their applications to MongoDB. And so this new platform enables companies who previously viewed migration and modernization to a new technology as just prohibitively expensive with the power of AI-enabled tooling that we've developed, we've been able to show that it's now possible. Started as an experiment, we were skeptical, too, can we just throw AI at everything and magically works. And we found sadly no. But we developed a bunch of experience there and then built tools and techniques to approach it. And now we've been seeing some wins with our customers. And so our Application Modernization Platform, as we talked about, is really comprised of tools that we've built, AI-powered and deterministic tools to help accelerate a lot of the phases of the modernization process, which historically with a big SI approach of yesteryear would take years and years with a high degree of failure. Techniques and methodologies that we developed because we found, like I said, you can't just throw all the code of ChatGPT and assume it will work. And then talent because basically, we need to have people who understand our tooling that we've developed, but also can engage with customers and help them realizing that this is part of -- for them -- for us, we want to get all their data liberated and into MongoDB so they can now be nimble and develop new AI applications. But for them, it's their business at risk. So making sure we're meeting the customers where they are and helping them migrate over. And so our primary focus right now is on Java applications running on Oracle because we -- by our estimates, this represents approximately half of the global total addressable market. Over time, we plan to expand beyond this over time, guided by customer demand and market opportunities. And so if you just read the headlines, you might think, okay, well, AI is just about the code generation. But as we walk through a little bit over this morning in the keynote, really, there's a whole bunch of phases to modernization. You have to analyze the code and your applications that are there. You have to generate test to know that whatever code you replace it with will produce similar results as the existing thing that may be an application that's been there for 20 years. You need to convert the code, you now need to validate the code that you converted and then you have to deploy and migrate. And so all these steps are important. And we built tools leveraging AI to help in each one of these steps. So let's just take the analysis phase. This is the first bubble there. So some of these applications are very, very old. You go to these customers, and they don't even have the developers who originally developed them, they have retired or moved on, right? And so in many cases, customers don't even -- they don't have the architectural diagram. They can't even describe what is there. They just know it's a critical piece that's been running their system. We've had -- so this is an example of tooling that basically does a static analysis of existing code and dynamic analysis of their system to help us understand what is there. And we've actually had customers tell us, hey, our application runs on this big relational database. And once we do our analysis, we surprise the customer to alert them that actually, no, do you know it actually depends on 2 different relational databases, and they were surprised. So anyway, this is one example of the tooling that helps us. So even just as we start and get engaged, this kind of analysis helps us speed up the process and brings a lot more fidelity to the process we're doing. Another area is code conversion. And so a lot of what we're doing -- a lot of customers have a lot of application logic locked up in stored procedures. And for those who are not familiar with stored procedures, it was -- it's kind of not really a pattern people do as much today. Back in the day, it was all in vogue to put application logic in code that would be inside your Oracle database. And the problem with that is, one, that code was not always checked in and sitting alongside your job applications or your other application code. So it's kind of hidden. And two, a lot of the LLMs actually aren't trained on that code because it's not in the GitHub repositories and all that. So that brings some challenges that we've been able to figure out how to navigate. And another example, too, is we've found that some of these store procedures are giant. And if you just try to take that and throw it to an LLM, you're just not going to get the results. So part of our process and our techniques is basically chunking that into smaller batches that are more isolated, testable and figuring out how to take this giant monolith of store procedure code and break it into smaller testable reusable chunks. And so that's another example of where we developed tooling. Okay. So that's all good, but let's talk about some customer results. So Lombard Odier successfully migrated key applications from SQL database to MongoDB. This resulted in migrating over 50x faster than they were able to do previously and reduced regression testing time from 3 days to 3 hours. Intellect AI, one of the world's largest enterprise fintech companies, reduced onboarding workflow times by 85%, enabling clients to access portfolio insights faster and development cycles were sped up by as much as 200%. And then Bendigo Bank reduced the development time required to migrate a core banking application from a legacy relational database to MongoDB Atlas by 90%. With AI tooling, the bank was able to reduce the time spent running application test cases from over 80 hours to just 5 minutes. So Bendigo migrated onto MongoDB Atlas at 1/10 of the cost of traditional legacy to cloud migration. So here are some proof points of that. And just a reminder that we've had sessions, breakout sessions that are being recorded where we are going into much more detail, including demos of the tooling we have. Okay. And now is when we transition to bring up our 2 customers for our guest panel, we'll play this exclusive new 1.5 minute video from one of our customers, explaining why they chose MongoDB, so that you can hear it -- from it, in words of our customers and not just me. [Presentation]

Thank you. And now I'd like to welcome up Tom Valletta, Enterprise Architect at Adobe Workfront and Scott Mooney, VP of Distribution Operations at McKesson. All right. So first of all, thanks so much for coming. Really thought it would be great for this crowd to hear from customers. So first, could I ask each of you to introduce yourself and your company?

I'm Tom Valletta. I work for Workfront, Adobe -- sorry, Adobe Workfront sometimes. Anyway, I've worked there for 6 years. Workfront is a marketing system of record or a content supply chain for marketing organizations to keep track of their marketing operational work. And so that's Workfront.

Okay. Good afternoon. My name is Scott Mooney. I'm with McKesson Corporation, and we're probably the largest company in the United States that most of you may not have ever heard of. We kind of fly a little bit below the radar on publicity sometimes, but we are a pharmaceutical company by base, but we also have technology divisions offering software services, technologies such as automation and robotics, data management services and other things. Mostly in the United States and Canada at the present time, we have had European operations that have recently scaled back, but that's kind of what we do. For McKesson, I'm an operations person. I come from the business side of our business, and that's mostly shipping boxes around the country, but I'm just coming off of a 13-year adventure leading a large technology project deploying out our traceability systems.

Cool. Well, with that, maybe do you want to expand a bit more on your workload, and then I'll ask you to do the same.

On my workload? You mean how long it is? It seems like it starts at 5 a.m. and goes to midnight, but...

No, no, the application.

The application, what we do. So the project we're just finishing up is called the Drug Supply Chain Security Act. And you might have heard a little bit about that from 2 of our technology people this morning. We are now in the United States actually embarking on an adventure where every single individual bottle of a prescription drug has a unique serial number attached to that bottle and a barcode, and it is required to be referenced as that product goes through a transaction from production to the manufacturer, distribution to a wholesaler to a dispenser. We can now identify exactly where every individual bottle has gone through that journey from start to stop. And we do that with millions and millions of bottles every single day.

That's mission-critical and at scale. So what about you, Tom?

Yes. So Adobe acquired Workfront about 4 years ago. Workfront, we provide a SaaS application that's business-to-business for the -- some of the largest marketers in the world, Coca-Cola, Amazon, Google. Those are some of our customers. What we do, we -- the SaaS application lets the marketers keep track of their campaigns and their marketing operations, their projects as they build digital assets and then get those into their marketing efforts. And so that's what Workfront does.

Great. And do you mind expanding on why did you choose MongoDB? You had a choice of technologies in front of you, but both of your companies could have chosen anything. Why did you land on MongoDB?

We actually started out with something different. For our serialization journey, we acquired a standard package from our ERP solution provider and stood that up as our original source of truth. But we found after we implemented it that it wasn't organized in a manner that was appropriate for the kind of questions we were going to be asking the system. The system had been built with a drug manufacturer in mind and drug manufacturers deal with a product then a lot underneath the product and then serial numbers underneath the lot. And that's the way they structured that original system. Our customers were asking us questions about tell me about the data for the transactions I had today. Tell me about the data for the transaction I had last week. Tell me about something I may have bought 2 years ago. And we found that in our original database system, original core system from the ERP provider, it bogged down. So we were looking for something more robust to be able to give us that ability to manage multiple different queries, different kinds of queries, more structured in a different way. Your application fit that bill for us and was able to be stood up fairly quickly. So we actually now run them both. We run one as a regulatory source of truth. That's something we let the government look at when they ask questions. We run the other one to be an immediately responsive system to our customers to be able to give them the information that they ask for.

Awesome.

We also started off with a different system. We have a -- we started off with the SQL system and a monolithic system connected to it. And as we started onboarding new customers, we got to the point where we had just over 1,000 customers on this single relational database, and we were running into all sorts of performance issues. And so we knew we needed to shard it. And so we created a second copy of it, and we said, all right, all the new customers are going to go on to the new one. And that lasted for about 500 more customers and then that ran out of capacity. And then we added another one and another one. And I mean we got to the point where we had full teams kind of managing the sharding and making sure that like the customer data got routed to the right place. So as we started to disaggregate our monolithic systems, we knew that we couldn't continue down that path. And so we had to put all of our new services on to -- basically on to Mongo. And the reason why we chose Mongo is because we knew that at a certain point, we were just going to run out of the ability to scale. It just wasn't going to work any longer. And we know that operating -- a lot of our engineers come from the SQL background. They know how to approach SQL. But if we get them started on Mongo, Mongo, it was a little bit more of a learning curve, even though it was very easy for the developers to get started on. It made it so that like they could approach that difficulty early in the process. And then when everyone says like -- when we get to that point where scale is our problem, that's the problem that we want to have. Everyone says that. But no one wants to be at that cliff where like all of a sudden, they're hitting that scale. And the cliff is in front of them and they're like, all right, now we have to rebuild everything, and it's huge. And so all of our new microservices are on MongoDB for that reason because it will continue to scale with us, and we don't run into the same problems.

Yes. We had a recent example of that in our drug traceability requirements. We've been piloting this for the last couple of years, but August 27 was the required go-live date that we had to turn the system on. Everything had to be active. Everything had to be perfect in the government's eyes. So up until that day, we were fielding through the MongoDB, maybe 1,000 inquiries a day coming in from customers through our 7 different portals that we have attached to it. Customer can access through any one of those portals with their credentials, state their question in the portal and queries out to the Mongo database. We went from having 1,000 queries a day coming in to August 27. We ran almost 400,000 queries the following morning between 8:00 in the morning and noon. And we didn't really notice any performance differences or anything. The system just automatically picked up the volume, handled the volume. There was no query problem, no problem for us. It was almost like it didn't happen. It became almost a nonevent in that regard.

That's awesome. Yes. Yes, and then kind of tying back, I think you talk -- I'm an engineer, you talk to engineers, oh, can you make this work? You start out with a relational system and said, okay, well, can you shard it? And I'm sure the engineers is like, yes, we can do that. And then, well, can you shard it again? And I think engineers are not the best about thinking of the overall business complexity and cost of, oh, wow, well, now I need more engineers and all that. And so I think there's a tendency to underlook the power of, as you were saying, just, hey, the database just scaled horizontally and just works. So glad to hear that is valued. So Scott, one thing was interesting when I was talking to you previously, you guys use MongoDB actually within the fulfillment centers itself. Can you just talk a little bit more -- and I believe Atlas, your counterparts were saying on stage, too. Can you just talk about your -- the topography that you need to support and how MongoDB helps you with that?

Sure. So in our world, we have about 60 distribution centers through the United States, and we handle products from simpler medications such as regular over-the-counters like aspirin to the very complex medications that may be patient-specific or they may be for oncology treatments. Oftentimes, these are very critical need issues. So part of our design of our base system is to centralize as much as we possibly can, but as a fallback because things happen like you lose your data lines, you lose your connectivity. Every facility has to have the ability to continue to operate independently until connections and communication is restored. That meant that even though we were doing most of our traceability information in a centralized database, replicate copies of that information had to exist in each of the distribution centers so that for the next 12 hours, 24 hours, whatever it may happen to be, they could continue to operate based on what they know about the product until connectivity is restored. So mirror images of the database have been disseminated into local servers in every on-premise location of McKesson. That facility can continue to run as long as it has power and they have their own generators to provide the power. So it keeps us in a fulfillment mode with our customers.

Yes. And I was impressed talking to you and your team about how getting drugs to the right people. Some of these are patients with really urgent conditions, you really look at this as kind of a life or death kind of situation and you take the -- make sure you have the operations to support that, and that's what really...

Yes. It's one of our models in the business. When you walk into one of our warehouses, one of the things you will see as you walk in is a big sign as the employees go into the workplace that says, it's not a package, it's a patient because that's really the way we view it. But that criticalness of being able to have a local disseminated database for those instances when we need to be able to operate that facility and keep that thing in tune with what the master system says is very important for us.

Yes. Well, I appreciate you trusting MongoDB with that. Tom, what about you? You were telling me how you run on -- you have the need to run on multiple clouds. Can you tell us a little bit more about how we help you there?

Yes. At about the same time that we were kind of trying to disaggregate our monolith, we had some new customers come on that had some specific cloud requirements. We were running all on AWS and Google became a customer. And Google said, of course, we're going to operate on GCP. And so we said, okay, when Google comes as your customer, and they bring a lot with them, we said, all right, so we'll run on GCP. And as we approach the database conversations there, Postgres will run -- we can run Postgres anywhere. But as we try to use the cloud offerings for Postgres, they're very different from AWS to GCP and from GCP to Azure. And so that on top of the other problems we were already having with Postgres was difficult for us. So as we started putting more of our workloads on Mongo, one of the great things that we noticed is you can build the same tooling against any of the clouds. It works in exactly the same way. The code is the same. You don't have to use -- you don't have to adapt your code to someone else's flavor of Postgres. And so that was useful for us. And then as we had more customers come on that had stricter enterprise requirements like a lot of our customers put -- their marketing information is very sensitive to them. They think of it as their secret sauce. And so they want it locked down. And so they wanted to bring their own encryption keys and provide us with those encryption keys while we were hosting their data, but then when they were done with us, they wanted to be able to pull those keys and walk away. And so all of the major cloud support bring your own key encryption, but all of them do it in completely different ways. And so having to build that several times was not something that we wanted to get into. And Mongo is the cleanest implementation of bring your own key encryption that we worked with. And so it's consistent across all the clouds, and it's useful when we have customers coming to us that are -- that have to operate in one cloud or another. You mentioned Walmart earlier. Walmart is one of our customers. They're like, we don't have to operate in any specific cloud, but we will not operate in this specific cloud, right? And so that's something that we have to deal with, and we appreciate Mongo for making that easy for us.

Great. And one of the things about Adobe, I -- maybe I'm gating myself, I think more of kind of an end user or a creative as a customer, but you're telling me basically in your business, you're really more of a business kind of application, right?

Yes. When people think about Adobe, they think about Photoshop, right? They think about Creatives who are using the tools on their local desktop. But half of our organization is this Experience Cloud, B2B, where we serve enterprise marketing organizations. And so we approach things from this enterprise perspective, like businesses who rely on our data day in and day out. We -- they have to work in our SaaS platform every day. They expect us to be enterprise. And we kind of went from thinking of Mongo as this like very easy for developers to get up and running, like it's this like very friendly platform for storing your data. But now we rely heavily on the enterprise controls that Mongo provides for us, and they're best-in-class, like we can't get those even from the other cloud vendors. So we prefer to work with Mongo because of its enterprise capabilities.

It's great to hear because like I mentioned earlier, I mean, that's one of the things we've really been investing a lot in, security, durability, availability, performance. Like we -- I tell my teams, like we only earn the right to talk about the next new shiny feature once we can guarantee to customers like yourselves that we can not only meet but exceed your expectations on those dimensions. So Great. Would you mind sharing any lessons that you've had to customers or investors who talk with customers, what lessons would you share to others engaging if they were going to start engaging with MongoDB?

I'll jump in. So for us, we had to think about things a little bit differently when we approach problems, using Mongo is a little bit different. But like I was saying earlier, if you approach the problems with the right technology stack at the beginning, then you can scale beyond where you get stuck. And so understanding the view that we would give to our customers and the perspective that they want to see the data, we can format it that way and get really strong performance out of Mongo. And that's something that I think that a lot of people kind of approach it from this like how should I model my data independent of like what my customers need to see. And for us, it's all about like, these are what the customers are coming for. Here's how I'm going to present the data for them that gives them the best possible view.

Yes. And in our case, we had a relationship with Mongo that goes back to other projects before the use case that I referenced earlier. So you guys were a known commodity to us to a certain degree. When we came across this particular use case, it was fairly quick to come up to speed that we had something as an opportunity here. The Mongo team worked with us hand-in-hand to help support that. And we even kind of drifted a little bit near the end because the original goal was simply to stand up the ability to have an on-prem system and the ability to be able to be more responsive to the customers than our traditional legacy system from our ERP supplier. But we tripped into the AI discussion. And it was really an interesting kind of partnership because in a matter of about -- I think it took 4 weeks between the Mongo support and our people, we mocked up a pro forma AI tool that replaces the user interfaces in our DSCSA system. Nobody has to learn how to click this tab here, click over 3 tabs to click there and then they get another screen and the piece of data you're looking for is in the bottom corner. The prototype is allowing them to just ask a plain language question. Tell me what you know about this serial number and the system through the AI tool is going out into prototype and looking for that information. It may not sound like a terrifically big deal, but we have a call center that needs to use this tool with 200 people in it, and they have a 20% turnover rate. And we started calculating what is going to teach us or cost us to train people. The AI tool kind of takes that out. So now we're looking to move something into production and look to develop it a little bit more.

Like Scott, we have a lot of -- I mean, there's a lot of vector tools out there that we could use. But having all of our data in Mongo and then having the vector database that's right there with it, where your data already is, that's been super convenient for us as we approach AI solutions.

Great. Any last words for the audience before we stand between them and lunch?

Never a good spot to be in, by the way. The worst spot though is between you and cocktail hour. Now, I think for us, the software does more than what we originally expected. It does more than we could have done with the other tools that we had available to us. Mongo has been more flexible. But it's really been that partnership with the organization as well because it's one thing for somebody to have a fantastic product, but how well they support the product has been key for us to be able to deploy it, implement it and get it out there.

For us, I think that the enterprise value is what surprised us. Mongo is an easy tool. And usually with easy tools, you -- they like have a level where they kind of start to fade. And we haven't seen that with Mongo. And so we really appreciate that.

Great. Well, thank you so much for making the time and talking to us about your use of MongoDB. Thank you. So lunch is outside, and we need to be back in seat in 15 minutes to keep on schedule. So if you could go do that and come back, we'd appreciate it. Thank you. [Break]

One of my favorite 70s band, Boston. I haven't heard that song in a long time. 2-minute warning to use the football analogy, and then we're going to have Fred start if we could. Thank you. Hello. Hi, everyone.

All right, sit now. Hi, everyone. I'm Fred. Nice to meet you. Great to be here. I joined MongoDB 1.5 years ago. I lead Atlas Data Services. And I will walk you today through our AI product strategy, where we are headed. And I hope to share some of why we are so excited and bullish about it and how we are helping our customers to build the next generation of applications. So the goal is very clear and very simple. We enable developers to build AI projects that are really making it to production. It's never been easier to hack a [ WipeCoding ] application. These tools are impressive. I love using them. They are fun, and they bring real value. Like it's very satisfying to be able to spin up a prototype in a few hours, very valuable to be able to build these tools and automation in a few days instead of weeks. Now building and bringing serious consumer and enterprise applications to production, real users, real data, real integrations, real security, real scale, it's still hard. Actually, it's even harder with AI because there are new building blocks. They are hallucinations. The costs are super hard to predict. So the reality is that the vast majority of the AI projects out there, they fail. They don't make it to production. And when they do, it's a long and painful journey. So that's exactly what we are here to solve, help developers build AI for production and run AI in production. That's good for them. We love our developers. We want them to be happy. And that's a massive growth opportunity for MongoDB because we already see that these AI workloads in production, they generate more data, and they consume more services to handle this data. So what does this mean in practice? Three very simple and clear developer needs out there. Number one, speed. They want to develop and iterate quickly. So the problem is that the stack -- the AI stack specifically is fragmented and complex. That's not a new problem, but it's been amplified by AI. So we'll speak about that. Number two, developers want to see the AI magic. We are building these AI applications because we can delight customers, we can cut costs, we can innovate, we can -- you need AI magic for that. And this AI magic is coming from the models, especially how the models can be connected to your data. And we also see that in real use, these models can fall short. And third and last, nobody just want to launch an application. Success is launching an application, running it in production, being used by real users, being nimble when you scale up, when you scale down, react, change and not new either, but with AI, that's a very different ball game. The pace of change and the amount of data that is generated is making it really hard for developers out there. So that's our focus, make a real difference for developers, simplify this journey to production. And in the next few slides, I'll come back to these 3 different stages and show you how concretely we are helping developers do that. So step one, move fast. We talked about earlier how this one wasn't new but was amplified by AI. So I want to show you what I mean by that. When we speak about AI, it's not one thing. There are many use cases, many applications that our customers are building. It could be a chatbot based on RAG and Knowledge Q&A to automate customer support. It could be recommendation, pick your favorite streaming video service to show you all these are maybe the movies that you should watch next, or it could be your e-commerce application, if you want to buy this nice-red shoes. And more and more with customers, we speak about agents, AI agent, agentic systems. These systems, they need this agentic systems. They need memory. They need context. They need to model relationships between entities. They need accuracy. They need speed. So what does that mean under the hood? Under the hood, these different use cases need some building blocks to enable these AI capabilities. They don't all need the exact same building blocks, but they all need many of them. So I'll spend a minute on this slide because I really want to walk you through 2 or 3 concrete examples to make sure we speak about the same thing. So first line, let's take a bank, and the bank want to develop a chatbot to handle customer support for their customers. Obviously, you need an LLM. The LLM is really the core of the experience. You absolutely need a strong embedding model and a vector database because if you only answer with the data that the LLM knows and what is out there in the Internet, you won't be very effective in answering your customers. Now the objective of this chatbot for the bank is to increase the satisfaction of your users and also maybe decrease the cost of your support structure. So your goal is really to minimize the number of time you have to go through a human, and you want at maximum to be able to answer these questions. The reality is that if you want to do that well, you most likely also need to go to your database directly. Like if a user is asking you, "Okay. What are the limits of my credit card?" It may be a wise idea to go to the database, check what type of credit card this user really has and make a real search about the limits for this credit card. And then you can combine that with many things that your vector search will tell you like how to increase limits and et cetera, the kind of problems that users are facing in the field. But that's what we call hybrid search. If you really want to improve the efficiency of this chatbot, you will want to [ buzz ] the database in the vector search. And a reranker, I'll speak about rerankers later, so -- but that's probably a good idea for this one. I'll take another example, recommendation. Again, you're on an e-commerce site, and you want these red shoes, you don't need an LLM, you just type red shoes, write [ tennis ] shoes or whatever. You probably need an embedding model and a vector search because that's a huge catalog, and you want to show as well these burgundy sneakers to the user. You don't want to narrow the search. You want really to expand. You probably don't need to know a lot about the database -- the user in the database, but you still want to access the data to filter because maybe you don't want to show items that are not in stock anymore. Or maybe this user, you know that they only like 5-star or 4-star-plus items, so you only want to filter. And in that case, you also don't need a reranker most likely, but I'll come back to that. Last example, an AI agent that is able to book your holiday, based on your preferences and your dates. I will not come back to each of these small points on this table because the AI agent basically needs all of them because an AI agent need durable memory. So you need to do real -- because probably the vacation you took 1 year ago could influence the right vacation to advise this year. So you need durable memory, and you need to do search and vector search, and you need context. You need to understand what has been done and not. And you need also to store preferences because maybe you like boutique hotel or maybe you like this kind of restaurants. So you need all of that. Now the reason why I still wanted to mention this AI agent and agentic system is that actually this table is oversimplified. There are at least 2 other capabilities that an AI agent will need. Number one, usually, you have different agents. You may have one to book the flight, one to book the restaurant. And they need to communicate, and they need to know the relationship. So you probably need graph capabilities to model these relationships between your agents. Next. If your flight is delayed, you will want to react fast. Your agent will want to know that and maybe trigger another action that's an event-driven architecture because the restaurant booking has to be canceled. So you probably need stream processing as well. So overall, the message is there are many building blocks for AI. And it's really hard. I haven't been able to do that to find one use case where you don't need many of these building blocks. Now if you are a developer, what does that mean? That means that you have this large architecture and all of these products and capabilities that you need to deal with. So you could do a couple of things. And you could indeed decide to stitch together product. You could decide, "Okay. I will take a database and embedding model and a vector database and a graph database and a stream processing service. Stitch them together via APIs. Create this data pipeline to really make sure your data is in sync between these systems. Connect them multiple times to your identity provider. Connect them multiple times to your secret manager. Connect them multiple times to your observability platform." You could do that. Don't tell your real friends to do that. But you could do that. That's a long and winding road, and it's probably not leading to building and iterating quickly. MongoDB response to that is bold simplicity. These data building blocks are: one, natively integrated; and two, they are where your operational data is. That's where they belong, these data services. The simplicity doesn't just mean that it's faster to build. Yes, it is faster to build because you have one tool to learn, et cetera, et cetera, everything we mentioned before. It's also better for performance. And if you have already tried to optimize the performance of a distributed system, you don't like these network latencies, and you don't like the data transfers. That's also better to secure because if you have been through the security of one of these big systems, usually, you like to have box that the auditor can go through. So overall, this natively integrated platform is helping customer build, iterate not only faster but also the right way. Most of what you see on this slide is already there, database, search, vector search and I mentioned graph capabilities and stream processing. The embedding and reranking is really something we are working on right now. I'm speaking about that a bit later. We got the best embedding and reranking models from Voyage AI, but we are still working on the native integration to make it really part of this platform. It's already used by thousands of customers. It does resonate with customers. Sometimes it does resonate with customers immediately, right away. Sometimes they need to go through the pain of [ stitching ] these services, and then it will resonate better. But yes, we have thousands of customers. We are investing a lot in the ecosystem for the exact same reason, simplicity. So for the developer, we want to meet them where they are. I mentioned a few, which is a bit heartbreaking because that could be a long, long list, but our long-chain package, strong adoption, strong growth of adoption for the package that allow AI agent to build durable memory and context on MongoDB. We announced last week a Vercel integration. So now when you are starting your project, your AI project in Vercel, you can directly create from there -- from the marketplace an Atlas cluster and build your project the right way. And Anthropic, we have blueprint to make sure that when you are building your RAG, your AI agent on MongoDB, you will do the integration with the LLM properly. Last, we keep delivering, keep building, keep executing. We just announced super fresh that search and vector search are in public preview in community and enterprise server. We deliver on our run anywhere commitment, and we respond to very high customer demand. Earlier this summer, we announced $rankFusion. So I will not come back to the details, but that's exactly the hybrid use case I mentioned before for the bank chatbot. If you want to boost your results, the quality of your results for some use cases, for quite a few use cases actually, it's better to do a vector search, a traditional lexical search and get the best of both worlds. And last, we are in private preview right now. Customers are playing and giving very -- I mean, nice feedback about our auto-embedding capabilities. This is the very first Voyage plus MongoDB native integration. So if you're a vector search on Atlas -- vector search customer, you don't even need to care about your embeddings. Like, we'll generate them for you when your database is updated, generate them for you when your user does a query. If later, you want to upgrade to a new model, we'll do that for you. That's really about the seamless integration between vector search and embeddings. And to come back to a couple of very concrete use cases. So customers using our solutions in production for real AI workloads. Iron Mountain, it's pretty cool, actually. What they do is they allow users to retrieve information across digital documents but also scan the paper or documents because they have many of the large companies. Financial Time is really a recommendation. So I mentioned an e-commerce example earlier in the streaming platform. This one is also to drive engagement of their users to make sure that you do propose the right articles they may be interested in. So they are using also Atlas vector search for that. And Okta is also a very cool use case. Sometimes when you are in this -- you're in your job, and you have all of these applications, and you never know which one you should use for -- to claim an expense or to book a trip or something like that, they develop this natural language interface based on Atlas vector search as well. And you can just say, "Okay. I need to claim an expense," and that will open the right application for you. All right. I'm taking some water, and we'll go to step 2. So step 2, developers need to see the real AI magic, and it's all about the models. And more precisely, the real AI magic is all about how the models can be connected to the real data of your company, of your application. Before we dive a bit more into that, I want to make sure that we speak about the same thing, and we all understand what is an embedding model and what is the reranking model. The embedding model turns unstructured data. So unstructured data is everything, text, image, audio, video. That's basically the data in the real world that the data that AI consume and generate. The embedding model transform this data into what we call a vector or an embedding, a very long suite of number. And this vector or this embedding captures the meaning of the data. So that's already pretty cool. Now you can have something representing the meaning behind this very unstructured data where -- before you couldn't do any operations on this data. What is really to understand a bit more of the magic, I think we can picture a map. Actually, what these embedding models do is they capture the meaning of the data, but they place it on a map. And then your application can navigate this map and perform semantic operations on this data. You can measure how similar 2 pictures are. You can retrieve an object in a video, and you can determine whether 2 text documents cover the same concept, even though they use different words. Now if we go to the reranking model. Embedding models are great at pulling out a few results from a huge corpus of data. We have customers of search and vector search using -- having billions of chunks of documents to perform their search right now. And embedding model will be superfast for that. Now if what you need is the single most accurate answer, similarity is not enough. Even if your embedding is heavy and long, it's not enough. You need to inspect that more. That's what rerankers do. They really run a deep compute-intensive check on the document, on the query, and they will push the best match to the top. So I will give you a picture maybe if there is -- to try to understand the difference between an embedding and reranking model and how they are related. Let's imagine you're in a big city, millions of people, and there's a crime. The embedding model will be able to very quickly find the suspects and bring them to the courtroom. Now you need a reranking model to run a deep investigation of each of the suspects, and that would be longer to really find who is guilty. So for some use cases, it's okay to have a suspect, that's good. For some AI use cases, you really need to get the single document. Agent systems, because they don't just recommend things, they act. Usually, they don't need -- oh, these are the 5 or 6 best documents. They need the one because then your hotel would be booked, or your restaurant would be booked. So the good news for us and for our customers is Voyage AI models are the best in the industry. They are the best because they are very accurate. So they give you better results and are beating competitions like OpenAI and Cohere. They are cost effective. Voyage-3.5, that is mentioned in this list, is reaching better results with embeddings that can be multiple times shorter, smaller than the other embedding. So why it matters, because some people don't realize that. Your embeddings can be as big or even bigger than your data. So yes, they do bring a lot of value. They do enable a lot of AI magic, but they can be very costly to store. And last, these models are very innovative. Multimodel is basically you can perform semantic operation, mixing text and videos for example. So that's very valuable for some use cases. The one I think is really breakthrough innovation is a voyage-context-3. So I will not try to make a technical explanation about that, but I want to try and make a simple example to show how this one is really a needle mover and how it does reduce hallucination. So let's imagine that you are building a chatbot, typical RAG pipeline, and you have a lot of documents that you pull from different sources, so typical chatbot with the RAG pipeline. And in the chatbot, you ask a simple question, which is, "How many kids -- how many children did the President of the United States had in 2002?" My example is not perfect because you don't need a chatbot for that. LLM already knows the answer, but I'm just sticking to a simple example. Let's imagine that somewhere in your huge corpus of data, you have a sentence that say, "In July 2002, the President, his wife and his 3 daughters went to," et cetera. For a vector database, that's gold, that's bingo. An embedding model will tell you, "Oh, that's a perfect match." And so you will get us an answer, "Well, the President of the United States in 2002 had 3 children." And the chatbot maybe even proud to say, "Well, and these were 3 daughters and their names," et cetera, et cetera. If this document was part of a history book or newspaper archive, that's great. That was a good answer. And that's what embedding model we were doing so far. They didn't know the global context. They were handling chunks of document. What if this document, this statement is part of a movie script? What if you didn't answer with a real number of children of George W. Bush, but you answer with a number of children of the character played by Martin Sheen in the West Wing. And so context is everything, and it can really reduce hallucination and give better results to users. So why does that matter? Well, that matter because for your chatbot use case, for your agent use case, the value is obviously in the LLM, and these models are incredible. But it will only be good if they are grounded in your real data. And embedding is what is creating the bridge between LLM and data. It will also improve user engagement, if you speak about a recommendation use case. So if you want to have more relevant chatbot, better AI agents, better recommendation engine, you need great embedding and reranking models. Anthropic is recommending our embedding models in their documentation because it's linked between LLM, and data is so important. All right. So that was step 2. It feels like we are done. We can build and iterate fast. We have great models. We have the AI magic. And the problem is that the real test is the real world. So we have to go to production now. So to step back a little bit. So this one is probably the easiest argument to make. It could have been one sentence, but this graph was pretty cool, but it's good. Pace of change is incredibly fast with AI, and the intensity of change is also bigger. If you think of the Internet, the major inflection in reach that it was, you could build one application, deploy the application once, and you could reach millions of a night. Then you have the cloud inflection point, which is about scale. You have to build, but you take care of your infrastructure with the cloud vendors [ you ] take care about the platform. So you can scale to billions in hours instead of weeks or months or even more sometimes. With AI, we are really reaching full velocity. The data is created and consumed by AI. AI don't sleep. It's always on. It's self-reinforcing, and it's no longer limited by human speed. So we are just at the beginning to see that it's pushing the boundaries of what the database need to handle. That is really just the beginning. So now more data, faster change. That's exactly what MongoDB was built for. It's our DNA. So the document model make it super easy to be flexible. As a developer, you change the code once you ship it. You don't have to change also your database and then the mapping between the database and the object and then check that your store processes are not broken, document model. And distributed system, horizontal scalability. You can absolutely handle a peak of traffic, and you can scale up and down without breaking the user experience, without breaking the developer spirit, which can be important as well. We don't reinvent the wheel. These design principles are leading us where we are, which is the best database for change and for scale. We are building, doubling down this principle for AI. The embedding, we don't have a new structure. You just store them in your document model. Search and vector search, we are creating search nodes. You can scale vertically. Yes, but you can also scale vertically -- horizontally. You can do both. And that's very important because some search systems, sometimes there is a little bit of data and very high activity of search queries. Sometimes you have a huge database and -- it can be both ways. You are not constrained by anything. You just scale horizontally as much as you need. And the other point about change and scale is, I mentioned the [ bold ], the simplicity and why this one natively integrated platform was better to build and to maintain and to achieve the right performance. It's also far better when something changes or when you have to scale. Nobody wants to turn all these nodes in 5 different systems because you need to do a 2x or 3x on your traffic. So one platform to build, one platform to maintain, one platform to secure, but also one platform to evolve and scale. So that's it. That's what we are focused on. This space is moving superfast. So we stay humble. We focus on execution, but we also know that it plays on our strength. Search, vector search, embeddings natively integrated right to the operational data where it belongs, you can build and iterate fast. The best-in-class embedding and reranking models to unlock the potential of these AI experiences and really bridge data and LLM and an architecture built for adaptability and scale by design. That's what MongoDB has been doing for years and years. So we believe we have the best platform for developers to build, launch, run and succeed in their AI projects. So now we will transition to bring up 3 amazing customers on stage for a panel discussion. We'll play an exclusive short video as we did before of one of our amazing customers as well, who couldn't make it, who are building incredible stuff with us. So I'll let you watch that, and then we'll discuss in a few minutes. Thank you. [Presentation]

All right. So we will welcome on stage Sudheesh, Shaun, Steven. Thanks a lot for being here. Where are you? I've been told Steven and you shouldn't be sit together. So I didn't...

Not too close.

Okay. Not too close. Okay. That's all right.

We used to work together. That's why.

Okay. Awesome.

And he's a Niners fan, too.

Yes. So great to see you. We talked a lot about our product, our vision, how we solve our customers' problem. But the real test, what is really important is to hear directly from you folks about your experience working with MongoDB, about what you are building, about what you see happening. I'll let you introduce yourself first, and then we'll start.

Cool. Hey, everyone. My name is Steve Poitras. I'm one of the founding architects at DevRev. Very happy to be here today and very happy to be in partnership with Mongo as well. So thank you again.

Guys, I'm Shaun Roberts. I'm a distinguished engineer in CX for Cisco and very happy to be here as well.

My name is Sudheesh. I'm the CEO and Co-Founder of a company called TinyFish, just got launched a couple of weeks ago.

Yes. I've seen that. Your blog posts are really good. So Awesome. Maybe the best way to dive in is to tell us how you are using MongoDB. So I don't know -- we can start again with you, Steven, and maybe work that way a bit.

Yes, sounds good. Yes. So one of the things at DevRev, we got founded right around 5 years ago. And one of the key things is we really had a greenfield environment, right? So there was no legacy architecture, no brownfield that we had to deal with. And one of the key decisions there was really what do we use as the core for our data platform. We knew AI was going to be fundamental, hence, the .ai and the domain name. We knew there was going to be massive amounts of data as well as tons of unstructured data. And that's really where we went with MongoDB Atlas right off the go to really kind of be that core data platform for us that runs all our operational, transactional as well as analytical pieces. We leverage it not only for data transforming, but also things like search as well as vector search. So really kind of the core from a data platform perspective.

Awesome.

For us, it was basically a collection of support engineers. So Cisco Support TAC is a very common name in the industry. We had the issue where we ran lean and mean like most support organizations do. And we were concerned what happens when that big event comes down the pipeline, the Log4j a couple of years ago or some security issue, and we can't handle it all at once. So a very bright set of individuals got together, and we designed and implemented what we call now the Virtual TAC Engineer, or it's also called Cisco Support Assistant for -- Cisco Support Assistant for TAC, right? And basically, we had to have something to back it that could scale, that could make use of AI. And so we started with some other database provider, which I won't mention right now. And we ended up selling on Mongo, which helped us scale and make it grow quite large because if you think about support cases, while doing 10 or 20 cases is not a big deal, we started scaling into thousands and thousands and thousands of cases. That's a much bigger deal.

The company is called TinyFish. It's just a year old, and I'll start by explaining why the name. For the first time, as we move from AI to agents it's all about doing, like you said. Agents is when finally action happens. If LLM is the brain, think of agents as the arms and legs. For the first time, we think it is possible for us to actually focus on the smallest fish in the ocean, the marketing person, the supply chain person, the pricing specialist. CFOs can have the FP&A team to do the real job, but how do we make sure that this person with a lot of responsibility and very little resources can deliver value, right? That's where it is actually possible now between the brain and the limbs. And TinyFish is very specifically focused on the intersection of enterprise and browser actions. So the state-of-the-art right now is about browser agents, where a human sits and on behalf of the human, an action is performed by agents, right, like coding agents, customer support agents and others. We are cutting a little closer to the next phase of it, which is removing human and scaling browser action at a superhuman scale. Imagine 1 million browsers being spun up to deliver recent extremely complex nuanced interaction and extraction of data for very specific use cases. And browsers, websites in general, are very difficult to make sense because they're constantly evolving. So they're not a good fit for LLMs to simply solve. That's where we come in. And we use Voyage specifically because it is so vastly unstructured and so much hard to differentiate. We use Voyage across the board between embedding and reranking.

Awesome. We may stay with you. You answered a bit of that -- of my next question, but I want to ask specifically because you mentioned scale, the unstructured data, what does AI consume. But like there are many solutions out there, so what makes you choose to work with MongoDB, if you could dive a bit deeper on that?

So to explain that I have to explain why this is a hard problem. 60% of an enterprise knowledge workers' time is spent on browsers, doing 3 things. They're doing deep research. They're doing interaction, entering information. And the third step is extracting data. And all of this needs to be extremely disciplined. It has to be deterministic. And websites in general, are nondeterministic. So how do you make deterministic things out of nondeterministic action that's out there at massive scale? So scale comes to play, which means that accuracy and performance matter. And that's why we tried everything as well. The company is a year old, so we had the luxury of going and looking at everything new. And we started going with very specific use cases. The first use case for retail, e-commerce, banking and others is, I have a product, I want to know a similar product. It's called product matching. And product matching is a hard problem because if I'm selling, let's say, an iPhone case, the first thing as a pricing specialist, I need to figure out is how many similar products exist in the world. And as you can imagine, it could be visually, it could be deterministically to figure out what it is you need to look at it. You need to read documents, you need to wait, sometimes, look at the specifications. This is such a complex problem. So we use 3.5 -- voyage-3.5 embedding to collect the -- like where is the location. I think it's a much better story than your crime story.

It's better, yes.

You're saying embedding to grab a bunch of people and then rerank and find the culprit, is not a good idea?

Still yours...

In my case, you can actually bring the entire catalog of your competition, [ embed ] them. And then we obviously have to rerank because -- think of this, for example, I'm going to Disneyland, and there is a package that I sell where you pick up from the hotel, no blackout dates, and it actually provides meals. How do I compare that product against something he's selling where there are blackout dates? These are the kind of things at scale, it's a hard problem. So rerank too comes into play for us, 2.5, where we are now able to identify that one product. Then we can use our logic to find out all the pricing and the promos and all of those sort of things. And what made this tick out are 2 things. Number one is it's very accurate. The accuracy matters to us. False flocks are extremely difficult in our case. So we do that. Number two, the Python APIs are phenomenally lightweight and fast.

Awesome. Thank you, Sudheesh. Sean, you also mentioned some of it, but your story is interesting with MongoDB.

Yes. For scale with us, like I said, it started with just doing a couple of cases here and there, it's kind of a POC in nature. But as it got caught wind [ and inside TAC ], people more wanted to use it. And we started scaling and scaling and scaling to now that we're -- the virtual engineer owns about 3,000 cases of its own, collaborates on another 50,000 to 100,000 cases a year -- or excuse me, a day. And in December, we just crossed 1 million cases worked by that. So that scale is just growing and growing and growing. What we found was that the relational database couldn't handle that kind of input and throughput. And so [ we're ] going to Mongo, we not only were able to grow that piece out, but we started to build APIs for the engineer and grow those out and all of those backed by Mongo. And it wasn't just a scale of the database. It was a scale of every component. Working in Atlas was great for us because I can have the virtual engineer running on its platform, and I don't have to worry about does it need to go up a couple of compute nodes, or does the database need to scale whatever. It's all taken care of. So for us, we can really focus then on improving the engineer experience, which at the end of the day, improves the customer experience for Cisco versus having to worry about, okay, is my database running or is my compute running or whatever? It was a better experience for everybody overall.

Awesome. Thank you. Steven?

Yes. I guess last but not least, so I think one of the key things is when we think about what we were trying to do at DevRev, right, it was really very similar to what an ERP did for supply chain back in the day. It really took 4 disjoint tools or all these multiple tools and really kind of consolidated them driving efficiency through centralization. And if you look at what we're trying to do, it's really taking a CRM tool, a ticketing tool, a work management tool, a service supply chain tool or a service catalog tool would be it. And given the amount of all the data throughout all those tools, if we consolidate all that, we have a very large scale problem. And if you extrapolate that over the sheer number of customers that we have today as well as want to have in the future, you get very, very staggering amounts of data as well as the fact that all customers' data structures are different. They don't all run on the same tools or same platforms. And so from a scalability perspective, we needed extremely massive scale, the ability to start small and incrementally scale there as well as have very flexible data structures that we could leverage, right? And so that was really kind of one of the key underpinnings that really led us to Mongo and Atlas specifically is we got all that out of the box, right? We got a scalable platform. Back in the day, it was one person. It was me who was setting this up and architecting it. And so it was -- it all came for free. And that's one of the key things. We get massive scalability, tons of flexibility. Plus, I think one of the other key things is if you look at like an Oracle or an MS SQL or MySQL, these things are literally 25-plus years old. And so am I going to place a bet on these technologies that were developed literally before the Internet evolved? Absolutely not. I want something that is innovative, something that's scalable and something that is really pushing the boundaries of the future. And that's really what I think Mongo is doing as well with Atlas.

Yes, that's awesome. Thank you for that. We may stay with you. What's amazing is that's totally on point with the 2 products, and you have been through the full journey, and you are well past that, like scaling, integrating billions of pages to growth. Can you maybe share something you have learned and that could be useful for others?

Yes. I mean I would say like there's a -- in hindsight, there's definitely a lot of retrospect. The biggest thing is you don't know what you don't know, right? And so even when we first got started, we had an idea about our -- ideas and what the model would look like and our scalability and all these things. But realistically, we had no idea what it was really going to be in reality, right? And so that's where I would say don't over-rotate and overpivot on overprescription or over definition of things because realistically, you have to be agile, you have to be flexible, especially if you look at how quickly the era of AI and LLMs and all these models are rapidly changing. One, you have to be very nimble because if it takes you 6 months to integrate with these things, or if you don't have a platform which natively gives you these capabilities, you're really going to be left in the dust. The other piece is, unless you have that flexibility or the ability to rapidly change, it makes things very, very clunky, very [ klugy ]. And so you have to be flexible. You have to embrace change. You have to embrace the fact that you don't know what you don't know. And it's kind of a scary thing, but it's also kind of an enabling thing. If you kind of can embrace that and accept it, I think it's actually a very empowering thing because it gives you that ability to really kind of keep up with the rate of change here.

Awesome. Great story. Thank you. Thank you, Shaun?

I would kind of go and echo on the flexibility, and I'll add to it. For us, when we first built the virtual engineer, the fact that you'd have to go in and totally pull out a database table and redo it because I wanted to add a new feature or add new storage, that was pretty poor, right? And it just caused us more dev cycles. So going to Mongo, we could always -- we could build out our APIs, and we could really add additional fields, features on the fly pretty fast. I think for us, that was huge, again, the scale thing was the biggest thing we combated. For me personally, as that scale grew out, I remember I rewrote one of our core services probably about once a year, and we've had it running for about 5 years. I've written it like 5 times. I have to have good infrastructure below to deal with that flexibility and to handle that. I think the thing that I have to add on top of the flexibility is I think you have to have a great team with a singular good vision on that irregardless of what infrastructure you have. And I think that is something that the virtual engineer team we really had -- everybody was focused on solving Cisco's customer problems, right? And that was really a pinpoint goal for us.

Awesome.

The dictionary did say irregardless is a real word, but I still protest. They talked about 2 important things, scale and flexibility. I'll say something a little different. We are -- just a company is very new. Most of what we are doing was not possible until early February this year when reasoning got better. So my point here is that we are living in a world where AI is also highly hyped. So enterprise customers are looking to see where is the real value and how much risk can they tolerate because they can't stand on the sidelines. So they need to figure out, like, what's the worst thing that happened if this product didn't work or if this company stops being. So you got to find use cases that are high value, low risk. And that's why we have been very intentional about moving fast without breaking things. So the specific thing that I'll point out is that we are underestimating brain and overestimating LLMs as of right now because, for example, it can solve international math Olympics problems. So most people can't. So they're like, "Okay. LLMs are better." But in general life, browsing is a very complex thing where we make decisions that we don't even think about. Just think about, for example, going to a movie, online booking. The decision process that your prefrontal cortex go through is like amazing. For example, you will be like, "I'm just going by myself. I don't mind if the seats are on the back, I'll just find something in the front. But now I'm going with my partner and my kids. I want to make sure the seats are next to each other, not going to be too far out." And then I don't find the right seats. "Okay, I'm going to have dinner and then watch a movie later, let me find a 9:00 show." So all of those decisions are made without even thinking. This is the power and complexity and nuance of browsing. Every decision we make, a hotel decision, a checkout decision, a pricing decision, apply the promo, save the money, which, where to buy, all of these decisions, we don't even think because our brain is abstracting all the complexity. So when you're trying to build all of that, no one knows where this industry is going, how far. So my requirement when I think about who to work with is, are they going to be an innovation partner or not? Are they going to force new changes to happen in the industry? And as we started talking to others, the thing, like all the way, the founder of Voyage AI, he was actually meeting with us. He's in Stanford in Bay Area. The team is very reactive. We have never had a problem where -- like we are in the cutting-edge research. But the problem -- the difference between research and engineering is that there is a deadline. So if you're just researching without a deadline, doesn't work. And for us, the fact that the product is good, it is fast, it is efficient, that's all good, but they are actually working and innovating with us. And that's another thing that you have to really think about in this high-frequency thing that you talked about.

By the way, I talked with you like a few weeks ago. I told Audrey, your product specialist, about your feedback, and you made our day.

Yes, Audrey was the one who made us decide like, okay, we'll work with [ Audrey ]. Okay. She happens to be at Voyage AI.

We only have one, Audrey, but like we have other folks that are great. Awesome. No, that's great. I mean there's a lot of good pieces of advice and hard learned lesson, et cetera. Let's reflect, if we could step back more, looking down the road and maybe we can even step back from your specific business, like when you look at AI, where it could go, the shift that you anticipate, if you have some thoughts that you would like to share with us. Steven?

Sure. Yes. I mean, so I think this is definitely like a very pontification question. And I kind of had some hindsight and some reflection on this as well. But I think one of the things that's been very clear to me is kind of this over rotation on hyper-personalization, right? And so if I think about Amazon or if I think about when I go to Google or when I go anywhere, everything is specifically targeted towards me. And I want that. People have grown to kind of embrace that and kind of expect it almost. And so that's why I think when it comes to how we interact with companies, how we interact with people, how we interact with advertisements, with platforms, I think there's going to be this huge focus on hyper-personalization just because that's what people have grown to kind of come to expect. Whether or not it's good or bad, I think there's positive and negative aspects to this, but I think that's what people want. When I go to americanairlines.com and it says, "Hey, what's your name?" I don't want to have to answer what's my name. I want it to know all that context about me. And I think that's where having data and all the context for these models is very critical, as well as having the ability to uniquely identify an individual, right, based upon certain traits or characteristics. And this is where the identification piece can become semi-complex, because in an area of billions of user IDs or cookies or sessions, especially with cookies being phased out, how do I uniquely identify that individual or that user? And it's not just a cookie, it's a person, right? And so how you, one, uniquely identify that person or individual is key, but then also how do you over hyper-personalize that as well. I think that's very important. I think the one last thing, too, just to kind of add on that, and I think there's 2 quotes that I would like to quote here that I think are very important, especially in this age of shift, because I think personally, AI is probably going to be more fundamental and more foundational than even the birth of the Internet, right? I think it's going to be revolutionary, more transitional and have more impact than that. But I think there's 2 quotes that I really like here. "The measure of intelligence is the ability to change", which is a quote by Albert Einstein. I think that's a very, very applicable quote here. And then the second quote is by JFK, which is, "Change is the law of life. And those who look only to the past or present are certain to miss the future". And so that's where, as product leaders, as companies, as builders, we have to semi let go of all the baggage of the past, right? We have to think about things differently and not really kind of be hindered there. So I think hyper-personalization, how we uniquely identify people, not traits, as well as how we kind of not let legacy bias impact us, I think those are key for sure.

I think for us, I think it really comes to the transition from when we started the coding, the engineer was transitioned from like text classifier, like Generation 1 type AI, right, to now it runs full generative AI. Now it's that next step, and you heard a little bit in the keynote today, it is talking more the Agentic flow, right? How many agents do we spun out there? If you look at Cisco products out there today, we've got agents that are running in product like XDR that are talking to a support agent, that are talking to a licensing agent, right? We're trying to build agents in all those areas to make the customer experience just something that's more seamless, right? And I think that next step and something that we're focusing on probably in the next couple of quarters is definitely going to be, even for our team, expanding to agent-to-agent communications and really ramping that up, especially as the SDKs come out for those different components and having Mongo back a lot of the agent work that we're doing.

Yes. For me, I think every 20 years or so, the Internet gets rebuilt. The first versions of it in the news groups to what Google and Facebook did, it has to evolve again. And what is that evolution going to look like? I think of it as outcome-driven Internet. Right now, in the last 10 years or so what happened is that you exist or not based on what Google tells you. Let's take back a second and think about why Internet. Internet was about discovery. It's about finding things that you care about. Obviously, it grew significantly bigger than human capability. And then a company like Google came in and said -- it's a great company. They came in and said, we are going to organize world's information. But what happened as part of this is, if you are not part of their index, you don't exist. And it's not because they are evil, it is that it's so massive that the only way to find will be to go through these, what I call, surveillance capitalist companies. They turn that surveillance capitalism in a way that if you don't exist in the first page in the blue link, you don't exist. So you may have the best service, but you'll never be found, you will never find the customers. Now as we move to the next phase of it, from SEO to GEO, as you don't even have patience, hotel links, you just want that one answer. And if the answer is what's the best green tea and your AI agent says or ChatGPT says, here's a green tea. What do you do, the rest of them? Your tea might be the best, but you are not optimizing for it. This has to change. There will be a change. We are not going to settle for this one answer that -- it's not even like I'm bidding for the top 10, I have to bid for the one. It doesn't work. For the first time, there is a potential light at the end of the tunnel where it could be rewired for outcomes. And if you go to our tinyfish.ai website, the story that we highlighted is Google Hotels, not because Google Hotels is the story. We told the story from a point of view of an 8-room hotel in Japan. This is a small hotel. They have 8 rooms. They don't have a sophisticated stack. Hotel prices are always dynamic. You don't know the price unless you execute a workflow. Our agents log into these complex websites multiple times a day, try to check out different hotels, find the prices and automatically update Google Hotel Meta. All of a sudden, their hotels, instead of saying call hotel, it will show the inventory and pricing. They didn't do a single thing. Google Hotel now has a lot more inventory. They're happy, and consumers have more choices. This is an example of identifying and doing things on behalf of humans, so that human actions and intent aspirations will become even more evident. Artificial intelligence is not just about artificial. We spent so much time thinking about artificial. It's also about intelligence for outcomes, for humans. I do think that the Internet has to evolve. We somehow sleep walk from this idea that Google, I don't have time, just tell me that one answer, we are going to significantly erode the value that it was created for. If I'm looking for and ethically source the best coffee from Nicaragua from a small family, it should be about the quality of the coffee and their ethics. It shouldn't be about how good they are in showing up in an answer that an AI chatbot is giving you. And it has to change. And we have to be part of making that change.

Terrific. Thank you, folks. You shared a lot already, mix of learnings and real stories and visions. Maybe before we transition to May, our Chief Marketing Officer, any closing thoughts you would like to share with the audience?

I mean, yes, I think in the last comments, I kind of hinted to some of these things. But I think the biggest thing is just embrace change, right? Embrace change changes here. It's not going to go away. And if we keep kind of fighting change, it's just going to, one, hurt ourselves, hurt our careers, and then also hurt the future. So I think embracing change is definitely key. I think one of the other things is also be proponents of the right types of change. So to the point about intent-based or getting the actual true results that you care about, I think that's so important, right? So as a user, we didn't go to search for wanting to go through things, we gained there for answers. If I search for coffee, I want the best coffee. I don't want the best branded or best marketed coffee, right? And I think those are so important things that we need to, one, fight for and then also hold people liable and responsible for these things, right? It's not about just making money of these things. It's about truly getting the right intent. And then, yes, I think the biggest thing is just embrace change. We don't know, we don't know. It's the wild West out there. Things are changing more rapidly than I've ever seen things change before. And it's an exciting time, just embrace it and go along for the ride. So...

Yes. I think for us, it's about just factoring into the daily routine, right, making sure that the folks know that it's more about making them operationally more efficient, right? So we can produce more code, better code, faster speeds. We're still solving very complex problems, and we're not going to stop that. Tech is not going to -- we're not going to get rid of people because we're going to have AI agents answering all the questions, because there's still going to be bugs that appear. There's still going to be things that happen that are caused down the road, right? So we're still going to have all that need for human engagement. I think that's a big thing. The other thing is to get our people trained appropriately on being able to do really good like prompt engineering, things like that, so they make proper use of the tools before them. They just keep remembering their tools. They're not taking over things.

I'm just grateful. I think what a time to be alive. Imagine if we were alive when industrial revolution started and steam engines were invented. Cisco, for example, they made Bay Area, essentially. If you go anywhere in San Jose, you'll see how -- if you were a part of that journey at that time. We don't have to wish that because we are actually in it. These are the good old days, and we are living in it. And it is hard to overexplain how lucky we are to be able to be in the middle of it. No matter what role you're in this room means you are lucky. So for me, it is like don't stand on the sidelines, like Steven said, but it's also more about there is actual value that you can deliver for yourself and your clients. Go to tinyfish.ai. I have to pitch.

Classic Sudheesh.

He knows me. We are getting started. We don't know the actual use cases, but you're using browsers, do it at super-human scale, with reasoning, do amazing things for yourself and your clients and be part of it. There is -- amazing things are happening everywhere. And like you said, change, change everything, change your job, join us.

Shameless.

Listen, thanks a lot for being our customers first. Thanks for sharing your insights today, and I really appreciate it. Thanks.

Thanks.

Thank you.

Thank you.

And we transition to May. May, the floor is yours, I think.

All right. Hi. When the CEO of TinyFish was talking, I felt a little seen. Anyway, welcome. 3.5 years ago, I joined MongoDB, and I was given the challenge, make Self-Serve the most efficient acquisition for MongoDB and do it in 3 years. Classic big hairy audacious goal. Today, I stand before you as MongoDB's new CMO, proud to say we did just that. Self-Serve is not only our most efficient acquisition channel, it's also the catalyst for our enterprise business. Let's step back for a moment. Product-led growth is our strategy. Self-Serve is how we animate and bring it to life. The idea is simple. We don't just tell developers, we show them and let them discover how great Atlas is for themselves. It's more than a free trial. We work to make every developer wildly successful in Atlas. That's how we design every interaction with empathy, not just showing utility, but helping them succeed. That's what drives adoption, strengthens retention and ultimately drives durable growth. At MongoDB, Self-Serve takes the barriers down to almost 0, a simple sign-up, no upfront commitment and a free tier that never expires. It's the freedom to get started right away. And it's not just small projects. That same Self-Serve journey makes our sales motion more efficient, because when we talk to customers, they're already building, running workloads and even spending with us. And these are not trivial projects. They're content management systems, e-commerce catalogs, transaction-heavy applications, the kinds of workloads that power modern businesses. Hundreds of thousands of users try MongoDB via Self-Serve every quarter. And here's the key. 80% of those developers have self-identified themselves as being new to MongoDB. I'll say that again. 80% of those developers identify themselves as being new to MongoDB. That makes Self-Serve our most important way to win the hearts and minds of the broader developer community, especially those moving beyond relational technologies and looking for a modern alternative. We're also seeing AI native start-ups choose this path to build the foundation for the next generation of applications of MongoDB. Together, these signals give us confidence that Self-Serve is a compounding engine driving growth that accelerates over time. Our Self-Serve motion has proven highly effective even as our go-to-market teams move upmarket to large enterprises. As usage grows through Self-Serve, so does revenue. Developers scale projects at their own pace, paying as they consume. In just 6 years. Self-Serve has grown to more than 50,000 customers. Year-over-year, we've more than doubled the number of net adds to our Self-Serve channel from 1,300 in Q2 FY '25 to more than 3,000 last quarter. Some of those customers are supported entirely digitally. Some are engaged by our scaled go-to-market team. But whether they're engaged digitally or by our sales team, Self-Serve is the front door to durable, efficient growth, the place where the journey starts and where enterprise growth begins. Now product-led growth isn't just an efficient way to bring SMB users in. It's a powerful driver for enterprise growth. Many start small, some as little as $8 a month, but more than 25% of our $1 million and up customers began in Self-Serve. And when they reach the $15 million mark, they get there about 15% faster than customers who came through traditional sales channels. Why? Because by the time sales engages, the developers have built, tested and gone to production on Atlas, they know it works. And that only makes it easier to scale across workloads, teams and business units. It also makes customers stickier because developers have invested in the platform and have learned and are succeeding on it. Now, at MongoDB, we never slow down and stop and rest on our laurels. So the next bar is how to make MongoDB the default database for modern applications. Here, you see the classic funnel, starts with mindshare being top of mind for developers, architects, decision-makers when they think of evaluating modern data platforms. Then we move to education, to grow confidence and competence, and that leads to preference selection and ultimately growth. Education happens in person, like today at the .local event, and in the product at scale with a low-friction experience that gets developers up and running fast. Prompts, docs and content then guide them forward until they convert into paying customers. And the journey never stands still. We're constantly testing, refining and improving. But what moves prospects from the top of the funnel down to the bottom and then looping up again is the Self-Serve engine. So let's take a look at it. Self-Serve works in 3 powerful ways: acquisition, learning and sales acceleration. First, acquisition. Let's meet developers where they are and get them to try Atlas. Second, learning. Every new user creates signals and feedback that makes the product better and the journey smoother. Finally, sales acceleration, turning early adoption into warm demand for our enterprise teams. That's why this engine is so strategic, but let's look at acquisition. There isn't a single path to MongoDB. Developers discover us through multiple doorways, each designed to be natural, frictionless and scalable. FirstSearch, just heard about that. For years, growth has started with a simple question. What's the best database for my SaaS app? And MongoDB has consistently shown up as the answer. Now, second, AI. This is our fastest on-ramp to Self-Serve. LLMs already drive 10% of our Atlas registration, and they convert better than any other channel. In fact, one of our top prompts fueling that growth is simple. What's the best database for flexible data modeling. But we're not leaving it to chance. We're making sure that momentum is turned into durable impact by focusing on 3 things: one, quality and accuracy of the answers; two, visibility in the right places; and three, insights into how we show up across the AI landscape. That's why we've tuned our website to be AI-ready, invested in third-party content and forms like Reddit and Stack Overflow and built analytics to track where MongoDB shows up and where to double down. Content, accuracy and insight. That's how we're going to win in AI and why LLMs are now our best converting source of traffic. Third, community. Nothing beats word of mouth. From open source adoption to .local to developer champions, our community brings hundreds and thousands of developers to MongoDB. Finally, ecosystem. Partnerships like the launch in the Vercel marketplace last week put MongoDB right where developers built. With just a few clicks, they can provision Atlas without leaving their workflow. Together, these on-ramps fuel Self-Serve, making MongoDB discoverable, accessible and top of mind for the next wave of developers. Learning. Now we don't just bring people in the door. Self-Serve, the Self-Serve engine teaches us and lets us teach users. Every click, every query and piece of feedback is a signal. At our scale, those signals give us visibility you just can't get any other way. We also pair that with -- we pair quantitative with qualitative inputs like surveys, focus groups and customer conversations. This gives us a complete picture we can use to improve the product and the journey. We see which features take off, where developers get stuck, and when a workload shifts from test to business critical. These insights tell us when to act. Sometimes it means fixing inefficiencies like slow queries or improving our alerting. Other times it's seeing when customers are pushing the database where it's just not ideal. At our scale, we can spot patterns automatically and guide users to the right solution. Sometimes that's search, Vector Search or Voyage AI. Other times it's helping them unlock what's already there. Either way, it's just not about fixing problems, it's about expanding usage and driving adoption, again, helping developers be wildly successful on Atlas. Developers also share feedback in docs, chatbots and community forms. And combined with usage data and product telemetry, those signals fuel a disciplined loop. I know Dev talks a lot about experimentation, and this is how we do it. We form hypotheses, test them, learn them and scale what works. So each cohort benefits from those before it. And the more developers use MongoDB, the more we learn and the more better we make it for the next cohort that comes through. That discipline is what drives and makes Self-Serve stronger every cycle. It's not just a revenue engine, it's also a learning engine for MongoDB. Last but not least, sales acceleration. Self-Serve also fuels our enterprise motion. It's pretty simple, land, signal, expand, retain. We land a developer through Self-Serve. The usage generates a signal of high-value, super engaged accounts, and those signals alert our sales teams. From there, we grow MongoDB usage across the organization. That turns cold calls into warm conversations powered by real customer data. The impact is clear, higher conversations, higher conversion rates, stronger ROI and a more efficient sales process. It's how we've already won over 70% of the Fortune 500 and how we're capturing the next wave of AI application development. These are one-offs. They prove Self-Serve is repeatable, reliable for enterprise growth. And here's the important point, well, one of my many. Developers often can't say yes to a purchase, but they can say no. By landing developers first, we reduce friction, build advocacy and make it easier for sales to get to a yes. Now let me show you how it plays out in real life. These stories span financial services, cybersecurity, crypto, design, goes on. And they all follow the same pattern. They all started in Self-Serve. One example, a global cryptocurrency exchange began with a single developer signing up. Usage grew quickly, and that one account led to Atlas becoming the preferred operational database for all of their applications. When sales engage, it wasn't a cold pitch, it was more in an advisory position, helping them to scale mission-critical systems. And that pattern repeats. At a Fortune 500 brokerage firm, developers experimented in Self-Serve before moving to sales. Today, MongoDB powers the application that supports millions of retail investors. At a global design and collaboration platform, developers started in Self-Serve and when usage scales, sales engage. And today, MongoDB supports hundreds of millions of monthly active users on their mission-critical application. That's the playbook, land, signal, expand, retain. It's how Self-Serve fuels our engine, driving acquisition, learning and sales acceleration. That's how MongoDB goes from first choice to every choice. So again, when I joined MongoDB 3 years ago, thrown down the challenge, make Self-Serve our most efficient channel. And today, I'm proud to say we did just that. But more importantly, the best is yet to be. We're still learning how to optimize for LLMs and how to become an essential tool within Agentic development platforms, and this engine keeps getting stronger, acquiring our next best customer more efficiently, feeding intelligence to our go-to-market teams and creating durable growth that compounds year-over-year. The impact of Self-Serve goes beyond the channel. As we get better at acquiring and supporting customers digitally, it frees sales to move upmarket and land those large accounts for us. That's why I'm so confident in where we're headed. And the truth is, we're just getting started. Thank you.

Thank you, May. Okay. So hey, thanks for staying with us. We're getting down to the -- we're starting now sixth, seventh inning, getting to the end. So I'm going to walk you through the financial update. We will talk at the end about some of our financial -- I'm going to call it our foundational elements as we look at the long-term plan. And then also, we will open it up to Q&A. We probably -- and thank you for the team for being so crisp, we'll have maybe a little bit more time for Q&A. So just before I get started, though, so hopefully, you enjoyed those sessions. If I could, just from my perspective, recap what you heard. Hey, Dev talked about durable, profitable growth. I thought it was super important that he walks you through, here's the evolution of MongoDB as well as our fundamental advantage, which is our document model and how we go to market. So I thought that was great. Jim and Fred, I thought they did a great job talking about 2 things. One is the product enhancements in the core product, and that's so important. That QE, the encryption thing, when they walked me through, I was like, wow, that's really neat. Super important to a developer. All the stuff that Jim talked about in terms of security, availability, all of those things, if you're a bank or you're a government agency, that's really important. That has allowed us to move upmarket. And then Fred's discussion, hopefully, that helped. We get a lot of questions from you folks. Hey, what is an AI use case? What does that really mean? And hopefully, that helped that as well. And May, who I love as a CMO, she says ROI more than I do, which is an unusual thing. That whole product-led Self-Serve has also enabled us to move upmarket, but make sure we don't lose what MongoDB is, which is really that mid-market as well. So thank you for that. Now my job is to pull it all together and walk you through the financial framework. So what are you going to hear from me today? We're going to hit -- and I get a lot of questions. Hey, when you joined Mongo, why? And what did you look at? The #1 thing for me, and folks, I've been in a lot of different places. It's one of the few places I've been that has such a large market with great organic growth. That's where it all starts. It's painful to be in a market that doesn't have a lot of growth. It's not very big. It's a dog-eat-dog world. Is there competition? Absolutely. But it's a huge market, lots of room for growth, so we're going to hit that. The thing that I've come to appreciate probably more than anything is the durable business model. And I didn't appreciate that until I got here. And it's one of the great things I love about software is the business model and how it drives profit. That flywheel impact is super important, and we're going to talk about that. We believe we can do both, grow revenue and profit. And folks, I get a lot of these questions, and I think it's a little bit of skepticism, which is, please tell me you're not going to sacrifice growth for profit. So this is being webcast. We will always lean towards growth versus profitability, but investment needs to come with a return, okay? So when we talk about the growth, that is the #1 goal. But we also, because of the flywheel, are very confident that we can do both, and we're going to talk about that. And then I will talk about our long-term targets. Okay. Before we get started, though, we had a really good Q2. So let's -- this is a little bit of a victory lap, which is fine. We're going to take that time. The guy from TinyFish gave his little advertisement. I'm going to do the same thing. So hey, Q2 and for the 5,600 employees at Mongo, I would say, thank you for the great performance. Here's how I would summarize it. Accelerating Atlas growth, stability in non-Atlas, another strong quarter of customer adds, expanding operating margins and meaningful cash flow. Checked all the boxes in Q2. And as you know, we not only rolled the beat, but we raised the guide across the board. So we feel really good about how it set us up for the rest of the year. I would also note a couple of things. 18% revenue growth at the high end, 14% operating margin. And yes, folks, like everybody else, we will talk about the Rule of 40. We used to be a Rule of 40 company. And gosh, darn, we want to get back to that. So we're at 32%. Hopefully, that number keeps going up, and we're going to talk about our goals to get there. Okay. Before we do that, let's talk about the market. Same chart that Dev showed, but we can't show it enough. Large growing market. The database market is obviously made up of OLTP as well as OLAP. We play mostly in, as we know, the data store, the OLTP. You heard today, that is where all the action is in AI. That's the high ground for inference. That's where we play. But you know what, the rest of it is there for us if we want to look at future expansion. So it's a huge market, and it's growing, as our friends at IDC say, by about 13%. Hard to find a $100 billion market, growing that fast. So it's a great market for us, and there's a lot of room for growth. No matter how you cut it, we've got a very small share. So even at our guidance, about somewhere around $2.4 billion, folks, we don't have much of the market at all. There is a lot of room to run, and we're super excited about that opportunity. There's green on the chart. There's lots of greenfield in the market. The other thing is, we have immense respect for the folks at IDC. I would not want to have their job trying to estimate market size and growth. But we also are firm believers. We believe that AI is actually going to accelerate that growth. The question is when? And while we don't have a view on that yet and you ask every quarter and you should ask, we do think that AI will expand the growth of that market even above the current market estimates. Okay. And we talked about it. Hey, OLTP, and we have a lot of these questions in the investor meetings in the one-on-one, which is, hey, why can't the other part of the market do it? That's where the operational data store is. That's where the real-time data is. You heard all the customers talk today about you want that vector search and that embedding right next to where you have the data. We think that, that is the high ground for AI workloads, specifically inference. So in summary, folks, it's a massive market. Few companies have that large of an opportunity. With only $2 billion -- around $2.5 billion in revenue, we have a very small piece of that. The opportunity in our core database is still very large. The market is expected to grow double digits, and we think it's actually going to accelerate with AI. Question is when, but we think it's there in the future. Okay. So that's the market backdrop. Now let's shift to Mongo. Okay. So I'm going to take a little bit of time on this slide. And one of the other things I know you always like and expect from Investor Day is, hey, give us some new metrics, give us some new data. You heard some from Dev, you heard some from May as well as from Jim and Fred. If you take a look at this, this is total revenue. We've broken it up between Atlas and non-Atlas and services. In fiscal '22, Atlas was about 56% of the business. We expect it to be close to 74%, 75% now. Interestingly enough, the last 3 years, Atlas has added about 400 basis points in mix for the last 3 years. One of the wonderful things about AI is we're not -- hey, we think it will be both form factors. We think it will help Atlas, but we also know it will help EA as well. So that mix, we expect Atlas to continue to grow. I'm not sure it will be 400 basis points. We'll see how it goes. The other thing is, and we've grayed out that area there because that's the guidance. We gave you very specific views of what we thought the second half was going to look like for Atlas. So it grew by, call it, 28% in the first half, somewhere in the mid-20s is the guide. We also get questions about, hey, how does that break out between the different cloud platforms? And we've said before, so number one, all 3 platforms on a year-to-date basis are growing very strong double digits across the board for all 3. That largely reflects the cloud market share that you see in other publications, but AWS is our longest relationship, so they're going to be a little bit bigger. But it largely reflects the cloud marketplace. So we do get that question quite a bit. So 3x growth, but Atlas has grown almost 4x during that time. So it continues to take share, and we do expect Atlas will be the driver of growth going forward. Okay. So I'm going to leave this up for a second, because I know you folks love this chart. I've been here a little over 100 days. I kind of like it. There's parts of it I don't love. This is how we measure the growth of Atlas, which is our week-over-week average consumption. And again, we're going to post this one. So we look week-over-week, and that's how we track it. Now what this is, is this is consumption growth. And you can see in here that there's variabilities throughout, as we call it, the seasonality. Some of it holds. There's been some changes. Economic things happen. External factors happen that change some of this. But we get a lot of questions from you folks on, hey, you say you're going to have consistent growth in Atlas, what does that mean? So what you need to do is take this chart and compare it also with the size of Atlas, and I'm going to talk about that to get to revenue. So what we mean by that is you see that line on the far right. On average, the week-over-week consumption for Atlas in the first half was relatively consistent with the first half of last year. The fact that Atlas is almost 30% bigger means that you get acceleration in revenue growth. So when we say relatively consistent consumption growth, we're not talking about relatively consistent growth. That's consumption. Consumption is a leading indicator. You then need to compare it against the size of Atlas, and that's going to take you to revenue. So we know you folks love that, and you ask about how was consumption in the quarter. This is how we answer the question, which is how did we see the week over week. The other nuance here is, hey, you do have some seasonality and variations that we bake into our forecast based on what time of the year it is, summer, holidays and other things. So it's not a perfect proxy, but it does give us a view of the growth. So I know we showed this last year. I know you hate when I pull stuff, so I'm not going to pull it. But I want to make sure we get a lot of questions about how does this then relate to revenue. So I like this chart, but I love this one. So this is the growth in Atlas revenue year-over-year. And you can see for the first -- for the last 2 fiscal years for the half, we did it by half, we added about $150 million of Atlas revenue on an annual basis. That was relatively flat. The great news is, with relatively consistent consumption, but a bigger base, it actually accelerated in the first half. This is what I think we get paid to do, drive more incremental Atlas revenue every quarter on a year-over-year basis. Percentages are important, dollars pay the bills. So this is something that we will show you and talk about a lot. So when you ask about consumption, I'm always going to give you the view, but I'm always going to bring it back to revenue, because that's what matters. Now in our guidance for the second half, we've largely assumed a relatively consistent absolute growth as well. So we expect this growth to continue. And that is our goal every quarter, is to drive more and more Atlas revenue driven by consumption, okay? So I wanted to tie consumption to revenue, okay? All right. Let's shift to non-Atlas. Why is this important? You heard it today from some of the customers, and we've talked about it. EA complements Atlas. It's really a big part of our run anywhere strategy. And there's a lot of industries as well that need to run both on-prem as well as in the cloud. We talked about all the -- you can run across multiple clouds, which is great. EA continues to be a growth driver. Yes, it started to slow a little bit as it relates to that. This is revenue. So you're going to get the duration. I'll say multiyear once. What I'm going to talk about is duration versus that. But it continues to be a big part of our business, and it's hugely important for our customers, especially in regulated industries. Plus keep in mind, the margins here are quite good. It drives a lot of the profitability of the business, which is important. The other thing is this is not a cash cow. We are not pulling resources and just letting it run. You heard today, we talked about the investments that we're making in EA and introducing search and vector search as well. So again, run anywhere is a strategic advantage. Especially for regulated industries, it's super important. We are still actively investing in non-Atlas or EA, and you heard some of the announcements that we've made today. The other thing I do want to note, this is revenue. Hey, folks, about 70% of this is support, right? The license is a part of it, but also the stability of this revenue stream comes from there's still a good piece of it that's support. So yes, there's variability within part of it, but not all of it. And you see that, and you've all asked this question. So here is the non-Atlas ARR growth rate. And yes, we gave you the past. So just going to let you stare at it for a second. The bump that you see in Q2 '24 was the OEM deal that we talked about back then. Otherwise, this is going to largely reflect what you saw in the revenue screen, which is that ARR growth rate has come down, and you saw the revenue also start to plateau as well. Importantly, the last 2 quarters, it's largely been consistent at about 7%. And going forward, what we'd say is we expect that to stay within the low-to mid-single digits for the foreseeable future. We'll see how we get in a couple of years. But as we look out for the rest of this year and '27, that would be the expectation with obviously some movement based on the duration that we'll get with our customers. Okay. All right. A couple on the customer and the customer growth. This is a great chart, and it shows that we continue to add customers above $100,000 in ARR and $1 million. Keep in mind, though, and we've got a couple of questions about, hey, the customer growth slowed. While this is an important metric, with the move up market, we still want to add customers, but the goal is to really go after the wallet share in those larger customers. So if you look at it over the last, call it, 3.5 years, we've continued to increase the average revenue in this cohort. And this is really important, because it shows our biggest customers continue to invest in Mongo. They don't just flatten out. While the workload may start to flatten out, they're adding more workloads, more business with us. So this is a big piece, and we watch this very closely as it relates to the success of our move upmarket. So yes, larger customers adds are important, but we also want to increase that wallet share of those larger customers. Okay. So that's the Mongo business. We walked through Atlas, non-Atlas. We talked about the customer metrics. Now let's talk about investments to drive growth. And I've said this repeatedly, and I'll say it again, the #1 driver of operating margin expansion, this is a great part about the business model, will come from growth. This is the flywheel. The more that we're able to grow revenue, call it, gross margin somewhere around the mid-70s, it creates a ton of profitability for us to invest in. And versus the last couple of places I've been, folks, this is a great problem to have, because this is now about where you invest to drive return versus having to pull dollars from other groups. So this is why it is so important for us to continue to invest in the business to drive the revenue, because this is the flywheel, this is the biggest driver of gross margin expansion. So I know some of you are worried you're going to pull back too far in the oak. No, we're not. We'll talk about that. The goal is to continue to drive revenue. That is going to drive more operating profit for us to invest. The overarching philosophy you'll hear from me is we will continue to invest in the business, but not at the same rate of revenue. And that's how we will drive operating margins up. We will invest, and I'm going to walk you through that, but just lower than revenue and lower than gross profit. Okay. Entering fiscal '26, Dev and the team talked about the investment to go grab the unique opportunity. Those are still there. We are still investing in those. We'll talk a little bit about other stuff we're doing. The #1 thing is around developer awareness. And this is why what May is doing in product-led growth and Self-Service is so important. This is where it all starts. Mongo was started to make life simple for the developer and our developer awareness is huge. So the areas that we're focused on, and you see it out here when you walk around, is all the hands-on workshops, making sure that they know the value that we bring and how they get used to and work with Mongo. What I heard today from a lot of those customers was simple, but yet scalable. Wow, that's really great, because usually, it's a big scalable, but it's not simple. Hey, we're simple and scalable. So that developer awareness is super important. Hands on keyboard and a lot of the stuff that we do with them is at all the badging that they do. At this local event by itself, we're hosting 5 of them just today. So the focus on the marketing is really 3 things. One is a reinvigoration of our Bay Area activities, specifically related to AI natives, and you had one up here in TinyFish, and attending the developer talks to really raise our level of awareness in the Bay Area in the AI natives. Number two is to go after relational developers. That's obviously a big piece, so that they know who Mongo is and how to use it. And then the other thing is upskilling those developers, so that they know how to use Mongo. So a big part of it -- I'll talk about reallocation later. The small restructuring we did in Q2, we took dollars from one bucket and we moved it over here, and this is where we invested. So that will be #1 in the investment, and it's very similar to what Dev talked about entering the year. The other area is research and development. Hey folks, as the CFO, I think there's only one thing that matters in a tech company, which is you have to have the best product. And we will continue to give resources around 2 areas, focusing on the core product, all the stability, security, to move upmarket, hugely important, things like QE, AMP, all that stuff, we will continue to invest in the core product. And then, of course, all the AI enhancements that we need to make sure that we are moving with a very fast market. That's what you heard today is, hey, the market is moving very quickly. So these are 2 areas we will continue to invest in. Of all the 3 groups, sales and marketing, R&D and G&A, this is the one where you should see costs may come down as a percent of revenue, but not as fast as the other ones. We need to continue to invest here, and we will. And then certainly, sales is a big part of it. This is probably going to be focused more on, I would call it, incremental investments, but I want to lay out some of the areas because we'll still do this. You still need direct reps, especially as we move upmarket, and that's a little bit of a different skill set. So we'll continue to invest in that. We will continue to invest in the product-led growth that May just walked you through. It was interesting. I didn't get it the first round, but after earnings, this forward-deployed engineer came up more than a couple of times. And this is especially important as it relates to our AMP product, because it is a combination of technology and "services", specifically around really strong technical talent. So that will be a focus. Also our partner ecosystem. It's not only going deeper with our existing SIs, but it's also making sure that we're really in the SI slip stream as it relates to AI. And then there are some areas across the world that we probably need a little bit better partner penetration in certain geos. So we'll have targeted investments there. And then we are, like everybody else, investing in AI and tools to make this team more efficient. It's a little bit longer play, but there is an investment there. So developer awareness, R&D and engineering and targeted focus in sales, okay? So that's where the investment focus is going forward. All that being said, we can also run our business more efficiently. And I get a lot of questions about where are you going to target? So I've broken this chart up into what I'm going to call business model efficiency and focus around specific areas. And these are the first 2. And again, I'm going to hit this time and time and time again. Revenue growth drives gross profit. That's the #1 driver of growth. We are also now over a $2 billion business. Across all of our functions, we can also leverage that scale. This goes to cost of goods sold with our negotiations. It goes to how we run the whole company. Scale is actually going to start to matter and help us run the business more efficiently. Now let's talk about specific areas. And I talked about this a little bit on the last call. One of the great things about Mongo is we've largely built the infrastructure to be a worldwide large software company. We're in every geo virtually in the world. We have direct sales, we have channel sales. We have the 2-tier distribution. We have R&D and engineering across all of our products, and we have a G&A team that can support a large public company. The benefit of that is most of the new investment is going to be incrementally not a step function. So we can add new direct reps. We can add new engineers. Obviously, we need lawyers and accountants and other things, but these are going to be incremental. Therefore, we're able to invest at a lower level than our revenue growth. So that's the big piece from a structural perspective. Reallocation is going to be a big piece, which is we've invested in a lot of things for all the right reasons. But you know what, not everything pays off. Not everything has a return. And the team is looking hard at where can we reallocate to drive better growth. The Q2 restructuring, moving it to developer awareness, is one such example. So we will continue to drive reallocation within the cost structure. And then number three is productivity, and everybody drives productivity. And I would highlight 4 areas for this. Number one is we have a good offshore footprint, but folks, it should be a lot bigger. So what you're going to see is while headcount may continue to go up, those are largely going to be in lower-cost locations, especially as it relates to engineering. So we're going to push a lot harder offshore. Think about this, too, when we get to the equity part that we'll talk about in capital structure. AI, just like everybody else, I thought it was great, was high value, low risk, okay? Everybody is looking at that. We need to be better about driving AI efficiency. So we will do that. The other piece is we largely have the management layers in place. So what we will do is we'll leverage that. And then also tools, we need to build better tools for efficiency. So those are the areas we're focused on. I don't want to point to certain groups. But in general, that's what we will look to, to drive efficiency. So hopefully, that helps with those questions. Okay. Before moving to the financial framework and the long-term model, hey, I want to hit a couple of things on capital structure. So the first thing is cash conversion, we've talked about this. So what this chart shows is on your far left, in the last 2 fiscal years, the green bar is the operating cash flow number and the blue line is the conversion from operating income to operating cash flow. And you see it's about $0.50 on the dollar. Keep in mind folks that you've also seen, during this time, deferred revenue continue to decline, because the consumption business is mostly you consume, you bill and then you collect later. And you should expect to see deferred continue to decline. But the nice part is it's largely flattening out. The goal is to get that 50% much closer to 100%. I don't think we can get over 100%, because we're not going to change our pricing. There's 2 parts about cash flow, how you collect and how you pay. We're going to leave the collections part there because that to me is a pricing decision, but we will get a lot better about driving best practices internally the way we manage our business and our vendors, okay? So it was actually 104% in the first half of this year. You should expect that percentage to come down in the second half, but still be above the 50%, okay? So a lot of you folks know me, at the end of the day, I love accounting, but I really, really, really love cash. So that's an important part. Okay. I also want to talk about our equity and our stock-based comp. So what you see on here is our fully diluted share count and then stock-based comp as a percent of revenue. And you can see it's come down from about 30% to about 24%. There's a couple of important things here. Are we okay? There's a lot of scurrying around?

[indiscernible].

Okay. Do you want me to stop?

[indiscernible].

Okay. So why don't I do this. We'll take a 5 minute break. We'll make sure that we're up for that. If people want to take a comfort break, they can. Perfect. Okay. [Break]

All right. Very importantly, and our wonderful Chief People Officer, Harsha, is in the back. Equity is an important part and always will be an important part of our compensation. Folks, we need it, especially as it relates to our engineers. So we will always issue equity as a part of our compensation, and you see that it's a big piece of it. So it's a key part of it, especially as we look at technical talent. However, as we change our operating model and our cost structure and we're more efficient, and we talked about offshoring as well, that's going to help here as well. We'll still issue equity. But from an aggregate perspective, that should start to come down. So our expectation is stock-based comp continues to decline. Don't expect to see it go way down. I think gradually, as we get more productive and we drive efficiencies, you should see it come down. But I want to make sure and set the stage, hey, folks, equity is a big piece, you're still going to see it. But like everybody else, we understand that we're diluting you down, and we want to make sure there's a return on that equity dollar. How we're going to manage that, though, is we want to manage -- our goal is to manage total share count relatively flat. And how we're going to do that is through our share buyback. The other thing that we'll do and some of you see other companies do that as well is, hey, even when it comes to the cash settlement of RSUs, keep in mind that when shares vest every quarter, we issue the gross amount of the shares. We then sell the net amount to pay the taxes and then we remit that cash. What we're going to do going forward is we're actually going to issue the net, and we're going to pay the cash directly out of cash balances. It is an implied buyback. It's incremental to what the Board has authorized. You'll see it in the cash flow statement, but that's another way for us to manage our share count. So the goal is to make sure and try to manage that dilution, be responsive and good stewards of your capital, but make sure that equity is a part of the compensation plan going forward. We have the wonderful luxury of having $2 billion on the balance sheet, and we will use it to help manage that dilution, okay? So let's talk about the long-term targets. I'm going to break this up into kind of the framework as we look at the business, what's critical for us. And then we will do the math and say, at a high level on average, what does that mean for the target perspective. But the thing that overrides all of this is, hey, folks, we are driving to be a Rule of 40 company, and we're very serious about this. So fiscal '22 and fiscal '23, Mongo actually was a Rule of 40 company. If my definition of that is revenue growth plus non-GAAP operating margin, it was 52% in '22. It was 47% in '23. Most of that was driven by revenue growth. Last year, that dropped to 34%, because we grew 19% at a 15% margin and the high end of the guidance is pretty close to that. So we expect now to be able to make ways back to that 40%, but in a much better balance. And again, I'll say the same thing I said earlier, which is we will always over-index on growth versus profitability, but they're both important, okay? So as you see our long-term goal, we understand that it's relatively rarefied air for a software company to get to that rule. That is our internal target. We feel it's reachable. And everything that you're going to see us talk about today is in pursuit of that goal, okay? Okay. Three parts of the financial framework. And when we talk about this, we're thinking over the next 3 to 5 years. A couple of things. It's a long-term plan. The company has never given targets before outside of very high level. So we take this seriously as our commitment. We also understand it's 3 to 5 years. If we all rewound back to when you sat in this room last year, and if anybody could have told us what the next year is looking like, do a victory lap, because you're really good. This is 3 to 5 years. There's a lot of moving parts. We feel really good about parts of the business that we'll talk about. Very importantly, we are not guiding for '27. I'm not even guiding for '28. This is a 3- to 5-year view, okay? So we will guide '27 when we get there in late February or early March. This is how we look at the business long term, where we're investing to drive that growth and what we think is important. Okay. So the first piece and the first thing I want to say is this is not a ceiling, okay? Our expectation and our goal, it's the most important part of our business, is to drive durable Atlas growth of at least 20%. It doesn't mean that it's going to be in the 20s. It may be in the 30s. This is not a ceiling. But this is the biggest piece of our financial framework, is to drive Atlas growth durably and consistently during that time frame. It is now about 75% of the business. It's going to continue to be a bigger part of the business. We're not guiding as to what mix because there's a -- hey, folks, there's a lot of moving parts. But everything that you heard Fred and Jim talk about and everything that you heard May talk about as well as Dev when he introduced it, was all around driving durable growth in Atlas, is the most important part of our business. This is the major focus, okay? As I've said many, many times, that then equates to margin expansion, largely driven by revenue growth. Our goal is to continue to drive operating profitability margins up by between 100 and 200 basis points a year. Why the range? Because of the duration and the mix, and I'll walk you through where we are today. This will move around a little bit. Some of it's out of our control. Keep in mind, we are in a consumption business. The customers decide how they deploy and consume. We can help them. We can push them. But at the end of the day, that's their decision. They also make the decision whether they do a multiyear or an annual renewal. So there are some things there that we just all have to deal with, and that's part of this. So in years where we do a little bit better in Atlas or in non-Atlas, you'll see us push up a little bit more, and then it may drop down. But again, within that range, pushing towards that Rule of 40. That's the second major framework from a financial perspective. And then, of course, I'm going to talk about cash. We need to generate better cash conversion and generate material free cash flow, and that is our goal. Again, we're focused on best practices. Nothing in this is baked in that we're going to change our pricing policy. It's too competitive out there. By the way, that's a timing issue if you want to collect upfront. We are where we are. We're assuming that stays relatively consistent, but we're going to drive much better efficiencies internally. So these are the three building blocks. Atlas growth, durable growth of at least 20%. It is not a ceiling. I will say that. I will say that. I will say that. We feel really good about that business. It grew 29% last quarter. We guided to right around the mid-20s. There's still a lot of time left in the year. This is the most important part of our business. The business model will drive efficiencies. We'll get better about the ROI of where we spend with the goal of always funding growth first. We will not starve the business and then that operating profit is going to convert to better cash conversion, okay? Now let's talk about what -- let's do the math. And before we do the math, again, I just want to go through it one more time. This is a 3- to 5-year time frame. We view this as a commitment. I'm going to shortcut the first question in Q&A, which is because I get this a lot, what is your guidance philosophy and what is your philosophy here? Folks, this is our best look at the base case. We will always give you a view that has more upside than downside, and that is the goal. But we take our commitment seriously, but we also want to be realistic. I love hockey. I hate hockey sticks. And I'm not going to stand up and give you a number that you're going to look at and say, Mike, come on really. We're going to give you something that we feel good about hitting. We're always going to build in more upside than downside, okay? And we are not guiding '27 for the third time, and I'll say it again when we get to the end. Okay. So let's do the math. Atlas growing at more than 20% over the next 3 to 5 years. On average, we would expect revenue growth, again, in that base case to be in the high teens. Let's break this down. Fiscal '25, Atlas grew by 27%. The company grew by 19%, because non-Atlas grew by about 3%. The high end of guidance for fiscal '26 is right around that same 26%, 27% for Atlas, but because of the duration impact and the headwinds we've talked about, non-Atlas subscription revenue is actually declining in the mid-double digits. Therefore, the high end of the guide is 18%. So '25, 19%; '26, '18. Hopefully, we do a little bit better. We're right around that high teens. So, we feel good about this, but we also know that there's upside. What are some of those puts and takes? If Atlas grows even faster, it will become a bigger percent of the business, and it's going to drive the growth up. And that's just the fundamental part of the business, which is we hope happens. We are expecting in this, and we're not guiding to EA specifically, because there's too much variation, but to remain that ARR kind of in that low to mid-single digits. So this is simply math driven by Atlas. Our goal, again, is to drive Atlas growth at least 20%. It is not a ceiling for the fourth time. Okay? So that's a big piece of it. The other part is hey, if we can have some stability in EA and when AI starts to hit, some of that will help. We've actually seen some of the AMP deals come through as EA deals, because they're going to do their modernization, they're going to keep the data on-prem. So I think it's going to help both. Again, we don't know where the mix goes, but that's the puts and takes as well. Again, the reason why we would be a little conservative, and we did this in the second half of the year, it's a consumption business, and there are economic factors that we can't forecast. Hence, where we are. So we feel really good about the business, good base case, but we feel there's more upside than downside. And it's really driven by the confidence in Atlas. Okay. We get this question a lot. Can you -- when can you get to 20% and can it go above? So again, we will invest to drive growth at 100 to 200 basis points a year. We feel very good about being able to get to 20% in the 3 to 5 years. This is a second area where I'm going to say, it's not a ceiling folks. If Atlas -- when Atlas continues to grow and even as we get to the end of this period, it's going to generate a bunch of profitability. And we do expect that this is going to continue to increase. But in the time frame, we feel really good about getting to the 20%. And I'll say it again, we will not -- these two are related. Our ability to invest then drives growth, which then drives margin. We will not starve the business to drive that number up. We will invest to drive growth, because growth is a lot more fun and it drives a lot more profit to the bottom line. So this is our job as management is to balance these two, and we will. But when you add those two together, some years, we're going to be above that high teens, some years maybe at the lower end. And the perfect example is fiscal '26. The first half of fiscal '26, Atlas has grown by 28%. Total revenue has grown by about 22%, if I'm not mistaken. In the second half, we still expect Atlas to grow, call it, in that mid-20s. But because of the duration impact, total revenue growth is actually 14% or 15% forecasted, because of that duration impact. That's why we have that range in the high teens, because that's going to happen as we go through the years. Here's the great news. As Atlas gets to be bigger and bigger and bigger, some of that volatility should get washed out. But that's where we sit today, okay? So those are the first two big pieces of the long-term targets. And of course, free cash flow conversion. So the goal is to have at least 80% plus when I say conversion, I mean from operating income to free cash flow. Free cash flow and operating cash flow are about the same here. We have very little CapEx. So we do expect to generate much or have much better conversion. So if we're at 20% operating margin, what we're saying is, we expect free cash flow margin to be at least 16%, and that will go up. You should not expect that number to be higher than operating income on a long-term basis because, again, we're not driving that much deferred revenue. Therefore, it's hard to grow cash flow faster than you grow profitability. Okay? Long-term model, feel great about Atlas, stability in EA. The flywheel will drive incremental profitability, we'll get better at managing our cash conversion. So those are the targets. That's the summary of where we are. Before we go to Q&A, and I thank you for your patience as we fix the glass in the rink. A couple of things. I just want to remind you of the growth drivers. We have a huge market. It's growing double digit. Our platform is differentiated with the document model, and we have clear discernible differences in our product. We do expect AI will become an incremental growth driver. We expect AMP will become an incremental growth driver sometime during this time frame that we talked about. And we plan to drive durable growth with margin expansion. That is the summary of the financials that pull together what we talked to you about today. So I thank you for your time and patience, and I know you probably have a bunch of them. We will run, I think what time you want to go to Bridget? We'll go at 3:30. We'll leave it open for 30 minutes for Q&A. So that's the prepared remarks. Let us get the chairs up, and then we'll pass the microphone around and take your questions. If I could ask Dev, Jim, Fred, May to join me, that would be great.

I'll just speak up. Howard Ma, from Guggenheim Securities. Thanks for doing this and a lot of anticipation for Mike's move upmarket again. Dev, I want to start with -- I believe on the Q1 2025 call, you guys laid out three strategic priorities, obviously, to say instantly, move upmarket, relational migration, which is both [indiscernible] and program and the math EA program. [indiscernible] it's like presentation of the long term target. What areas provide most of that?

Okay. So I would say of the three things, clearly, the returns that we're seeing from the move upmarket are evidence in our Q1 and Q2 numbers. It takes some time, obviously, for those -- when you move people upmarket or frankly, replace people in mid-market and hire people at the high end of the market, it takes some time for them to ramp, close deals, maybe we have to re-factor some sales teams and some territories, and that took some time to work through. But we started seeing the green shoots towards the end of last year, but it's still very hard to predict how quickly those workloads will grow. And I think a big part of the growth that we've seen in calendar FY '26, the first half of FY '26 is that move upmarket. In terms of relational migrator, I think we have seen some -- we've -- I think what we've seen is a lot of conviction increase about the opportunity. We've now talked to lots of customers across various industries in both North America, Europe and Asia. There's clear demand. We've become much more focused on -- obviously, you've heard the AMP story. And if you had attended some of the breakouts of the keynote, you'll hear a lot more detail about AMP as well. So I think we have a lot more conviction. I mean, Jim may want to add more color around that. But clearly, we said that it's going to take some time to show up in the numbers, because these are big, big workloads and customers are going to move cautiously, but there's clear demand. So we think that's more of a long-term driver. And then with AI, I think we made a lot of progress with -- I think a lot of you were surprised how quickly rolled out our vector capabilities when that market was still quite early. I think the Voyage acquisition has obviously proven to be fairly prescient. But the enterprise is still early in their adoption of AI. So I don't think you're going to see massive projects necessarily appear out of the gate, but we feel like we're seeing enough traction and opportunity that we feel like we're well positioned when that -- when enterprise get more and more comfortable in deploying these AI applications or agentic use cases.

It's Jason Ader with William Blair. Dev, I asked ChatGPT your question on the ideal database for the AI era. And it said three must-have things are relational for consistency and joints, JSON for unstructured data and Vector Search. So first question, is ChatGPT wrong? Second question, when we look at the recent developer surveys, is there a correlation between your popularity score and when you move to SSPL? And related to that, could you comment on the new open source document database project that Microsoft contributed to the Linux Foundation and how you guys see that in the market?

Okay. So another multipart question. So let's try and go through all three. So we believe that the problem -- I mean, some of these LMs are trained based on the information. When I asked ChatGPT the question, they didn't come up with that answer, so I'm surprised you got that answer. But essentially, the whole point is, when you have to distribute data across tables, it makes the cognitive load on developers that much higher. With MongoDB, you can move data more closely and related data more closely into one document. Obviously, JSON, we are a native JSON database, and I see a lot of comments about Postgres supports JSONB. I want to make it very, very clear that, that's like a retrofit to an existing architecture, and that's very different than being a native JSON database and the severe performance and feature limitations with using JSONB on Postgres compared to MongoDB. And I forgot the third part of your question, was...

Just on the correlation between the -- when you move to SSPL, the developer popularity scores.

Yes. We moved to SSPL in essentially January of 2019 -- I'm sorry, of fall of 2018. And then Amazon came out with its clone in January of 2019, because we had kind of got heard rumors that, that was going to happen. And I would say that our Atlas has only grown faster since then. Obviously, it's slowed down a bit since our peak. But we feel like there are some misconceptions in some communities, and I know, May want to talk about that, like some people think like that they can't use us for anything without paying us for something. The only restriction with SSPL is important to understand, and it's exactly not a restriction, it's a condition of use is that if you offer a MongoDB as a service, you have to open source, the extensions you built on MongoDB and the underlying management plane. It does not restrict you from doing that. It's just a condition of use. If you want to use it just as any -- it conforms to all the principles of open source beyond that. And then, regarding the Linux Foundation comment, I believe that -- I believe that, that -- those decisions by the hyperscalers to move or support the Linux Foundation is really a nice exit strategy for them so that they don't have to continue to invest in the clone products they've built. If you do your own diligence and we have a lot of people who've come from AWS and other places, we basically said those products have not taken off. As you know, the hyperscalers have a lot of other priorities. And so this is an easy strategy for them to do because, one, they can reduce their own personal R&D investment. But should the community build something interesting, they can still monetize it by offering that on their cloud. So I think this is more of a graceful exit strategy versus some new strategic threat to MongoDB.

Wonderful. Rishi Jaluria, RBC. This one is for May and Dev, both. Look, I'm excited to see that you're making headway in kind of going more after developers, obviously, always been a developer-led tool from the beginning, but establishing more of a foothold in the Bay Area where all these AI start-ups are being founded. The question for you is, as you think about trying to establish more of that brand awareness, what kind of tools do you have in your arsenal that you don't have situations of developers say, "Hey, I've tried something on a relational database or I tried it on a Postgres and then I realize I needed MongoDB, but that from the get-go, as they're even ideating and coming up with these foundations that MongoDB is just in their heads the default, whether that's event, whether that's doing more boots on the ground outreach. Maybe help us understand the thesis there.

Yes. Thank you for that question. Actually, I was worried when you pulled up the ChatGPT, because that's actually part of the strategy. You noticed that earlier, I used the word mindshare, not awareness. I think you probably caught that nuance, because awareness implies broader and mindshare is like a very targeted program. So one, we want to recognize that we have some amazing developers already no longer debate. How do we fire them up? How do we arm them to also be part of the advocacy and that flywheel, right? So scaling that way. Two, we have a next generation of developers. We've got a very robust education program. But how do we also capture these next-gen developers who are also AI developers that may not have followed the typical CS route, so to speak. So there's a lot of work going on over there, too. Now in terms of capturing hearts and minds and expanding on to the broader developer community, which I talked about earlier, there's some myth-busting that we have to do clearly over there. And updating everyone's operating system on what MongoDB is, asset transactions, JSON, what we are. So there are folks who remember MongoDB from the earlier days who have still those precepts in their heads and how do we update that. But then also how do we reach new folks as well. So while I like that my CFO likes me talking about ROI all the time, I have started laying the groundwork that some of the mindshare abstracts may be more abstract, because we need to go a little bit deeper -- sorry, higher up in the funnel and reach folks where they're even just investigating what the options are before they even have MongoDB in their brain. Now it's my job as well as products job and everyone in the go-to-market organizations for us to show up in a big way when they are researching and we come to them with an amazing product offering and a value proposition and a business value case. So that's, Dev, do you have anything to add?

No. That was great.

Thank you.

Sanjit Singh with Morgan Stanley. Thank you for all the great content and the new data today, and are super insightful. I wanted to unpack the theme around the durability of growth on two fronts. When I think about -- you guys have been very clear that AI is going to be an opportunity, but the timing is hard to predict. And so as we've seen Atlas and the broader business improve in the first half of the year, I suspect part of that is that the calendar year '24 workloads are ramping nicely. But is there a potential risk of an air pocket as we don't know the timing of it. So the question is always that, is that is there a handoff needed between kind of the momentum that you see today with your core workloads before the AI opportunity takes hold? I'd love to get your perspective on that. The second question is around what the analytical database players, Snowflake and Databricks of the world. And essentially get your critique, essentially, they're saying, we're going to bring more data and unstructured data. Customers want to build really important applications on top of that data, and they want to become the application platform of the future. Why is their strategy wrong? And why is that not a threat to MongoDB? So durability both of those two fronts.

Do you want to take the first one?

Yes, you want to do the second one first?

Sure. So to answer the second question first, listen, I've been at MongoDB for 11 years. Through that time, I've seen Snowflake go through multiple leadership changes. Frank Slootman, obviously, who's got a stellar track record said he was going to go after the OLTP market with Unistore. Ali has also made some proclamations that he's going to come out with a next-generation OLTP platform. And both companies basically decided to buy Postgres-based OLTP database companies. I think it says a couple of things. One, it says that it's acknowledgment by them that OLTP is the strategic high ground for inference. And the reason why is that you need access to real-time data. So yes, the definition of application can be fuzzy if you say a data engineering use case and you call that an app. That's very different than, say, an e-commerce app or a travel agent or like a financial agent where you're doing basically real-time decision-making or e-commerce application. So the definition of applications can get a little fuzzy when people say people are running apps from my platform. If you want to run a high concurrency real-time application, you need an OLTP engine to do so. So that's point number one. So I think both companies have recognized that and said, we need to do something. And they also recognize that to build something organically takes a lot of time, a lot of money and a lot of patience, because hardening these platforms, building something hard these platforms is we're in year 18 of our existence. So this is -- even though we still consider ourselves like a young adult, we've been around the block, and we've earned those stripes through just experience, focus and investments. And so when you realize I can't do this organically, what option do you have? The only option you have is to go buy a Postgres database, right, to basically jump start the process. But that comes with all the limitations and challenges with the relational architecture that we've spoken about for a long period of time.

Thank you, Dev. So on the question, it's a great question. And as we look at the next 3 to 5 years, this is why we talked about the range of Atlas. We don't expect there to -- and I love the phrase an air pocket. The -- as we said, AI has not contributed to what we've done really in the first half. And if we're talking about mid- to upper 20% growth, hey, the law of large numbers is real, but we -- if even that comes down, that's when we expect AI and AMP to help drive that growth and contribute to that 20% growth over time. We don't think that there's like a drop. We think it's going to feed in. And we've seen that a little bit, even though it's a small piece of our business, you heard three customers today talk about the use cases they use. So we think it's going to be part of that growth. But at this point, we don't see an air pocket as we look out over the next 3 to 5 years.

Matt Martino, Goldman Sachs. Dev, I wanted to get your perspective on a few things around AMP. One, what's the playbook here in terms of identifying and capturing legacy relational workloads? Because I think it's fair to say that not every workload is purpose-built for a document model. And then two, Mike, for you, historically, MongoDB has generated 20% to 30% of their new business from relational displacement. With this new platform, what are the aspirations for the long-term mix there?

Yes. So Matt, on the first question, I would push back on your point that not every workload is designed for a document model. I would say we can address a whole -- I mean, if you look at our customer base, we have all kinds of workloads, of all types of use cases. I would say the compelling reason to move from relational to document may not be as high, even though we can address it, because maybe they can't leverage all our features. So it is a small distinction what you said. Our approach is to -- it's a very much more of a top-down sale, because we are trying to find pain inside an organization. What is causing that pain? And invariably, if you're a financial services firm and the regulators say, you have a problem, you have a systemic risk, you got to get off this core application, because it's very dated, your development team is no longer there. You're running on old technology. That's going to be a compelling -- a compelling point for someone to say, I got to take action. It could be around a contract renewal with an incumbent. They know contract renewal is coming up in 18 months, and they say, we want to reduce our footprint inside an organization. It could be some other business issues. So our sales team, we actually have more demand than we can service. So we are trying to basically -- because we're taking a product-centric approach, we don't want to try and be all things to all people and look like a glorified SI. What we want to do is take a product-centric approach. So we're purposely focusing on right now Java running under Oracle typically with short procedures. And even there, we recognize there's so much variability in terms of the versions, libraries, how different companies code one versus another that there will still be a lot of services involved. But that's our point of view. We may slightly expand that ideal customer profile to maybe contemplate some other technologies if it's still -- if we feel like it's not that incremental. I don't know, Jim, do you want to add some color on that. But that's -- our playbook is to be quite disciplined about the opportunities we're going after.

Yes. No, I agree. And I think the vast majority of data is still locked up in some of these legacy applications. And I think what I'm most excited about with AMP is, one, basically, it is more of a top-down engagement that we're getting. And really, I think the catalyst for that is, I think the customers are feeling -- customers have been on old stacks for quite some time. Why did they not change previously? Well, they thought they could kind of survive as is. But the existential threat now is AI. They're like, I need to get to AI. I feel everyone has to report to the Board, what are they doing around AI. And they just know that the core -- the foundation to AI is the data, is the database, and they're locked up in all technologies. So for me, it's -- one, it's getting us more top-down engagement with some of these customers rather than kind of a bottoms-up from the developer level. So that's very interesting. It's getting them on to MongoDB and on to Atlas. And then you heard from McKesson, he was like, "Oh, yes, we're using MongoDB" and basically something came up where they're like, "oh, we need to do an AI thing." Now, McKesson was not an AMP customer, I'm kind of commingling ideas here. But he's like, "Oh, we need to do AI," and MongoDB has all the parts needed per Fred's discussion. And so we were basically prototyping like that week. So anyway, I think that kind of flywheel is pretty exciting, still early, but I think it has potential long term.

And then, Matt, on the mix question, so from a percentage, I don't really expect that to change much because as Atlas grows, I think AMP and AI-Gen should feed into that growth. The aggregate dollars will certainly become more meaningful. But as a percentage, I don't think that we would see a big mix change. And as we've talked about and we showed the data on the large customers, it's also tough for us to pinpoint. Is that a migration? Is that a new app? Because to us, it looks like new business. Hopefully, that helps.

Miller Jump from Truist Securities. Thank you for putting this together. I actually want to dig a little bit deeper on AMP as well. I guess, if you could just share maybe from the announcement today, is there anything that you see is like most incremental on the technology side that's a part of AMP. And then you mentioned headcount being deployed to help scale this. Like how -- where are you now with that headcount? And how do you think about it scaling in the future? I guess maybe for Mike, I'm curious if there's leverage there as well or if these engineers are each working with like one customer per engineer.

Do you want to answer that?

Technology. Yes. I mean, I think, like I said in my part of the talk, it really started with engagement with the customers. We had people in our, like, solutions architects groups, start -- it started with the experiment, like early on, AI tools are coming out, oh, maybe AI can help here. And I think even internally, I think some people were skeptical of, oh, well, can it really do -- really make a difference. And what we found is even the internal skeptics were like, well, actually, it can. And -- but then it's like, okay, well, if you just read the clickbait headlines of, okay, AI is going to generate all the code and engineers are out of work or whatever, that's what -- we're not finding that happening. What we're finding is, but actually the devils in the details, how you present the data to the code base, the store procedures to AI, how you chunk it, the workflows -- but the good news is working with customers now for quite a bit. We've gleaned those learnings, and we've been taking the product, because we're not natively an SI. We're saying, hey, how do we productize this to scale? And so from the field, we basically bring those learnings and working it into tools and technology that then we can provide to our engineers in the field to do it more repeatable with higher quality, faster in future engagements.

And from a headcount perspective, I kind of break it up into two. The four deployed engineer piece of it, I think you'll see us invest in that now, and we've done that because we need to build that scale. Over time, certainly, we would expect them to have multiple engagements, and they'll be a big part of the feedback loop for AMP. The piece where we're helping them actually do the coding, you'll see that be more variable. So I think there's two pieces to that headcount build. And that's better, because the second part will at least align to the revenue. The first part, there is some investment.

And if I can just double-click this -- just so everyone understands, I mean, obviously, Palantir has kind of framed this forward deployed engineer kind of definition, but just so everyone understands, we think that's part product manager and part developer, because the product management part is taking the repeatable part that Jim alluded to, the code, the libraries, the patterns that they see and re-factoring that into the product, where it's just not someone cranking out code that will never be reused again. And not that, you need everyone on the team at a client engagement to be FTE, but as someone -- at least one person who's factoring and thinking as a product manager and saying, how do I then -- but if I have to do this engagement again, how much of that can I just build to the product versus I have to repeat everything one more time. And the customers like that because, again, I mentioned this when I first got up is because they recognize we're not an SI. We are not in the business of trying to generate massive amount of services revenue. And they like the fact that incentives are aligned. We want to get this done as quickly as possible so that we can make -- move that application off a relational platform to MongoDB.

Will Power with Baird. Yes, again, echo to everybody's -- thanks for all the remarks today. Mike, in one of your slides, you referenced the week-over-week consumption growth in Q2, notable running above average. Can you just remind us what the key kind of core drivers there were and the sustainability of that, given that AI, I think, is still pretty early. And as we look at the kind of long-term framework, Atlas growing 20% plus. Just trying to understand the visibility and kind of core underpinnings of your confidence around that given that AI and AMP are probably still a little ways off.

Yes. So let's take those two questions. So if you look at Q2, we talked about this a little bit, Will, the consumption growth on a week-over-week basis when you saw it bump up a little bit. Some of it is seasonality very -- because, again, it's compared to Q1, it's week-over-week. We started out the quarter strong. We talked about that in May. And then that consumption largely held through June and July. So that consumption growth was pretty strong through that quarter. And then the nice part about that is, that builds a bigger base to go into the second half, which gave us the confidence to increase the guidance around Atlas. And then on your question on the 20%, the sustainability, the durability, really, the results that we've seen now give us even more confidence in the durability of that because to your point, AMP and AI are largely not big drivers of that. And what we're seeing is, especially with the move up market and what you saw in the larger customers is that we're seeing more deployment in those larger customers. We are seeing some of those even older workloads grow. We said for longer and bigger, which is a little bit of a change. You saw that in the consumption as well. So -- and as we look at it, we also know that, hey, we certainly expect over that time frame that we will start to get AI in AMP, but we are very confident in the core business, continuing to drive durable growth in Atlas without those being incremental drivers.

And just to add, the underlying driver is the higher -- I think said simply, it's higher-quality workloads. We -- because of our change in our compensation model and as well as the move up market, we are -- we are acquiring higher-quality workloads that are growing faster for longer.

Thank you. If I could do that, and we've talked to some folks about it, we continue to make tweaks to the comp model. And this was about, to Dev's great point, about getting higher quality workloads than just getting the quantity of workloads because those weren't growing as much as we'd like, and we will continue to tweak that as we go through this year and into next year.

Okay. Great. This is Yu Kim, Loop Capital Markets. So if you can just talk about the success that you're having or just the progress that you're making in targeting the large enterprise market. I think that's been the main focus over the past year. If you can just update us on that. It appears like the last quarter, there was a pretty big step-up in terms of the success you're getting from that market. Was there a certain like inflection point that happened, maybe the sales productivity ramped up properly or maybe the partner ecosystem, there was a lot more incentive driven by the partners. If you can just describe your overall progress that you're making into that enterprise market and what happened last quarter and how sustainable that is?

Yes. It reminds me of that line, why did someone rob banks, because that's where the money was, right? We are definitely seeing that the large enterprise is still spending healthily with us. And we've seen that historically, our sales productivity at the high end of the market has always been better than, say, at the mid-market. If I were to rewind the movie and in '22 when ZIRP ended -- calendar '22 when ZIRP ended, we should have moved upmarket more quickly. I think because the mid-market was also a big source of growth for us, we saw a lot of early and mid-stage companies grow very, very quickly. We decided that we probably waited too long and we're probably too patient to think that the next cohort would behave in the same way, and that didn't happen. So one is, just the overall mix of sales headcount is the preponderance of headcount is now at the high end of the market, which by means that you get better sales productivity on a blended average from your sales force. Two, because we are focusing less on volume and more aligning their comp to ARR growth, which is ultimately our North Star of value, they're naturally gravitating to bigger and more strategic workloads. I think those two things is why you're seeing the numbers you are. Obviously, you can't guarantee every quarter, you're going to repeat what we did previously, but we feel good about the motion. And when we review with the sales leadership team, they feel like that motion is really working.

Steve Koenig, Macquarie. Thanks very much for making the whole executive team available here and all your time. Great stuff. So this one is for Dev. I'm thinking about you're highlighting 2% share of $100 billion market. So that's kind of got, for me, both glass half full and glass half empty connotations, right? And so when I think about, well, most successful software companies dominate a category, right? And when I think about your category, I think like the core, you take $100 billion database and how much of it is operational? I don't know. Maybe Gartner knows, but let's say it's $50 billion, okay? And then you say, well, how much of that is custom applications as opposed to running SAP, ERP, right? So let's say it's half again. So that's like $25 billion. So at $2 billion, you're still maybe like 10% of that market. So what I'm wondering, I guess my question here is like when you think about what your target is and your category that you aspire to dominate, what is that for you? And like 3 to 5 years or even longer, what is that market that you're going to control?

Yes. So I would say, clearly, it's first OLTP, and it's really around custom applications. And that's where the enterprise for AI is actually moving more slowly, because one, the technology is not as mature, people have concerns about the predictability and the quality of the outputs of some of these AI-based solutions. So people are moving much more cautiously here. They're quite excited about it, but they're moving cautiously. But that, to us, is the first place. We are definitely working with what I call ISVs, who are thinking about embedding MongoDB into their product. That's a big part of the investment in Reclaim the day because a lot of the new AI native companies are doing so. We have some companies who are growing quickly, but the majority of them are still very, very early. So that's the second leg of the stool. I think, Mike alluded to it is that we're not necessarily saying that we're going to the OLAP market right now. But if there's an opportunity for us to pursue that market, we're not going to ignore it, because there's a big market. But then the question is, how do we attack that market in a highly differentiated way. We just don't want to be another me-too company, which is frankly what I think the OLAP guys are doing in the OLTP space is just coming out with a me-too solution. The world doesn't need a 15th and 16th Postgres-based Database as a Service offering. So I think that's the way we think about the market. And I would say our core market is still growing. I mean, people are so excited about AI, but they forget that if you talk to any senior IT executive in a financial institution or a large enterprise, they're still investing a lot and just run the business. There are so many things that they have to do in terms of servicing and support their business. AI is a nice thing about things to consider, but there's still a lot of near-term needs that they need to deliver on.

Tyler Radke from Citi. Dev, obviously, kind of brand-new executive team here at least on stage, and it's great to hear about all the different initiatives, especially the self-serve channel. I wanted to ask you about the sort of upper end of the go-to-market. I think in your opening remarks, as we think about MongoDB 3.0, how you get to $5 billion and beyond, you kind of evolved from selling work workload by workload to more strategic kind of top-down deals. So I'm wondering if you could elaborate on that. What do you need to do from a go-to-market perspective? Do you have the right people in place? And how do you actually do that?

So a couple of points. One, I would say that I think the management team at MongoDB has never been better. I think the breadth and depth of the team today is second to none. And it's not the whole entire management team. We have our Chief People Officer in the back and a few people who are not here today, but I feel like this is a team that can really grow this business very well. Second point I would say is, in terms of getting from $2 billion to, say, $5 billion, we definitely recognize that we need to start doing bigger deals. One of the things that we find exciting about AMP is that when you can show a senior-level customer about our ability to solve a major or migrate a very complex relational application of MongoDB, the perception of MongoDB suddenly changes overnight. All of a sudden -- because I've said this before, I hate the term no SQL, because you get bucketed into this carrier being the single function database that does -- is a one-trick pony. And we're not a one-trick pony by any stretch of the imagination. So -- but then it becomes -- comes to light like when people see that, oh, my goodness, you can really address this problem. And so then they all of a sudden think about us in a very different way. And now you're much more viewed as a strategic platform versus just one of many database options that they have. And then the third thing I would say is, we are also building -- we haven't really talked about this. We mentioned it a couple of times, but in full disclosure, we're also looking at building like an AI factory. Because what customers today want is they don't want tools, they want solutions. They said, don't come me with a bag of tools because I have enough tools. I want a solution to help me solve this particular problem. So we're starting to work with customers on building a factory that's a combination of products and services so that we can help them solve, say, a problem, build me a recommendation engine using AI, build me an Agentic workflow. Now we'll work with partners as well, and we're very early in this process. But that's how we start moving upmarket and selling bigger deals because we're not just selling workload by workload.

Actually, Dev, that's how AMP started 2 years ago. Right?

That's correct.

So we started modernization factory, clearly need better marketing for there. But yes, modernization factory started 2 years ago, we built on that success, and that's what we announced yesterday.

That's correct.

All right. Eric Heath with KeyBanc. I guess, I heard two sides of the spectrum here where PLG, you're focused on new workloads, AI natives being kind of at the frontier of new applications.

New customers.

New customers. But also new personas and new applications. But at the same time, we're talking about AMP, we're talking about migrations, et cetera, and the big opportunity there with the move upmarket. But arguably, this is probably the best time in Mongo's history to capitalize on new application development. So I guess like how do you think about the bigger, better opportunity over the next couple of years in terms of being at the forefront to capture what could be a massive tidal wave of new AI applications coming online versus focusing on relational migration?

Yes. I think, we kind of view those as two sides of the same coin, because AMP or relational migrations are really using AI as a means to an end versus an end to itself. We're using AI even -- and as Jim talked about, the challenge, and I heard Alex Karp probably describe it the best way that I think about it is that, a lot of people think AI is this magic elixir and you just use it and everything magically happens. What we are doing is putting the scaffolding or some sort of ontology around AI for migrating, like the sophistication around chunking up the code. Obviously, in a session like this, you can't go into gory detail, but the sophistication on how to chunk up the code, how to use AI to start re-factoring the code, how to use AI to start building unit tests and functional tests so that you can ensure that what you're building is functionally equivalent to what you already have, because no one is going to migrate if they can't do that. So all that scaffolding or that ontology of understanding concepts and relationships and rules are really critical to kind of making something really usable. And I think that's -- people use the term -- another term in sort of ontology is like a knowledge graph, like building that knowledge graph really helps provide the guardrails so you can really have consistency of output. So that is something that is part of AI. But then to your other point, yes, there may be a lot of people are interested in building AI applications, but people are also very nervous about AI applications, because of the fact that it's a probabilistic system. We just talked about embedding models and like how do you guarantee the output of these LLMs by having better embedding models. But they're not like, again, a magic guarantee. Like I'll give you a simple example. Someone did share this example with me is like, if you understand the semantic meaning of like insulin solves diabetes. That sounds like a very simple concept to understand, but insulin is only for type 1 diabetes. You don't use insulin for type 2 diabetes, right? So those nuances are things that -- so like imagine a financial services institution saying, I'm going to use AI and start giving people predictions on what stocks to buy and what stocks to sell. They're very nervous about the output, because they can't control the output and the nuances that come with understanding all the data. So it's going to take some time for people to really leverage the power of AI. And I've said this for the last few years, I think people are just overestimating the impact in the short term, but then maybe underestimating in the long term. Thank you very much. I appreciate all the time. And I know all of you are very busy, but we appreciate the time you spend with us.

Thank you.