Thank you, 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 wanted 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. Since the last time we were on the stage, we've had tens of thousands of people attend these events all around the world. 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 you some sense of our business. When I first joined MongoDB, we were a fairly small company, still with a decent name, but still unproven. 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, 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 one 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 it's 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 I 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 had to serve billions of ads per day, so consequently, they had 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, but 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, there's got to be a better way, and that epiphany was what we call the document model. The document model, built on JSON, is, 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 changes, and it also enables you to do that when the pace of change is only accelerating, and because MongoDB is built on a distributed architecture, it offers unparalleled scalability and performance, and if you 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 trite or being a cliché, 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 customer 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 processes 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 on what an agent does, we should use. 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 agent, 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 maybe 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 that have been taken, the cost and timing of flight into Naples, the booking of a hotel in Positano, and a dinner reservation in Ravello. These are all logged in the database. And because all this data 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 provides 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. 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 and any unanticipated events. 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. 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 it needs to 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 bringing 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, a vector similarity search, a keyword search, and search on metadata filters all in one pass, so this means that developers can build AI-powered agentic 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 embeddings, 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 re-ranking models by optimizing the most contextually rich, domain-optimized embeddings. So, said in another very simple way, MongoDB sits at the gateway of meaning 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 new technology can replicate overnight. It takes years of investment, of focus, and experience to do that. So what's interesting is that 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 were to ask AI, what's the ideal database that will power the modern agentic world? And I encourage all of you to ask your favorite frontier model. I think it will look awfully a 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 startups. 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 picking 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 all about our latest release, MongoDB 8.2. It's our most feature-rich and performant 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 latest 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 two to three times faster from their legacy system to MongoDB using this new approach that we call AMP. 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, Os Olivo. And, he was going to give you a lot of detail about the foundation of a 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're sharded, we've made it easier to keep up with your applications by making resharding up to 50 times faster. And if that's not enough, in 8.0, we also optimized 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. Array traversals, 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 three times 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 advance 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 equality 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 four 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 and need to stay on a release longer, we've got your back here too. Currently, major releases are supported for three years. Starting with MongoDB 8.0, I'm very excited to announce that we're extending long-term support from three to five years. It'll 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 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 need 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 three 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 non-negotiables 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, Upendra Kulkarni, in conversation with MongoDB's very own Melissa Plunkett. McKesson has been called the largest healthcare service provider that you've never heard of. Up endra, 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 North America. And within McKesson, I work as a principal product manager, and I've been with the company for about 15 years. Yeah. 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 kinds of challenges does that create for a company like McKesson? Yeah, thanks so DSCSA was 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 pretty massive scale. We're talking 1.2 billion serial numbers, and I believe that is annually. So it's billions of d rug 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 two don't match, the challenge is that product is now as if it didn't exist in the supply chain. You can think of a lot of drugs where we've had shortages over the last decade or so. Every bottle matters when we 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, and the data is just as important as the produc t itself to be usable. Amazing. So now I understand that McKesson's first approach involved a specialized SAP compliance system together with Postgres, 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, can you first walk us through at a high level what the limitations were and what kind of solution you ultimately had to build? Yeah. So we attempted at first to come up with one system to solve all of our problems. And what we realized at our size and scale, it was almost 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 and put that on its own repository to help alleviate that bottleneck and that scaling. Fantastic. Now, as I understand it, you built two repositories. So you had the 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? Yeah. So part of it was we had lots of requirements. Well, so let me step back. DSCSA was a very new regulatory requirement. We were out to build something that didn't exist. There's no off-the-shelf software that you can go and buy or look at. So with this, all the new challenges, and we went with DSR to help break down the calls 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. With 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+ customers every day. All that activity, unfortunately, happens all in the morning. Anytime from 7:00 A.M. to noon is when everybody's wanting their information. It made sense to help separate those systems out to individual use cases to make sure that we're able to be successful. Fantastic. Now you've decided on the CDR, DSR approach. What tipped the scale toward MongoDB? A couple of different things, right? One of the key things was our data in the DSCSA world is very hierarchical in nature. Obviously, the document database fits that model 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 had requirements to also have on-prem systems as well as in-the-cloud systems. So it allowed 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 go-live has been as smooth as it can get. I think it's a moment that we all should be incredibly 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 fight 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 times what you expected with no disruption. And so that means a lot for your patients. What did 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 these that serve kind of the humanity, it's an incredibly proud moment. Fantastic. And one of the things you mentioned, right, 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 performant, 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 doing 300,000 requests in the next day, and MongoDB was so performant, we didn't even notice it. There was no blip on the map. The Atlas performed fantastic, and we were very proud of the success and what we were 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, what advice would you give your peers in the audience, Brian, if they're tackling similar large-scale mission-critical challenges like this? Yeah. You know, when I think about the entire journey, I think one of the keys 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 were 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 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 and 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 healthcare industry and the patients alike? And we have quite a few things that are lined up. We are embarking. We're 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 future-proofing our operations now. Yeah. And I just have 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 remembered those days when it was very popular, blockchain was going to save the world. AI was kind of seen 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 was just fantastic. Fantastic. Thank you both so much for sharing your story with us. Upendra. Thank you. Brian, thank you, guys. It's not often that 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 their 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 source using vector-based retrieval. That information is then fed to a large language model to generate accurate, grounded responses. The ability to chat with developer documentation is a great example of this. Next up are 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. In this scenario, a team of highly specialized independent agents, such as a VP of marketing, a market researcher, a copywriter, a graphic designer, etc., 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 one critical component, and that is the quality of your embedding models and re-rankers. This is often the difference between potential and production. Before we go any further, let's do a quick refresher on embeddings and re-ranking. An embedding 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 re-rankers, they compare each retrieved document directly to the user's query. You can think about it this way: you first retrieve results using embeddings, and a re-ranker then reorders those results to improve accuracy. Stronger embedding models and re-rankers improve the quality of your 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 content of past conversations, so if embedding models and re-rankers are so important, where can I get great ones? Well, I'm glad you asked, MongoDB Voyage offers best-in-class embedding models and re-rankers. We have your typical general-purpose text embedding models, which turn pure text into an embedding. In this category, the Voyage 3.0 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 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-c ontex- 3, a breakthrough in precise chunk retrieval with global document context. This contextualized chunk model is the very first of its kind. Our model processes the entire document in a single pass and generates a distinct embedding for each chunk, delivering superior retrieval performance. On the reranker side, our recent rerank- 2.0 release sets an industry standard for re-ranking 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 had to feed that data into your embedding model and then be sure to update both data stores. And 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 two 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. Hey, 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've watched it way too many times, too many times for me to even admit. But I just can't get enough of Meryl Streep and her iconic stares, like when she glares at Anne Hathaway at 32 minutes, or, oh, my favorite, the Cerulean Sweater scene. You know what I'm talking about. At 54 minutes, 11 seconds, or... Whoa, whoa, whoa. Hold up, hold up. That's actually pretty good. You know the actual timestamps. I mean, you really have seen this movie a lot. 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 scenes from all of my favorite movies. So I built an app for it, an AI app for it. It's what 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 point. That's a good point. Okay, so why don't I use the next best thing? Are you ready for it? Hit me. Previous MongoDB.local keynotes. What? 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? Well, look, you don't have to tell me twice. I do it every week, every weekend, so... See? So, okay, okay, jokes aside, there's this term that Dev always uses, something like critical moment. So how about we see if he talks about that in last year's keynote? So here's my app. I've 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. Oh, it's crucible moment. My bad, my bad. But while they'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 timestamp for me to skip to. So let's see what Dev has to say about crucible moments. The most well-known venture capital firms in the world, and who's also one of our earliest and largest investors in the company, has a term they call 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. Oh, wow. I better not mess this demo up in case this ends up being a crucible moment in my life. Look, crucible moment aside, you know this demo is super impressive. Can you tell us a little bit more about how you built it? Sure, yeah. 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 the frame to capture what's happening within it. But can you believe that it took me, it cost 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? Oh, yeah, 100%. So speed is the name of the game, right? And there's many MongoDB features that you can use to optimize AI 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 float 32 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, they now only take eight 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-c ontext- 3, Voyage- 3-l arge, and the Voyage- 3.5 series are all trained with 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 GenAI Showcase GitHub repo that has this app that I was just showing you and many others for you to check out after today. Awesome, awesome. I love it. Well, thank you, Frank. And I'm going to now go re-watch 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 scratched 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 P.M. 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. Now, grab 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 nights? 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 large estate of legacy applications, which were 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, risking 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, you know, large estate of stored procedures. It's a ball of spaghetti, which is, you know, hardly documented, and you're very convoluted to understand. Okay? And then you have these outdated frameworks and runtimes, which are brittle and hard to upgrade. Code 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 tests 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 these applications can be enormous. But making the decision to rewrite, to re-architect, and modernize these applications can be overwhelming. It's why so many companies postpone their modernization projects year after year. I have good news. MongoDB has worked on many such modernization projects. Through years of experience, we have, you know, 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 MongoDB's 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, you know, code transformations speed up by 10x and overall modernization efforts by two to three times faster. These modernized apps will land on MongoDB, so you are better prepared and positioned for the future. AMP includes primarily three things. We call them the three 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 on MongoDB, and in the future, you can focus on building, you know, 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 60 times faster and reducing the regression testing time from three days to just three hours. IntellectA I, one of the world's largest fintech platforms, was faced with significant performance and scalability challenges on their existing stack, which was based on a monolithic architecture and with a 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, their development life cycles were sped up by as much as 200%. 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%. With AI tooling, the bank was able to reduce time spent running their application test cases from over 80 hours to just under five 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, you know, 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 de-risk 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 a performant application running on MongoDB so that you can have 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 where he will be in conversation with Voyage AI founder Tengyu Ma and CNBC's Jon Fortt. Thank you. All right. That's quite a 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, that every application was essentially a CRUD function on a database. But then people realized it didn't make sense to recreate their own CRM or their own HRIS system. So every customer ended up implementing some version of Salesforce or some version of Workday or some of their equivalents. But that wasn't really a competitive advantage. That really just made their business run more efficiently because your competitors could use Salesforce or Workday. What really provided 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 find other ways to drive a 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 agentic use cases that truly transform their 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 as 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've 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 the 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 vision models. But large language model was really amazing. And yeah. 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. Yeah, I think so. What's the lesson in that for technologists, for developers who 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 in some sense, I think the AI kind of like technology is changing the workforce, changing the way that we work every day. So I think Anthropic has a blog post about this, and MongoDB will 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 assistants. 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, in 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, the human communication piece and then even the degree of understanding you need to have of your organization's mission, your customers' needs. Yeah, 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 our scale of our ambition, there's so much more we want to accomplish. It's not like we 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 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, Voyager. 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 vector store, and we were really proud that we could offer a company's ability to do this very sophisticated. And you heard a little earlier about hybrid search, the Rank Fusion command, that you can do very sophisticated searches. But customers, when they heard the story, said, 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. We quickly 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 larger organization. So we had multiple conversations and discussions and realized it made sense to do that. 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. The Voyage models are ranked very high, so much so that Anthropic recommends the Voyage models to all their customers. 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? Because we believe that we have amazing kind of progress in the last few years for the AI capabilities. But sometimes people forget or miss that these AI models off the shelf cannot access proprietary information the company or an individual has. 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, they'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. Okay. Yeah. Embedding models is this tool that MongoDB built to make this kind of connections and ingesting massive data into large language models possible. In some sense, it's kind of like a librarian, which helps you find the most relevant book or book chapters in your library. In some sense, this librarian is also beyond a traditional librarian who is using the call numbers, right? The call number is just nine digits. But here, the embedding model actually generates thousands of numerical floating point precision numbers to represent not only the book title, the book, the year, the authors, but also every little detail in that book up to the chapters, sentences, or even any entities in the book. So that when you use this longer version of the call numbers, we call it embeddings or vectors, to search the relevant chapters, you can be much more accurate and much more efficient. Okay. 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 scraped 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 re-ranking models are super important to be able to 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, as sexy a couple of years ago is now viewed as 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 one of the reasons, for example, that I believe that the vision and joy in MongoDB is that we believe in the document model, which is what AI is all about because AI's data are unstructured, semi-structured. In some sense, that'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 require a database, and MongoDB can be that database that is intelligent because you can search through the database with the embedding models, the re-rankers, and get the most relevant information. Well, let's let them get to it. Dev, Tengyu, thanks for having me here. Thank you. Helping you kick it off. Well, you're our rock star from CNBC, so thank you for being here. Well, I got to get to work. Yeah, exactly. How's the markets doing? Thank you very much. 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 A.M. So refill your coffee cups, do whatever you need to, and the next session will start at 10:45 A.M. Thank you very much. I love the flow. I love the content and what they talked about with the Good morning. Sorry to stop the music. I know everybody loves that great 1980s song. Good morning to everybody. My name is Mike Berry. I'm the CFO at MongoDB, and I am proud and honored to be the emcee 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 three o'clock, so that's about a four-hour event. About 12:15 P.M. or so, we'll take a 15-minute break, have lunch boxes for you, so we'll keep you nourished during that time. We will have a Q&A session at the end, so I would ask you hold your questions till 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, 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 two people, and Jess started a couple of weeks ago, as I like to tell them, hey, but there is no shallow end of the pool at Mongo. You're going to dive right in. Earnings, investor day. But there's two 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 four months. So Bridget, Austin, thank you very much. The other big thank you, and they're not here yet, and some of them may be in here, is 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. 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 31st, 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, 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. You know, one of the great things about this, at least I think it's great, versus last year, hey, there's four or five new people. There's only one 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's 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 a thousand times today. Durable, profitable growth. So when you leave here today at 3:01 P.M., there's a couple of things we want you to remember. That's one 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. You see those folks there, Cisco, DevRev, and TinyFish. We're going to have May talk to you about, and we talk about this a lot, our product-led growth and our self-serve model. It's a huge part of our go-to-market motion. 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? Yes, we will talk about long-term targets. You're going to have to wait two hours and 30 minutes. Hopefully, it's worth the wait. Then we'll open it up for Q&A. All your presenters will come up and talk to you. Okay, those are all the housekeeping items. Again, folks, we'll post on the website, and you'll have access to those charts. 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 four 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 in the keynote. It's 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. Just a couple of things on the market. These are all IDC numbers. The market today is estimated to be a little over $100 billion, and as you know, we only own 2% of that market. Even if you became a 5% share, we would be a $5 billion revenue company. 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 30% year- over- year for the next few years, so that speaks volumes about the fact that our market's large and it's still growing. So the second question is, 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. Constantly, 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 the 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 would do search and retrieval through 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 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, the founders started the company in 2007. They were, essentially, I talked about this in the keynote, but the founders were the founders of a company called DoubleClick. DoubleClick was one of the first web-scale apps that people saw. They used to serve billions of ads per day, and so consequently, they had to deal with the massive data challenges of that time, and this is like over 20 years ago. 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 build something that we would want to do? And that was 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 challenged me at that time saying, can we build a durable business? There were a lot of questions about open-source companies. And at that time, there weren't many open-source companies that had achieved meaningful scale. And so open-source is great for generating value, but wasn't great for capturing value. And when I looked 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 to be confused with the product, the phase of the company. And we believe there's an opportunity 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 relationals been around for over 50 years, and in many organizations, there's a predisposition to just stay with relational. We recognize 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. 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 I have in my business. 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 re-architect a software product once you've 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 with my supply chain? All of that can be embedded and unified in a 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 is 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 its incumbency. Relational is not flexible. Relational is not easy to change. Relational doesn't easily support different data types. A lot of relational databases claim 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 KB in size has to do something called off-row storage. Off-row storage really adds a performance overhead to Postgres. So there's limits to what these platforms can do because they were not architected from day one to be a native JSON database. So then when you think about, okay, what does the ideal database for AI look like?, and I'd 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 a lexical search engine, but we also offer world-class embedding and re-ranking 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 you perform even in the most demanding use cases. And we're battle-tested. Some of you may have heard of some of these newfangled companies who 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 that market, which is the legacy relational market. When I took MongoDB public seven 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 seven years, but I was frustrated that that part of the business did not grow as fast, and one of the reasons was that 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. 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 tests, 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 that's essentially what we did with AMP. We recognize that AMP, 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 codes their own, writes code, et cetera. So there'll always be some combination of products or tooling and services over time. That ratio will increase more on product or tooling, but we recognize 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, 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 three years 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 you walk people through this, our architects are 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. 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. That's really happened since the first day I joined the company. When we first joined, the question was, ey, there's a bunch of NoSQL players. Why do you win? There's 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 proved 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're 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 had 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 anyone's 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. It's 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. 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. Our differentiation against relational, I would argue, is real and durable. Let's talk about why. 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. They're basically designed for a world of uniformity and predictability. 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 a 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. In a world that's constantly changing, that becomes super problematic. Third, Postgres and these relational databases were designed to be single-node systems. Now, what's interesting, and Jim will 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. 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. As customers really start understanding this as 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. 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 Atlas ARR is coming 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 five times 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 re-ranking 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'll 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 and 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 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, can't go back. Three, thank you. That we're continuing to focus on driving more impacts for our go-to-market efforts. We've talked a lot about how we moved up market 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's 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 mic 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 they've 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. It enables us to have the best performance with documents and unstructured JSON data, which, as they've 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, healthcare, 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 on some of these dimensions, including very notably performance. And these demands permeate both how we build the software, but as they've 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 mention 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 atop 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. So we released MongoDB 8.0 last October 1st. And already over 2/3 of Atlas clusters are now running 8.0. So customers are really rapidly moving to this because their 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 a little bit more a little later today, in terms of performance, they saw database reads improve by as much as 30%, and bulk writes improved as much as 50%. And then Coinbase, 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 demands. 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. We're really excited to put this in the hands of our customers today. In the keynote, we talked about Queryable Encryption. 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. day, in 8.2, we expanded Queryable Encryption to add support for even more types of queries: prefix, suffix, and substring. What that means is you can build an application now. For example, let's say I had a customer support application for a healthcare 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. The application can still pull up all of the records that meet those criteria and pull up maybe the few customers or probably with one credit card, the one customer where that will match. This is a really powerful capability that only we have. Now, Queryable Encryption, you might say, okay, well, that's interesting. That's future. 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 have already been 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. It 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 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 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 infinitely 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 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 into 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 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 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 replicating across all three. And so not only are you taking advantage of that we support over 120 different geographic regions, but you also are taking advantage that if you choose MongoDB, you have the optionality to move across the three 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, they're on one cloud, and they're getting pressure to diversify. And they've actually been calling us because they're our customers, and they're saying, hey, Jim, how do you all approach this? Do you have any tips and tricks? 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 two, and due to mergers and acquisitions, 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 some of our customers come up on stage, is 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? It could be availability of hardware, NVIDIA chips, or what have you, or who's developing the best AI services. I think the answer is it's not crystal clear how things are going to play out. So as a CIO or 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 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 model is a 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 you're run anywhere, it 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. It started as an experiment. We were skeptical too, oh, can we just throw AI at everything and magically it 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 at 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, 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, kay, well, AI is just about the code generation, but as we walked through a little bit 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 tests 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. It was 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've retired or moved on, right? And so in many cases, customers don't even 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. So this is an example of tooling that basically does 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 two 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, well, 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 Java applications or your other application code. It's kind of hidden. Two, a lot of the LLMs actually aren't trained on that code because it's not in the GitHub repositories and all that. That brings some challenges that we've been able to figure out how to navigate. Another example, too, is we've found that some of these stored procedures are giant. If you just try to take that and throw it to an LLM, you're just not going to get the results. 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 stored procedure code and break it into smaller, testable, reusable chunks. That's another example of where we've developed tooling. Okay. That's all good, but let's talk about some customer results. Lombard Odier successfully migrated key applications from SQL database to MongoDB. This resulted in migrating over 50 times faster than they were able to do previously and reduced regression testing time from three days to three 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%. 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 the AI tooling, the bank was able to reduce the time spent running application test cases from over 80 hours to just 5 minutes. Bendigo migrated onto MongoDB Atlas at 1/10 of the cost of traditional legacy to cloud migration. Here are some proof points of that. And just a reminder that we've had breakout sessions that are being recorded where we are going into much more detail, including demos of the tooling we have. Okay. And so now, as we transition to bring up our two 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 you can hear from it in the words of our customer and not just me. Certainly, when you start a technology company, architecture is destiny. You don't want that architectural decision to limit you in the future. What you build at the beginning defines what you can become as a company. When we were starting Big ID, we thought there was an opportunity to reimagine how organizations go about protecting their sensitive data. Early on, we made certain decisions in how we built the product. The choice of stack is important. We obviously looked at the structured options in terms of Postgres and so forth, and we looked at some of the NoSQL structures, but again, we wanted an organization to bet on the future. MongoDB provided us the full package: enterprise-class support, multiple interfaces. We wanted the ability to operate in the cloud. We wanted to be able to operate in the data center, so we have a tremendous amount of flexibility in terms of what we collect and how we actually analyze the data to create the only catalog for unstructured data in the world. We're able to do things, especially around GenAI data, that none of our competitors are able to do, so MongoDB not only gave us enterprise support and enterprise class, but it essentially provided us future-proofing, especially as we enter the GenAI era of big data. Decisions you make early on define what you can become as a company. That decision to partner with MongoDB means that companies like us can rethink how people go about protecting their most critical and sensitive data. Great. Thank you. And now I'd like to Welcome up Tom Valetta, Enterprise Architect, rather, at Adobe Workfront, and Scott Mooney, VP of Distribution Operations at McKesson. Thanks, Scott. Hey. Thanks. 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 Valetta. I work for Workfront Adobe. Sorry, Adobe Workfront sometimes. Anyway, I've worked there for six 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, technology 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. 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? Yeah, yeah. You mean how long it is? Seems like it starts at 5:00 A.M. and goes to midnight, but. No, 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 two 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. Yeah, with mission-critical and large scale. So what about you, Tom? Yeah. So Adobe acquired Workfront about four years ago. Workfront, we provide a SaaS application that's business-to-business for some of the largest marketers in the world: Coca-Cola, Amazon, Google. Those are some of our customers. What we do, 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. 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 two years ago, and we found that in our original database system, our 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 information that they ask for. Awesome. We also started off with a different system. We started off with a SQL system and a monolithic system connected to it. 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, so we knew we needed to shard it, 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. That lasted for about 500 more customers. Then that ran out of capacity. Then we added another one and another one. I mean, we got to the point where we had full teams kind of managing the s haring and making sure that 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 basically onto 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 a lot of our engineers come from the SQL background. They know how to approach SQL. But if we get them started on 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 they could approach that difficulty early in the process. And then when everyone says, 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 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. Yeah, yeah. 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 27th 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 seven different portals that we have attached to it. A customer can access through any one of those portals with their credentials, state their question in a portal, and it queries out to the MongoDB database. We went from having 1,000 queries a day coming in to August 27th. We ran almost 400,000 queries the following morning between 8: A.M. 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 non-event in that regard. That's awesome. Yeah. Yeah. 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 started out with a relational system and said, okay, well, can you shard it? And I'm sure the engineer is like, yeah, we can do that. And then, okay, well, can you shard it again? And I think engineers are not the best about thinking of the overall business complexity and costs of, oh, 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 it was 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 talk a little bit more? And I believe Atlas, your counterparts were saying on stage too. Can you just talk about the topology that you need to support and how MongoDB helps you with that? Sure, so in our world, we have about 60 distribution centers throughout the United States, and we handle products from simpler medications such as regular over-the-counter 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. Yeah. Now, 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 make sure you have the operations to support that. And that's really. Yeah. It's one of our mottos 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. Yeah. 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 abou how we help you there? Yeah. 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 approached 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 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, 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 clouds 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 MongoDB is the cleanest implementation of bring your own key encryption that we've worked with. And so it's consistent across all the clouds, and it's useful when we have customers coming to us 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, maybe I'm dating myself, I think more of kind of an end user or a creative as a customer, but you were telling me basically in your business, you're really more of a business basis kind of application, right? Yeah. 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. Businesses who rely on our data day in and day out, 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 very easy for developers to get up and running. It's this 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. We can't get those even from the other cloud vendors, so we prefer to work with Mongo because of its enterprise capabilities. Wow. 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. I tell my teams, 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 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 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. Cool. Yeah. 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 four 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 three 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. 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 it's 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 to look at 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. No, 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, they 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. Oh, I see it now. Awesome. Hello. Hi, everyone. I'm Fred. Nice to meet you. Great to be here. I joined MongoDB one year and a half ago. I lead Atlas Data Services, and I will walk you today through our AI product strategy, where we are, 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 or live code an application. These tools are impressive. Love using them. They're fun, and they bring real value. 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. There 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. 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. 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. You need AI magic for that. And this AI magic is coming from the models, especially as 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 wants 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 three 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 you should watch next. It could be your e-commerce application if you want to buy these nice red shoes. And more and more, with customers, we speak about agents, AI agents, agentic systems. These systems, they need these agentic systems, they need memory, they need context, they need to model relationships between entities, they need accuracies, 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 two or three concrete examples to make sure we speak about the same thing. So first line, let's take a bank. And the bank wants 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 bank is to increase the satisfaction of your users and also maybe decrease the cost of your infrastructure. So your goal is really to minimize the number of times 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. If your user is asking you, okay, what are the limits on 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. Then you can combine that with many things that your Vector Search will tell you, like how to increase limits, et cetera, or the kind of problems that users are facing in the field. That's what we call hybrid search. If you really want to improve the efficiency of this chatbot, you will want to use the database and the Vector Search. A reranker. I'll speak about rerankers later, so that's probably a good idea for this one. I'll take another example, recommendation. Again, your e-commerce site, and you want these red shoes. You don't need an LLM. You just type red shoes or red 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 it. You probably don't need to know a lot about 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 five-star or four-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, so 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 needs durable memory, so you need durable memory because probably the vacation you took one year ago could influence the right vacation to advise this year. 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. Maybe you like boutique hotel, or maybe you like this kind of restaurant. 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 two 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're 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 products. You could decide, okay, I will take a database and an embedding model and a vector database and a graph database and a stream processing service, stitch them together, wire 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 responds to that with 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 these 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 one box that the auditor can go through. So overall, this natively integrated platform is helping customers 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 yeah, 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 will be a bit heartbreaking because that could be a long, long list, but our LangChain package, strong adoption, strong growth of adoption for the package that allows AI agents to build durable memory and context on MongoDB. We announced last week 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 projects 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 a run anywhere commitment, and we respond to very high customer demand. Earlier this summer, we announced hybrid R ank Fusion. 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 nice feedback about our auto embedding capabilities. This is a very first Voyage plus MongoDB native integration. So if you have a Vector Search on Atlas, Vector Search customer, you don't even need to care about your embeddings. We will 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. To come back to a couple of very concrete use cases, 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 scanned paper documents because they have many of those, these large companies. The Financial Times is really a recommendation. I mentioned an e-commerce example earlier and 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. They're 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'd never know which one you should use 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 two. Step two, 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 a reranking model. An embedding model turns unstructured data. So unstructured data is everything: text, image, audio, video. That's basically the data in the real world. That's the data that AI consumes and generates. The embedding model transforms this data into what we call a vector or an embedding, a very long suite of numbers. 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 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 two pictures are. You can retrieve an object in a video, and you can determine whether two 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 having billions of chunks of documents to perform their search right now. And embedding models would be super fast 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's a way to try to understand the difference between an embedding and a 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 the suspect. That's good. For some AI use cases, you really need to get the single document. Agentic systems, because they don't just recommend things, they act. Usually, they don't need, oh, these are the five or six best documents. They need the one because then your hotel will be booked or your restaurant will 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 embeddings. So now 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. Multimodal is basically you can perform semantic operation, mixing text and videos for examples. 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 a 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 have 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 says, in July 2002, the president, his wife, and his three 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 as an answer, wow, the president of the United States in 2002 had three children. And the chatbot may be even proud to say, wow, and these were three daughters and their name, et cetera, et cetera. If this document was part of a history book or a newspaper archive, that's great. That was a good answer, and that's what embedding models 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 matters 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 a 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 this link between LLM and data is so important. All right. So that was step two. 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 could. 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 which that it was, you could build one application, deploy the application once, and you could reach millions overnight. Then you have the cloud inflection points, which is about scale. You have to build, but 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 needs 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 makes 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 stored procedures 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 on 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 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 a very 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 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 five 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 super fast. So we stay humble. We focus on execution, but we also know that it plays on our strengths. 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. We believe we have the best platform for developers to build, launch, run, and succeed in their AI projects. Now we will transition to bring up three 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. We couldn't make it, but we are building incredible stuff with us. I'll let you watch that, and then we'll discuss in a few minutes. Thank you. If you're building an early-stage company that you think is going to be scaling very rapidly, you really only have one option in this space, and it's MongoDB. We believe that the world is transitioning to an agent-native world, and so we want to help organizations transition to agent-native development. Factory is a platform that helps bring agents into the entire software development lifecycle and help optimize and automate the different tasks that software developers do. Applications evolve really quickly, and so you're constantly looking for high performance, low cost, high scalability, and so we need to pick platforms that aren't just capable, but that are reliable. When you think about AI applications, a lot of the data is far less structured. A document database maps really nicely to a lot of these slightly more unstructured or perhaps varied in structure data models. We started working with Voyage as our embedding provider pre-acquisition. We were jumping around from VectorDB to VectorDB, and when we found Atlas, we were like, why didn't we start with this? We ended up switching to MongoDB Atlas. We've been using it ever since. The balance of scalability, reliability, and cost combined in one platform is hugely important for our team. We had to focus on building the application that we actually want to build. We are consistently exploring options across the entire technology stack, and one of the things that keeps us with MongoDB is that even as the technology evolves, we see MongoDB evolving with it. While other providers may fit a specific niche, being able to bring all of this together into a story is what matters most for us. Being able to rely on MongoDB to scale with our growth has been fantastic. All right, so we welcome on stage Sudheesh, Sean, Steven. Thanks a lot for being here. Where are you? I've been told Steven and you shouldn't be seated together, so I didn't know. We used to work together. That's why. Okay, awesome. It is nice to be able to. Yeah. Yeah, so great to see you. We talk a lot about our product, our vision, how we solve our customers' problems. 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. Hey, guys. I'm Sean Roberts. I'm a distinguished engineer in CX for Cisco, and very happy to be here as well. And my name is Sudheesh. I'm the CEO and co-founder of a company called TinyFish. Just got launched a couple of weeks ago. Yeah. 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 it works that way, but. Yeah, sounds good. Yeah, so one of the things at DevRev, we got founded right around five 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 in 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 Tech is a very common name and 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 Tech Engineer, or it's also called Cisco Support Assistant for the Cisco Support Assistant for Tech, 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. 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 just 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. 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 their P&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 what 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 a 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 re-ranking. 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 scales, unstructured data, what does AI consume? But 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 worker's time is spent on browsers doing three things. They're doing deep research. They're doing interaction, entering information, and the third step is extracting data. All of this needs to be extremely disciplined. It has to be deterministic, and websites in general are non-deterministic. So, how do you make deterministic things out of non-deterministic action that's out there at massive scale? Scale comes to play, which means that accuracy and performance matter. That's why we tried everything as well. The company is a year old, so we had the luxury of going at looking at everything new. 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. Oh, it's better. Yeah, yeah. Using embedding to grab a bunch of people and then re-rank and find the culprit is not a good idea. I'll steal yours. I'll steal yours. In my case, you can actually bring the entire catalog of your competition, embed them, and then we obviously have to re-rank 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 that scale. It's a hard problem, so re rank-2 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 stick out are two things. Number one is it's very accurate. The accuracy matters to us. False flags 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 a bit, but your story is interesting with MongoDB. Yeah, 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 of inside of tech, 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 the 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 went when we go into 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 could 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. Yeah, 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 four 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 service catalog tool, whatever it may be. 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? That was really kind of one of the key underpinnings that really led us to MongoDB and Atlas specifically. 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. It all came for free. That is 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. 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 is scalable, and something that is really pushing the boundaries of the future. That's really what I think Mongo is doing as well with Atlas. Yeah, that's awesome. Thank you for that. We may stay with you. What's amazing is that's totally on point with the two products. You have been through the full journey, and you are well past that, like scaling, integrating billions of pages to browse. Can you maybe share something you have learned and that could be useful for others? Yeah, 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? 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 over-pivot on over-prescription 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 six 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 clunky, very klugey. 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, so. Awesome. Great story. Thank you. Thank you, Steven. Sean? I would kind of go and echo on 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 in going to Mongo, 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 five years. I've written it like five 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. I think that is something that the virtual engineer team we really had, everybody was focused on solving Cisco's customer problems, right? That was really a pinpoint goal for us. Awesome. The dictionary did say regardless is a real word, but I still protest. They talked about two 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. My point here is that we are living in a world where AI is also highly hyped. 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 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 aren't 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 movie later. Let me find a 9:00 P.M. show. 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 word to buy, all of those 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 this. 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 from all the way to 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 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, it 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. 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 her this. Audrey was the one who made us decide like, okay, we will work with Audrey. Okay. Okay, she happens to be at Voyage. We only have one Audrey, but we have other folks that are great. Okay, 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 and 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 shifts that you anticipate, if you have some thoughts that you would like to share with us. Steven? Sure. Yeah, 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 toward me, and I want that. People have grown to kind of embrace that and kind of expect it almost. And so that's where 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. 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. 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? It's not just a cookie, it's a person, right? 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 two 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 two 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 things, 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. Awesome. I think for us, I think it really comes to the transition from when we started the coding and the engineer, it was transition from like text classifier, like generation one 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 is talking more the agentic flow, right? How many agents do we spawn 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 MongoDB back a lot of the agent work that we're doing. Y eah, for me, I think every 20 years or so, the internet gets rebuilt. The first versions of news groups to what Google and Facebook did, it has to evolve again. 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. Look, let's take back a second and think about why the internet. The 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 the 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 this, 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. You may have the best service, but you'll never be found. You'll never find the customers. Now, as we move to the next phase of it, from SEO to GEO, you don't even have patience for 10 links. You just want that one answer. If the answer is, what's the best green tea? 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're 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'm having 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 Hotel is the story. We told the story from a point of view of an eight-room hotel in Japan. This is a small hotel. They have eight rooms. They don't have a sophisticated stack. Hotel prices are always dynamic. You don't know the price unless you execute an exit 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'll 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 the artificial. It's also about intelligence for outcomes for humans. I do think that the internet has to evolve. We somehow sleepwalk 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 an ethically sourced, 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 learned 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, yeah, 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, change is 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 points 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 off these things. It's about truly getting the right intent. And then, yeah, I think the biggest thing is just embrace change. We don't know what we don't know. It's the wild west out there. Things are changing more rapidly than I've ever seen things change before. It's an exciting time. Just embrace it and go along for the ride. Yeah, I think for us, it's about just factoring it into the daily routine, right? Making sure that the folks know that it's more about making them operationally more efficient, right? We can produce more code, better code, faster speeds. We're still solving very complex problems, and we're not going to stop that. AI is 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? We're still going to have all that need for human engagement. I think that's a big thing. I think the other thing is to get our people trained appropriately on being able to do really good prompt engineering, things like that, so they make proper use of the tools before them. They just keep remembering they're 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 the 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 are 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 seduction. He knows me. We are getting started. We don't know the actual use cases, but you're using browsers. Do it at superhuman scale with the reasoning. Do amazing things for yourself and your clients and be part of it. There are amazing things happening everywhere. And like you said, change. Change everything. Change your job. Join us. Shameless quote. Listen, thanks a lot for being our first customers. Thanks for sharing your insights today, and I really appreciate it. Thanks. Thanks. Thank you. And we transition to May. May's floor is yours, I think. I'll find the clip here. All right. Hi. When the CEO of TinyFish was talking, I felt a little seen. Anyway, welcome. Three and a half years ago, I joined MongoDB, and I was given the challenge. Make self-serve the most efficient acquisition for MongoDB and do it in three 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 strategy is a 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 zero. 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. This might sound OK. I see. OK, thank you. We're also seeing AI-native startups choose this path to build the foundation for the next generation of applications on MongoDB. Together, these signals give us confidence that self-serve is a compounding engine driving growth that accelerates over time. All right, I'm just going to yell. Our self-serve motion has proven highly effective, even as our go-to-market teams moved up market 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 six years, self-serve has grown to more than 50,000 customers year-over-year, with more than doubled the number of net adds to our self-serve channel, from 1,300 in Q2 FY25 to more than 3,000 last quarter. Some of those customers are supported entirely digitally. Some are engaged by our scale 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. It starts with Mindshare, being top of mind for developers, architects, decision-makers when they think of evaluating modern data platforms. Then we move into education to grow confidence and competence. 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. The journey never stands still. We're constantly testing, refining, and improving. What moves prospects from the top of the funnel down to the bottom and then looping up again is the self-serve engine. Let's take a look at it. Self-serve works in three 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. First, search. 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 three 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 contents and forums 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 build. 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. 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 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 this is 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 forums, and combined with usage data and product telemetry, those signals fuel a discipline loop. I know Dev's 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, a higher conversion rate, 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 aren't one-offs. They prove self-service 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 engaged, 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 three years ago, throwing 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 up market 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. OK, 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'll 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 to the team for being so crisp, will 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 two 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 up market, 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 up market, 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 number one 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. This is being webcast. We will always lean towards growth versus profitability. But investment needs to come with a return. OK, so when we talk about the growth, that is the number one 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. OK, before we get started, though, we had a really good Q2. So this is a little bit of a victory lap, which is fine. We're going to take that time. The guy from Tiny Fish 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 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. OK, 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's 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 a force 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 green field 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. OK, and we talked about it. Hey, OLTP, and we have a lot of these questions in the investor meetings and 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. The question is when, but we think it's there in the future. OK, so that's the market backdrop. Now, let's shift to Mongo. OK, 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 2022, Atlas was about 56% of the business. We expect it to be close to 74%, 75% now. Interestingly enough, the last three years, Atlas has added about 400 basis points in mix for the last three years. One of the wonderful things about AI is we're not, hey, we think it'll be both form factors. We think it'll 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'll 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 three platforms on a year-to-date basis are growing very strong double digits across the board for all three. 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 three times growth. But Atlas has grown almost four times during that time. So it continues to take share. And we do expect Atlas will be the driver of growth going forward. OK, 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, oh, goodness. 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 the, 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 through 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 two 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. OK, so I wanted to tie consumption to revenue. OK, 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 multi-year 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 AI 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 AI. 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 2024 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 two quarters, it has largely been consistent at about 7%. And going forward, what we would say is we expect that to stay within the low to mid-single digits for the foreseeable future. We will see how we get in a couple of years. But as we look out for the rest of this year in 2027, that would be the expectation with obviously some movement based on the duration that we will get with our customers. OK, all right. A couple on the customer and the customer growth. This is a great chart. It shows that we continue to add customers above $100,000 in ARR and $1 million. Keep in mind, though, 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. The goal is to really go after the wallet share in those larger customers. If you look at it over the last, call it, three and a half years, we've continued to increase the average revenue in this cohort. 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. This is a big piece. We watch this very closely as it relates to the success of our move-up market. Yes, larger customers' ads are important. But we also want to increase that wallet share of those larger customers. OK, 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. I've said this repeatedly. I'll say it again. The number one 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. 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. 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. I know some of you are worried you're going to pull back too far in the yoke. 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. That's just, that's how we will drive operating margins up. We will invest. I'm going to walk you through that, but just lower than revenue and lower than gross profit. OK, entering fiscal 2026, 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 number one thing is around developer awareness. This is why what May's 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. Our developer awareness is huge. The areas that we're focused on, and you see it out here when you walk around, are 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 that, all the badging that they do. At this local event by itself, we're hosting five of them just today, so the focus on the marketing is really three things. One is a reinvigoration of our Bay Area activities, specifically related to AI natives. And you had one up here in SF 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 number one 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, 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 two areas, focusing on the core product, all the stability, security to move up market. It's 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's moving very quickly, so these are two areas we will continue to invest in. Of all the three groups, sales, marketing, R&D, and G&A, this is the one where you should see costs may come down as a% 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 up market, 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, and it was interesting. I didn't get it the first round, but this after earnings, this forward deployed engineer came up more than. Features, the substring, prefix, suffix. Yeah. Another thing we made a change like right now, it's not really a part of 8.2 release. But starting from 8.2, we're going to make all the incremental release available to all the customers, Atlas, EA, and the community. And at the same time, we are also extending our support for LTS, which is long-term support. It releases from three years to five years. So that means like you don't, like currently, if you want five-year support, you have to spend money to purchase two-year extended support. And you don't need to do that anymore. And for your mission-critical workloads, so you will get more stable environments. And you can upgrade less frequently. So you'll have more time to test. And you'll have more time to plan those updates. And also at the same time, we will be providing patches to those releases, including security fixes, critical bug fixes through the whole support. That's a big commitment to change to be pushing all these things out. Yeah, right. And to increase that long-term support. So I mean, I know that's kind of the behind the scenes or the things we kind of take for granted. But that's really important. Yeah, definitely. Because we keep hearing customer feedback about two totally different things. On one side, the customer who's running mission-critical applications, like legacy applications, saying, I want stable. I want reliability. I don't want to, I don't want change. I don't like changes. I don't want upgrades. So on the other side, for customers who's developing new applications, especially AI applications or agentic applications, they were like, I need new features. Every time when you have a new feature, I need to use it like now. So how do we change our release cadence? How do we change our release cycle to serve both sides, like both consumers? It's something we've been focusing on. So that is how, like what led to this change we're making in our release cycle. Well, we're out of time here. So I just want to thank you so much for coming on the podcast and chatting with us about this. And I appreciate all the work you're doing to handle both production loads that reliability. and no change, and the ones that want all the latest, greatest features and trying to juggle the challenges of that. Yeah, definitely. Very happy to be here, and thank you. Appreciate that.