MDB - MongoDB Inc. (MDB) Investor Session at MongoDB.local NYC 2023 (Transcript)

2023-06-22 17:38:04 ET

MongoDB, Inc. (MDB)

Investor Session at MongoDB.local NYC 2023

June 22, 2023 11:30 AM ET

Company Participants

Dev Ittycheria - Chief Executive Officer, MongoDB Inc.

Sahir Azam - Chief Product Officer

Michael Gordon - Chief Operating Officer & Chief Financial Officer

Andrew Davidson - Senior Vice President of Product

Michael Scholz - VP Product & Customer Marketing at Commercetools

Dave Conway - Managing Director at Morgan Stanley

Joe Crone - Vice President of Technology and Product Development at Arc XP

Chris Grusz - Managing Director, AWS Marketplace

Paul Blake - Senior Director, Engagement-GEP Worldwide

Conference Call Participants

Kash Rangan - Goldman Sachs

Fred Havemeyer - Macquarie

Brent Bracelin - Piper Sandler

Tyler Radke - Citi

Sanjit Singh - Morgan Stanley

Mike Cikos - Needham

Jason Ader - William Blair

Brad Reback - Stifel

Howard Ma - Guggenheim Securities

Rishi Jaluria - RBC

Ivan Feinseth - Tigress Financial Partners

Julie Bhusal Sharma - Morningstar

Miller Jump - Truist Securities

Presentation

Michael Gordon

Alrighty, thank you for joining us. To those of you in the room, thank you for being here. I hope you enjoyed the keynotes. For those of you on the live stream, welcome. I hope you enjoyed the keynotes as well. It's great to see a packed room here and I get to serve in one of my favorite roles, MC.

So our agenda today, we have got a lot that we are cramming in to three hours. But part of the benefit of tying this event from an Investor Day perspective to our MongoDB.local event is to you get a real sense for the products, the innovation, the new announcements, but also really importantly, how our customers are using our products. And so that really continues to be the emphasis of the day-to-day.

We know a lot of you cover lots of companies, and we are just one of the many companies. But what we do is, to us, really interesting, but also sometimes, inaccessible from afar. And so we want to make sure that we really help you understand what it is, how our approach is different, and how we are helping customers in the market.

So here's the agenda. We are going to run through a product overview, a number of the announcements that we covered this morning in the various keynotes. Sahir and Andrew will talk us through that. They will also then, because AI runs through so many different things, we have got a separate section on AI just to sort of help put that all into full context for you.

We are going to do a customer panel, which I think is one of the great aspects of this event is hearing directly from customers, how they are using MongoDB, what challenges they are solving, how it's impacting their businesses. Dev is going to host a chat with AWS, one of our many partners, but an important one. And then, I'll provide a broader update on the business.

What we will do is we will give a little bit of visibility into some of the Atlas dynamics that we have been talking about and also some of our customer breakdowns to try and shed a little bit more light in the spirit of the theme of helping to understand our customers and how they are using MongoDB.

Pro tip, this is not some sort of pivot where I'm going to announce some model shift or unveil some new long-term target model. For those of you who've been around for a while and followed us, we have pretty consistent in our messaging and our execution and nothing is changing there. So, I don't want to steal any of my own thunder, but probably worth teeing that up for all of you. But look forward to the conversation and the session that we'll have over the course of the day today.

The Safe Harbor statement, I will now pause for several minutes to let you read all this. But here we have the standard language that we have and really look forward to being able to get into the conversation overall. We'll start off on the product side. If you think about the market, we are pursuing one of the largest markets and one of the fastest growing markets in all of software.

The reason for this is, companies are increasingly needing to rely on their technology specifically their internally built technology to drive competitive advantage, right? That's where competitive advantage comes from. You can't get competitive advantage by buying off-the-shelf software, you need to build it.

And so therefore, when you hear phrases like software is eating the world or every company becoming a technology company or you hear about big banks talking about having more developers than large West Coast technology firms, that's really at the core of this. It's about driving competitive advantage. And so every application that people are building has a database at its core.

And that's why this market is so incredibly large, with 81 billion spent in 2023, estimated per IDC, growing to 136 billion over the next four years. Most markets, certainly databases have been around for a very long time. I tend to think of large markets and mature markets growing in line with GDP.

But part of the reason why this market is growing in double digits is because of that strategic nature, is because it every application at its core, has its database, and has the developer data platform that we're offering. But our market is different. It's not typical. Many of you are experts at pattern recognition. And I think it's important to call out here that we don't quite fit the pattern that you used to see.

Most markets are fairly monolithic. And by monolithic, I mean in that regard. When you think about the application stack, the basis of competition, the unit of competition is the customer. You win, all the customer or none of the customer. If you're providing HR software, if you're providing the ERP system, if you're providing the CRM, you tend to have the whole company running on your platform.

And if you're a challenger or an incumbent, you're locked out of that account, right? So if you're running an HR system, and a big telco or retail or whatever it is, one team is not on a different HR system than another team. They all run on the same thing. And so if you're, workday, and they're running PeopleSoft, you're sort of locked out until eventually you hopefully break-in and win the whole cap. That is not the market that we operate in.

Our competition is not binary like that. We're competing for workloads. As I mentioned, every application has its own database. And the result of that is that our unit of competition itself is the workload. And so you've heard us talk about the sort of land and expand model that we have. What this means is winning an initial workload, yes, hopefully that workload is successful, but the way and grows, but the way that we really grow within the account is winning additional workloads.

And yes, winning that next subsequent workload is faster, more successful, ultimately, economically more efficient, but you still need to do effort. You don't just sit back, kick your feet up and have the workloads flow in. Obviously, you can win them in bigger and bigger chunks as you become a standard with the account, et cetera, et cetera. But I think it's just critical to underscore the fact that a basis of our competition is the workload and that's how we gain share within an account.

When you think about an illustrative customer journey, here you can see a workload that first look workload. Every new customer relationship has to big again with an initial workload, and then an initial workload grows, the first couple years tend to be when there's fastest growth but the workloads to still continue to grow for many, many years.

But really what the opportunity is, once it's on boarded, that workload will tend to have its own growth behaviors, right? It tends to be a number of application specific factors, as we've talked about, could be affected by macroeconomic conditions. And the underlying ultimately is the underlying read, write query activity in the application.

But over time, the way you grow within the account is adding new workloads, right? And making them successful and you can be able to penetrate the account further. So I think that's important to set up in context for a lot of the things that we're talking about here today. Also separate from the market being incredibly large already, it will continue to grow because there will be an explosion in the number of new applications that are developed over time.

As I mentioned, the sort of critical aspect of competitive advantage is people are looking to innovate more quickly. You heard Dev mentioned that in the keynote, that's one of the key drivers. And so, more and more applications will be built and that will continue to be a tailwind for us in our business. Here, you can see the estimate from Microsoft, that more applications are built in the next 55 years than the last 40 years combined just to put one context or frame of reference.

Secondly, the developer really is at the center of this, the developers, the one who's driving this innovation, developer productivity is critical. And developers are the real decision makers in technology. And then lastly, in addition to developers and the need for all these applications to happen, there'll be other technological developments, where by more and more applications will be built to be a little bit of a democratization that will further accelerate the building of applications, all of which should benefit us.

And so our whole company is oriented around winning more workloads. This is not just a go-to-market orientation. Although importantly, it is a go to market orientation and that's a change, or that's a shift from winning a big multiyear contract on an annual subscription license or maybe you do a three year deal and you kind of sit back. This is much more focused on winning more workloads within the account.

But again, it's not just a go to market motion. This is also a focus across the whole company. And so when you think about the announcements today, and what we communicated, it's really geared around winning more workloads. And so we don't have time to go into all the announcements in great depth, because there were so many of them. But we're going to focus on a few, we're going to focus on the ones that are highlighted here, app modernization search, queryable encryption, vector search, and then streams as some of the announcements that we're most interested in digging into with all of you.

As I mentioned, we'll have Q&A at the end. But now I'm going to turn the stage over to Sahir, our Chief Product Officer to start with app modernization.

Sahir Azam

Thank you, Michael. Hello everyone. Good to see some familiar faces. So hopefully, you got to catch some of the keynote and get a glimpse of some of this. But we want to put a bit more context behind the investments we've made in the last year and the expansion of the platform. And to start, we want to focus on modernizing the existing legacy of state that sits and captures billions of dollars of revenue in the database industry.

As you've heard on stage from Dev, our foundational differentiation and technical advantage starts with the document model, the data model and architecture that we built the Company and technology on from the beginning. And the reason this is so powerful is because of three key reasons. One, document models are very natural for developers to be able to build and importantly iterate and improve applications overtime.

A well written app using MongoDB is also much more performant. If you think about relational databases they were optimized for a time in which hardware with disks were really expensive and people were relatively cheap. The equation is completely flipped today. Scalable hardware is available for anyone on a utility basis at their fingertips, but hiring developers and making them productive is the challenge that most organizations have.

So, there is actually a performance benefit to the data model and how it persists everything on disk. And that makes things much more scalable. We have a distributed architecture that can be able to scale applications horizontally in an efficient way. Now, it actually goes further than this. Another context around this is the idea of rows and tables in a relational database doesn't naturally map to the way application developers think. They think about objects. They think about managing a purchase or managing products in a catalog or customers or people as part of their application.

These are all objects, and that started to become the driver behind new programming languages. Object oriented programming rise over the last 20 years. So, one of the most powerful things about Mongo is that, a natural way to map object oriented programming directly into the data model. It's a perfect fit without a whole lot of translation or ORM technology to convert complex rows and tables into something that can work with the application. It's that intuitive experience that really drives this.

Now, our principal competition in the market is still legacy relational technology, right? And that shows up in a couple forms. There is certainly the proprietary large vendors, the Oracles or the DB2s or the SQL Servers of the world, but then there's also the open source alternatives. But fundamentally, the newer open source alternatives or maybe not so new in the case of things like Postgre have the same fundamental limitation. It's still a 40 year old architecture in data model that was built for a time of accounting applications on mainframes.

Now to be more specific, we see our customers struggling to innovate on relational databases for a few key reasons. One, as I mentioned, they are not optimized for the modern way developers work. They impose constraints on how fast you can iterate on an application. The idea of having rigid rows and tables with complex relationships, if you ever walk around, some of your IT teams floors and where the developers work, you will see giant maps, maps of related energy relationship diagrams, and how complicated it is to even understand them, let alone change them.

And this overall rigidity is what makes it hard for people to move fast. And in the narrow when anyone wants to innovate, this becomes a real hindrance. So, what do customers do? Modern application requirements are constantly growing, so they have to do something. They end up surrounding their core relational database, with a bunch of band-aids, meaning specialized, niche solutions for various use cases.

That could be, for example, key value stores, cashing systems. It could be a search engine, as I mentioned, on stage, with bolt-on more complexity. It could be analytic systems and mobile and edge synchronization services. These are all components that get added to a stack. And when I meet with customers, it's not like there is one complex diagram like this. Every individual application team has their own different cumbersome version of this. So, there is no reusability, no skills development, and repeatability inside of that organization. This complexity kills.

Now, why are people applying these band-aid solutions? They are doing so for two reasons. On one hand, relational databases are hard to get off of. None of these band-aid solutions -- excuse me, are able to fundamentally replace the transactional guarantees and capabilities of a relational database. So they end up being an adjunct. They end up being an add-on. Conversely, a relational database can't scale or add the different data models and manipulation types that all these different specialized use cases can offer.

So, on both hands, you can't replace one with the other, it just creates more sprawl. MongoDB is very unique because seven, eight years ago, we made a very intentional decision to focus on bringing forward a lot of the things people expect from traditional relational databases, strong consistency guarantees, schema enforcement, enterprise security. All the mission critical enterprise features to a modern distributed document oriented database, which places us in a little bit of an interesting place in the market, because we're so associated with the non-relational or no SQL sort of segment but in fact we're quite different than all of those because we fundamentally can replace a relational database system.

Now, getting off of these legacy systems is clearly hard. And this is a very even simplified description of what it takes, but just getting through it very quickly. The first is you need to update the schema. Modeling information in a way that's optimized for rows and tables in a relational database is very different than modeling data in something like MongoDB, which is a document oriented database. The way the relationships between objects works is much simplified, but it's not the same.

You then need to of course rewrite your code. So the application business logic, there's custom stuff that drives and innovates differentiates the software you're building that needs to be refactored at the very least, but oftentimes needs to be completely rewritten for a modern programming language or a new architecture.

And then, of course, you actually have to migrate the data and there's different ways to do this that we'll get into. But this is at a very high level, the process that happens for a single that migration. It does require a holistic approach. It's not just technology, we'll certainly discuss that, but it also requires people. It requires expertise and doing this safely, doing this repeatedly. And it requires partnerships to make this whole process work end to end.

So starting with technology, today, we announced the general availability of a technology we call Relational Migrator. We announced the preview of this last year, we've been working with dozens of companies with our presales and field teams on testing it and actually now running live migrations of real production application. So, we're really excited to see what we've been able to accomplish. And now, we're making this downloadable for everyone.

And it focuses on three key areas. First, we've built a UI that's beautiful and allows you to create a canvas for designing MongoDB Schema. So, it inspects the relational schema and allows you to map it and create a document oriented schema in MongoDB, all with drag and drop.

Next, it handles the migration itself. So, it actually moves data from the traditional legacy relational system into MongoDB. And finally, it helps generate sample code. So, now that we understand the schema, we can generate sample MongoDB queries that accelerate the development process.

We support a broad array of different database services as a source Oracle, SQL Server, MySQL, or even end to life databases like Sybase or cloud databases from our cloud partners. The destination can be MongoDB Atlas, or it can be a self managed MongoDB deployment of enterprise on premises in a customer data center where there's still quite a bit of modernization happening.

And on the migration itself, we support two models, a onetime snapshot, think of that as a bulk move of all the data once or a continuous change capture system where you have a running application, the changes that are in the source database are automatically streamed to MongoDB. And then the customer can flip over the application to connect to the new database when they're ready to avoid downtime as much as possible.

Now, we've gotten a lot of great feedback around this. I'm not going to read the quotes here. But the themes that are coming out are the stability and performance of moving the data is definitely an area customers are really impressed by. The other is the usability so that, design canvas of being able to visualize your existing relational schema turn that into documents, see what that new model looks like, helps developers rationalize, how to think about application code changes going forward.

Let's move on to people. We're also investing heavily in skills across the Company. One and most importantly, perhaps our professional services team. We have centers of excellence and skills inside of our services teams that are built on analyzing the right applications or components of applications to modernize to MongoDB. And the process to create a center of excellence at the customer site to do this repeatedly, not just for one application, but for many applications.

We're expanding our MongoDB University education programs. Today, they've been really focused on how to build with Mongo, use a technology or query language on new products. But we're adding new courses that are aimed at existing SQL developers. We're starting with a specific course, but then we'll have an entire learning path that we can walk people through to get sharper and sharper on the usage of MongoDB.

And last and certainly not least, one of the things we've really scaled up in the last year is our Developer Relations days. So this is where we take a Dev advocate, we fly them around the world, so one of our large customers. They gather together hundreds of developers, for example. We do a training on MongoDB and the differences between relational and Mongo and the benefits. And then we break off with candidate applications and get hands on and actually help them prototypes, they can understand how that app can translate to MongoDB.

It really just flips the switch in terms of the buy-in of how we actually can do this for applications that people would never have thought could be moved off of a relational system. And last, but certainly not least, our partnerships. So many organizations, especially in the enterprise have deep existing relationships with the global SIs whether it's Accenture, Infosys, et cetera. We've been working with them for many years on skilling up hundreds of consultants on MongoDB.

They have large app modernization programs, so we plug right into their overall go-to-market there. And certainly, this has helped us some of the largest most regulated companies that we work with. But we also work with thousands and thousands of smaller companies or even teams inside of large organizations that want to move a bit faster. And so,, we saw a need to create an ecosystem of more boutique SI partners. And these are smaller organizations that can drop on an application get hands on and accelerate that process. We call this Jumpstart. We actually have an ownership stake in many of these companies. You'll continue to see this expand as we go forward, seeing great results in just a couple years.

Now, we'll continue to invest in this across all facets, technology, people partnerships. This is a long journey. And we will tell you more about some specifics we're doing on the roadmap in the AI section later when there Andrew and I are covering. But it's important to note that we don't think everything will be ever fully automated, we're just going to constantly move the bar forward, make it easier, which is really important for us because it expands the aperture of applications that customers will consider modernizing because the cost and effort now makes sense.

With that being said, I'll hand it over to Andrew to cover Atlas search and all the new enhancements there.

Andrew Davidson

Thank you. Sahir. Folks great to be here today, I'm Andrew Davidson, SVP of Product at MongoDB and been here for Company over 10 years. So, I wanted to do a little bit of a level set on our search strategy. You hear us talk a lot about search and why is there so important? Well, I want you to think back to those applications you might have used back in the 90s, early 2000s. And if you think about those software applications, they kind of made it feel like you were just using a database directly. You would write data into some kind of form and you would write it to the database and then come back and it was kludgy and slow and frankly, you hated using that software.

What do you think about the software that you love using today? It's interacting with you throughout your life all day long. You're doing it many of you right now. You love this software, because it's totally been revolutionized by user experience design. And one of the key ways we have been able to revolutionize user experiences is powered by search. Search enables these natural language experience, search allows us to, allow end users to describe what they are looking for and tell them a recommendation or give them what they think they are looking for before they even realize what they were looking for or to do auto complete and so many other things let alone the classic looking for my item in an e-commerce catalog or many other use cases.

Now, the challenge has been that most application teams haven't had the sophistication to layer in an entirely separate search engine alongside their operational data store. Let me explain what I mean by that. Every application at its heart, as Michael was saying, has an operational data store like MongoDB. This is powering the core system of record for that application. But if you are going to try and introduce some of these search capabilities into your software, you are going to have to introduce a synchronization process, which needs to be governed. You are going to be moving data out of a database like MongoDB.

Traditionally, you would have to separately move that data into a search engine which means you have to stand up, operationalize, manage and maintain an entirely new technology, all of which requires significant governance and an ongoing burden. And then in your software application, you are now going to be managing multiple APIs, multiple connection dynamics to these different engines. All of this leads to complexity, and essentially represents an ongoing tax. This is kind of an example of those band-aids that folks can layer in, that Sahir was mentioning.

So we saw, there is just such a huge opportunity here to ask ourselves, since this is something that is so powerful, it shouldn't be reserved for those software applications being built by the most sophisticated teams in the world. If we can make this something that every software development team could build with then we massively unlock a lot of value for them, we make them more agile, able to build software faster. And we make it so that far more teams than ever before will be able to build the power of search into applications, which means all of us will benefit.

So that's been our philosophy with MongoDB Atlas and Atlas Search. We have fully managed on the back end, all of the synchronization, heavy lifting, all the complexity of building these rich search indexes. These are specialized data structures that make those capabilities possible. We make it so that a developer building software with MongoDB doesn't have to have all this expert specialty, knowledge into how to really think about search. They can be a MongoDB oriented developer and simply create a new type of index and through the same, elegantly integrated query experience, run those search queries adjacent to the rest of their application queries.

So this is an extremely powerful concept, and we have seen great resonance with our customer base on this, tons of builders organically just adopting and layering in this capability. To quote a few software developers on the platform today, not having to deal with the replication and re-indexing just makes their life so much easier. Not having to manage additional infrastructure. All of it becomes so much more efficient and easy to use. It's kind of obvious frankly.

But what we have seen is, such great validation and adoption that so many people building with this capability for the first time every month, that more and more large scale, mission critical search use cases are coming onto the platform, which is inevitable. They are growing up with us. And so, we thought to ourselves, what do we need to do to think for the future to be ready for this next level of scale, next level of sophistication? And so, we were very excited to announce today the private preview of our dedicated search notes.

This is an entirely new foundation that gives us the ability to independently scale the search portion of a workload, with optimized hardware, better availability. In other words, uptime characteristics, and we'll set the foundation for much larger scale use cases of the future. Now, the key point here to keep in mind is that as a software developer, nothing changes.

You don't have to think differently about your queries or index strategy. This is all of a back end detailed at Atlas brings to bear to make it so that you can go much bigger, but your software and your code, all of it is completely consistent in line with our vision of continuing to be elegantly integrated into our developer data platform.

So if I jump into another topic, if search is about enriching every kind of software in every kind of industry, in every kind of vertical, all over the world, because that's how ubiquitous search is. Well, we also need to think about some of the most elite mission critical special characteristic workloads and industries and think about their special requirements. And we have to make our investments there as well. So that brings us to a very different topic, which is Queryable Encryption.

The topic of data encryption is nuanced, it's complex. There's a huge amount of academic research here. But it's only a partially solved problem. If we talk about data in transit or encryption over the wire, there's standards here that are well established. TLS network encryption, which powers HTTPS, which powers that little lock icon in your web browser that tells you, I have an encrypted connection to my website, great.

And then separately, for data at rest, we also have a pretty well solve problem. If someone were to steal the hard drive out of the back end of a server, without the encryption key, all they're going to be able to see a ciphertext from that drive. That's extremely important. But it turns out that encryption in use, which -- or sorry, data in use, which is basically the data in memory on a server, for example, where a database is actually actively querying that data is not a solved problem when it comes to encryption.

And this has, frankly, some threat vectors associated with it. There are challenges of the inside threat from the service provider, the kind of who's watching the watcher type scenarios, which requires trust of the service provider. And there's always levels of trust but you can never be perfect yet.

And then there's separately this concept of CPU side channel attacks, which you might have seen in the news a couple of years ago, these occasionally rear their heads and essentially allow you to potentially access memory from one virtual machine on the same physical machine as another, which is a huge problem. So, there's been a lot of people looking at this for a long time, but it's tough.

Up to this point, essentially, you had to decide. You're either going to have your data encrypted in use or have it be queryable. You couldn't have it be both. And this is essentially one of the hardest problems in computer science. It's at the intersection of advanced cryptography and database engineering research. There are many people in academia and research labs who focus on this problem full time and you hear about a lot of different ways of tackling this problem. And traditionally, it really, no one has, until recently seen a path.

So if we think about a simple two by two where on one dimension we ask ourselves, do we have expressive queries? And on the other we ask is encryption in use? Most databases offer at least some type of expressive queries without encryption and use, some databases including MongoDB offer encryption and use, but without expressive credibility. MongoDB offers this in the form of our client side field level encryption, which was launched in I think 2019.

But we realized that research and academia was getting to the point where it was ready to enter the industry. We actually identified a small team and acquired them out of Brown University researchers there about 2.5 years ago. And we spent the subsequent time bringing that capability into our platform, which has allowed us to become the first leader in industry showing what can be done with queryable encryption, which brings expressive queries to encryption in use.

We're very excited to announce the general availability of this queryable encryption capability. In our upcoming 7.0 release, we made this announcement today. This is a really big step forward in the industry. Very specifically, this is targeting rent equality match with randomized encryption. This is a specific subset of the ultimate long-term roadmap for us to do more and more expressive queries, all while preserving this encrypted attribute over time.

So why is this important? Well, we think about these industries that build critical software for all of us that we all rely on healthcare, financial services, government and more. We want to ensure that the next generation of software applications built in these crucial regulated industries are built privacy optimized from the ground up from day one, all of us benefit from this. We at MongoDB are focused on ensuring that these types of industries can get to that next level in line with our broader ambitions to enable builders in all of the crucial industries in this world.

So, with that, back to Sahir.

Sahir Azam

Alright, let's talk about stream processing. I think this was one of the announcement that surprised people today based on a couple of comments I heard in the hallways. I'm really excited to get into it. So streaming data in some sense is everywhere. A lot of the experiences that we are used to day-to-day in the software we interact with is, powered by data in motion. You think about a hyper personalized experience in an e-commerce site or that perfect Instagram ad that tries to tell sell you something you don't want to actually buy, but end up doing anyways. All of that is fundamentally powered by streaming data.

But that expands to the enterprise as well, whether it's manufacturing and IoT, where you're collecting massive amounts of information from a factory floor or driving application self-driving, where you need to reorient the pattern automatically based on current conditions and traffic. And of course, financial use cases, fraud detection, intrusion events, for security, et cetera, are all powered by real time data.

But in order to make this real time data usable for an application, it's quite complex today, there's a few components that are necessary. One, you need a streaming transport technology. Here Apache Kafka is the most prevalent, but there are also proprietary products on the major cloud providers and alternatives that are open source as well. You then need a stream processing layer, either something that's homegrown and built from scratch, or an off-the-shelf solution that can actually query the data as it's flowing through this plumbing in this transport system.

And, of course, for the important data that you need to persist and maintain over time that lands in an operational database at the heart of the application. Obviously, MongoDB is quite prevalent and popular in this and we've really changed the database industry because of that intuitive document based approach our scalable architecture, the reach of outlets, all those characteristics. And we see an opportunity to do the same thing in the stream processing space. This is how we're doing it.

So, first and foremost, existing solutions have some limitations. One, they're all fundamentally based on the same rigid schema model and SQL interfaces that are unnatural for developers to work with. Same problem is the database space happening again in the stream processing space. Introducing a dedicated stream processing layer adds again another component to that sprawling architecture that you might have seen Dev presented earlier. It's more complexity, it's more cost, it's more operational maintenance, it's more to secure. It just adds to the mess.

And of course, the developer experience is fragmented. The developer is not just working with one interface in API now. They're dealing with multiple drivers, which bloats their application. They have to authenticate it kind multiple databases. It becomes more rigid, more brittle. So Atlas stream processing focused on those three challenges in particular. First and foremost, of course, by centering it around the flexibility and intuitiveness of the document model, we brought forward all of those characteristics, our idiomatic drivers, our natural way of working with data to stream processing.

We focus on continuous processing. So our query engine no longer just focuses on data persisted in MongoDB or static systems, it actually can query data in motion as it's flowing through something like Kafka. And it integrates for the first time in an intuitive way, data and databases, data at rest as long side data in motion into one experience that can power an end-to-end application.

We are very excited about this. The customers that we've shown this to with our demos and preview were blown away the sophistication and ease of use. It has that MongoDB experience that they expect. So net-net, we're bringing that entire experience, not just from the database market, but bringing it forward to the entire streaming ecosystem. You'll see out-of-the-box integrations that we're releasing in preview and we'll continue to expand to more platform players over time.

So, we talked about a few different areas of expansion of the Atlas platform. You want to take a break, you want to keep going -- we're going to keep going. All right. But now we're going to talk about everyone's favorite topic in the industry, AI, and we're going to get into some specifics about how it affects MongoDB and what we're building and doing around it. There's really four key things that we've observed and thought about over the last year or two as this trend was really starting to take off.

One, we fundamentally believe that AI will increase the volume and sophistication of applications being built. There's going to be more software developed. And that's going to mean that there's going to need to be more operational data and more databases backing them. We believe some of the inherent benefits of MongoDB that we just talked about previously, apply even more so to applications powered by AI and automation. And there are a few key components we think are necessary for these modern applications, vector search being a foundational element.

And last, we believe that, that app maturization journey from legacy relational systems to a modern platform like Mongo can be revolutionized with automation and AI. So, let's dig into this. First, let's talk about the volume and sophistication of applications. Now every time there's a platform shift in IT, the volume of applications and the sophistication of those applications increases by an order of magnitude.

This goes all the way back to the 70s, when you think about early mainframes in the '60s and '70s, there are probably hundreds of software suites tens of softwares and suites that were used by a subset of enterprises. Over the '80s and the '90s, client server architectures and package software became something that all knowledge workers could use. We could do spreadsheets for the first time, word processing, et cetera. But it was still a lot of packaged software.

But now we're talking about hundreds of software suites, maybe in the thousands. Then we started to see the simultaneous growth of mobility and smartphones and cloud powering the back end. And that really led to this massive explosion of all the interfaces and applications and software eating the world, all the stuff that we've been adjusted to over the last decade or two.

We believe that AI is that next platform shift. And therefore, as software becomes easier to create, more sophisticated and more automated, it will be necessary that there are going to be tools that have to power that, that don't exist today. And it starts with the development of the app itself. You've all seen things like GitHub CoPilot that make it easy to -- for a developer to be more efficient. I demoed the ability to convert SQL code, to MongoDB code easily using generative AI.

All of this just means that building software will be easier. And it means that the definition of a developer is actually changing and expanding over time. AI-driven applications are also more data intensive. They process higher volumes of data. The experience needs to be increasingly real time and since users are spread across the world, interacting with these applications now with natural language or audio and voice, the data needs to be distributed in low latency, not only at the cloud, but also at the edge.

Applications can get more powerful. Now we have ways of interacting smartly with video, audio, geospatial data, pods, poms, unstructured text in the same way we've traditionally dealt with structured data. And it democrasizes the experience of software even further across the world, you no longer need to be in front of a laptop or an iPad or even with a smartphone. It will be embedded in our daily lives in things like AR, VR the ability to interact in natural language. All of this is driving that growth, expansion of software.

Now as you all know and as Michael mentioned, we're fortunate to sit in one of the most dynamic and fastest-growing and largest markets in all of software. The numbers here, as I'm sure you all know, that are projected to grow by analysts over the next four or five years. These don't even account for the explosion of applications that are coming because of generative AI. So, we think this is a market expanding opportunity as this platform shift occurs over the coming years.

Now at a basic level, we see AI as a driver for these applications. And even if we did nothing at MongoDB, we just continue to execute our core operational developer data platform vision, we would benefit from this trend. And in fact, we're already starting to see that. Now what does an operational data layer need to be able to support these sophisticated AI apps. There's a few key characteristics that are worth digging into.

One, AI-powered apps need to deal with a versatile set of heterogeneous data. It's not just structured information rows and tables. It's not even just documents anymore. Applications need to represent the real world, be able to understand and process images and video and voice and text all together in a simple way. They need to be able to efficiently handle rapid iteration.

One of our product VPs like to say we're in the AOL era of this new AI-driven application movement, which means that there's going to be a lot of change, a lot of experimentation. You can't do that in a system that's rigid and with a fixed schema that doesn't allow teams to work quickly.

The scale of applications that will be developed over the coming decades will be much bigger than anything we've ever seen because it's no longer humans necessarily sitting in front of a laptop screen clicking with a mouse, it's actually software driving software, machine-to-machine communications.

I mean given an example. If I have to take a trip, I go to Expedia buy my flight, I book a hotel on marriott.com, I figure out what tour I want to go to restaurants I want to go to, maybe it takes me an hour, that's a certain level of scale and processing required to make that happen in time. But now AI agents can automate that whole thing in a matter of seconds. So that level of pressure that's going to be put on infrastructure will only increase as automation and speed of processing increases in an automated way.

And of course, data needs to be very differentiated. Even at Apple's announcements recently. You can see how they're doing language models on the device or privacy. So you can't just rely on data to be sitting in the cloud. You need this to be something that sits in a factory floor, a data center, multiple public clouds and even edge and mobile embedded devices, as Dev mentioned earlier.

Now what is MongoDB always been known for? We're known for, first and foremost, the flexibility of dealing with heterogeneous data. That's one of the main reasons people use MongoDB is you can easily model all these different shapes and types of data. We support a broad array of workload types, so you can iterate fast without having to bring in new technologies, integrate it into your stack, learn it, scale up your teams. It's just right there at your fingertips.

We're best-in-class at efficient performance at scale. You can build massive applications. Some of the largest applications in the world already run on MongoDB. And we're a leader in global reach and multi-cloud, whether that's the 110 regions across the three cloud providers, the ability to go on premises or the ability to move data seamlessly between cloud providers. And you all know AWS, Azure, GCP, are great partners. They're investing millions in new AI services up the stack. But for an organization to leverage that, they need to be able to use their domain-specific or proprietary data with those services. We're the only platform in the world that can seamlessly move data around the globe and across clouds in a matter of minutes by just clicking a button. So we think we're well set up for this trend.

Now all of these competitive advantages I mentioned become even more relevant. So we're excited. We're starting to see this already in our customer base. On the earnings call, Dev mentioned, we have -- we're aware of at least 200 customers that came on in the last quarter. We have thousands that have got AI or doing something with AI features in the platform today. And we're really excited to see this coming in and changing the dynamics of what our funnel looks like every week.

One of the things Andrew does is scrub the list of new companies and investigates what these companies actually do and some of the more interesting examples or something worth talking to maybe over coffee later. So that -- the first two were really about the core platform, how our foundational technology is well suited for this wave. Andrew is -- going to hand it over to Andrew. He's going to get into more specifics around how we're expanding the platform with new capabilities to make it even stronger.

Andrew Davidson

So, let's talk vector search and vectors. This is a really big topic and there's a huge amount of buzz around this in the industry right now. So, I'd like to demystify it for you. I think it's a little bit -- it's ambiguous at first. What's going on is -- there's been a democratization of a technology that's actually been around for a long time.

If you think about applications you may use like Shazam to find out what that sound playing on the background is or Google's reverse image search, maybe you took a picture of a flower and you want to know what's that flower. Those applications are powered by the same technology. So it's been around for a long time.

What's changed more recently? Well, in the last couple of years, really the last two years, I would say, there's been this proliferation of off-the-shelf machine learning models that you can use almost like a library as a developer. Without having to have the sophistication of being a machine learning or data science engineer, you don't have to go build the model, you can just use the model.

So what do you do -- what do you use these models for? Well, what these models do is they allow you to summarize any kind of source data that could be images, video, text, a sound bite. They allow to summarize that source data with a numerical representation of its meaning. And this is referred to as an embedding. The numerical representation is called a vector, and this concept is called embedding.

So what the heck do we really mean by this? So let me give you an example. We're going to go back to math class for a second here. I know you're all quantitative. That's going to be great. Let's talk about a simplified two-dimensional vector space, in other words, a plane in a two-dimensional vector space vectors are points on the plane.

So here, we have four vectors: pen, pencil, notepad and book. If you think about it, the computer doesn't know what a pen or a pencil is. We know, but it doesn't know. It doesn't know what notepad or book is. But if we have a machine learning model that can understand the meaning of what pen and pencil are and map that into a numeric vector space that puts them closer together then the computer can understand that pen and pencil are more related to each other, just like notepad and book are more related to each other.

And that's a powerful concept because it means I can now start doing these nearest neighbor style results. I can say, I think I have a pen here, but tell me what other things might be like a pen that are available to me. And if we generalize this concept and imagine that we could summarize any kind of source data with a variety of different kinds of machine learning models that can create these vector embeddings then I can do all kinds of cool use cases that I'll talk about in a minute.

Now it's worth just reiterating that these vectors, they're really optimized for how computers can do calculations. Computers are good at doing these massively parallel vector distance calculations and new indexing technologies actually make it so you can very efficiently do some of this in a database context. So let's talk about some of the use cases.

Well, there's the classic semantic search use cases, which is essentially an expansion of traditional search, where you're encapsulating meaning. So for example, if you're searching I don't know, a corpus of assays, and you want to describe the meaning of what you're looking for, it's not necessarily going to be a keyword-based hit. You want it to be an intelligent enough engine to find what you're looking for.

But you can generalize this beyond text into images like we were talking about into video and sound bites and more. And if we think about -- what's -- I mentioned that this whole thing has become really interesting in the last two years because you can now take advantage of off-the-shelf machine learning models.

Well, in the last six months, this whole thing has gone into overdrive. And that's because Vector search is extremely powerful in connection with generative AI applications built on top of large language models and other generative models. This is a different kind of model than the type of model I was talking about before, if that makes sense.

So in the last six months with the rise of ChatGPT, a bunch of new standards, which I'll walk you through in a moment, for building these generative applications, take advantage of vector search. And you can use them to do expert systems, question-and-answer experiences, you can do conversational support, you can do personalization, et cetera, like never before.

So let me walk you through a sort of simplified diagram for how some of the most popular frameworks for building generative AI-enriched applications look today. On the right side, we have the application interface. This is where our users will interact with our offering, maybe this is a simple expert system style almost like a chatbot that's going to bring to bear our unique knowledge base.

Well, on the left side, we have the domain-specific knowledge or data that we have available, maybe it's the data from our knowledge base that has information that we uniquely have and can make it useful to the person who's asking for it. The way you build one of these applications as you pull data from your knowledge base in this case, which could very likely be running in your operational data store, MongoDB, for example.

And you pull it into this embedding creation preprocessing step. And essentially, what you do is you break it up into chunks and you send the raw data over to your operational data store, so it can be used in the application. I'll explain why in a moment. And you separately send the vector embedding to a vector database or vector search engine off to the side.

Now the way this works is a user will come in from the application with a request, maybe asking, "Hey, how do I do this thing that I'm trying to do?" And There'll be a little bit of a processing step where that request will be parsed and it will be sent through the vector search engine. What's going to then -- what that vector search engine will allow us to do is find corpus -- find information in our knowledge base that's related to what the user was asking for.

And that will allow us to point to the actual raw data that's in the operational data store. And then we can use that raw data to do a prompt engineering step where we can start feeding this data in a piecemeal way chunked up appropriately through a large language model and, in turn, return a cogent intelligent sounding response to the end user taking advantage of what the large language model can do to make it sound intelligent, but base lining it to the unique knowledge that we had in our application and our unique business.

There's countless applications for this. And this is how you can avoid hallucinations because you're anchoring it in context that's relevant to your business. Now this is an application like any other, meaning it has plenty of other use cases for its operational data store, maybe the user profile stored in the operational data store.

Maybe information about the history of what questions were asked and what answers were provided is sort of in the operational data store. No doubt you'll be asking your user, was this helpful for you? Was it not? What's next? All of that's going to be tracked in the operational data store. So there's kind of a loop here that inevitably happens.

Now when we look at this diagram, it's somewhat complex. And like Sahir said, this is the very beginning, these frameworks and standards will now that evolve very rapidly, and this is kind of a simplified view. It's somewhat complex, and we can't help but notice that this is totally ripe for us to think about, "Hey, it looks like there's another band-aid here, another niche off to the side, layered in database or vector search engine, clearly, there's something more we could do.

So, that's why we were so excited to announce today, what I'm personally most excited about the public preview of Atlas Vector Search today. We were able to make this the public preview today because we've been in private preview with this capability since the fall. And I'll point out, that was before the rise of degenerative AI ChatGPT wave.

The reason we were early movers in this is we solve the need for this in connection with this democratization of those models that I was mentioning before. And all of this has gone into overdrive in the last six months. And so we just feel we feel really good about the fact that we've been able to bring this public so quickly.

So what we do is bring vector search elegantly integrated into the exact same context of your operational data store. In other words, a vector that summarizes information sits alongside the information. It summarizes so it can effectively be used as an index to pull that information back. I would point out that a vector without the information it summarizes is somewhat useless, frankly.

And so it's a really natural fit for MongoDB where you have this document model to be able to just embed the vector right there. Now the vector embedding step involves partners. Sahir mentioned many -- this is a prolific ecosystem. You do those generate those vector embeddings through our partner in Google Cloud Vertex, OpenAI and Amazon Bedrock or you can run your own models to do all of that. So we're operating with a very open and pluggable approach.

So let's review the diagram again. This is where we are today as of today's public preview. We simplify the heck out of this loop. Your software application, it interacts with one operational data store that also includes vector search. It's kind of obvious I'll grant you that. But the large language model is a crucial part of it in the loop.

And if I were to -- Sahir was mentioning that I've certainly been tracking many interesting customers that are building on this kind of a framework. One thing I'd mention is it doesn't have to be a language model. This is you could think of this as being a simple example, but you could also be doing image synthesis, for example, with a stable diffusion style model.

As an example, we have a customer that creates a platform for fashion designers to basically describe what they would like to see in textiles and it will synthesize a bunch of fashion suggestions for them. And guess what, they go through and look at them and they point out, which ones they think are good and which ones are not good. And all of that is used in a training loop.

So, there's lots of different scenarios for this. Another good example of a customer that's doing predictive maintenance by listening for sounds in a car motor. And if they hear certain sounds, they believe using vector search that it's time to bring that car into the shop.

So vector search is such a critical logical expansion into our developer data platform vision, elegantly integrated right at the fingertips of a huge number of software developers to build these incredible next-generation semantic search and increasingly generative AI-enriched applications.

Thank you. Back to Sahir.

Sahir Azam

Thanks, Andrew. So to wrap up the product section, we're going to come back around to application modernization. So as I mentioned, modernization is very hard. Getting off of any database is sticky. It's complicated. It's live operational systems. I walked through a simple process from updating the schema to rewriting the code to ultimately migrating the data itself.

Today, we took a pretty big step forward with the general availability of Relational Migrator, as I mentioned earlier, and we solve parts of that overall process. But what we're working on next is taking some of the technologies that Andrew has mentioned and applying it to the change of code that's actually necessary. The queries in the application code, that's one of the most challenged parts of a modernization exercise because it requires development time. It's very error prone. How do you make sure something is consistent? It's heavily iterative.

And so, we're working on two key initiatives right now with the future of Relational Migrator. The first is SQL query conversion. So, we're building capabilities and we saw some of this on stage if you watch the keynote to be able to inspect an existing application, understand the SQL queries that interact with the legacy database and automatically translate that to MQL, so Mongo's query language and our aggregation framework.

We can do this for simple queries, and even stored procedure. So the business logic that often sits in an Oracle system or whatnot can be unwound and turned into logic with MongoDB. We're using fundamentally an LLM that we're trading behind the scenes as well as a foundational public model to make this happen.

The next phase is to move up the stack and to actually help with the customers' business logic across different parts of the life cycle, everything from assessment, so understanding the interdependencies and the business logic and the code, so you can start classifying which apps you can save the most money by modernizing, which are going to be the most complicated to modernize, et cetera, as well as the actual code conversion.

So being able to move from a traditional language like Cobol, for example, on the mainframe is something more modern. And of course, the last piece is testing. There are a lot of -- we're working with some partners actually as well that are working on automated testing by generating test suites to be able to compare like-for-like software and be able to make sure that the functional requirements as well as the performance are equal, if not better, to the original application. So, there's going to be a lot of innovation happening in this space across our ecosystem.

Now as I mentioned earlier, we don't believe it will ever be easy or push button, but we believe that AI can make a step change in the amount of effort of these different levels of the process. And every time we make it easier to move from our legacy database on to Mongo DB, customers move more applications over to us given the benefits around performance, scale and flexibility that we've been talking about all day.

So we're very excited about this. This is an area where we're doing some real R&D work, experimentation. The ecosystem is changing almost on a weekly basis right now. And so we're super excited. So hopefully, we walked through comprehensively first and foremost, how this trend in AI is a beneficial to MongoDB no matter what we do, we're just well suited for it on the basis of all the work we've been working on for 15 years. But more importantly, we're also investing to be a leader in this space.

I think the next piece here is our customer panel. Definitely, if you have questions, the team will be around. We're happy to dig deeper on any of these. Hopefully, this gives a good broad brush and some background context behind what we announced today. Thank you.

Michael Gordon

Thank you very much. I'll jump down here. All right. Thank you. Please come on to the stage. All righty. So hopefully, that was a helpful overview from Sahir and Andrew on a whole bunch of the product announcements that we've had, and we look forward to continuing to talk about those over time.

Now, I'm super excited to host our customer panel. It's always one of my favorite things of our investor session. So welcome to all of you. Thank you for coming. Why don't I just first started off by letting you each sort of introduce yourself let the audience know who you are, your organization and kind of your critical IT priorities, and we'll just dive right into it.

Michael Scholz

Sure. My name is Michael Scholz The VP of Product and Customer Marketing for Commercetools. For those of you who don't know Commercetools, Commercetools provides the leading composable commerce platform giving our customers all the independent and required components to run outstanding shopping experiences across all different touch points. We are lucky to have some of the most iconic brands, and we can call them our customers. So, we're talking Lululemon, Sephora, Auto Beauty, Audi, BMW, Volkswagen, and I could go on and on.

And these customers are choosing to run Commercetools because they require that sophistication, that scalability, that flexibility from their digital experience and digital commerce platform at lower cost but also by increasing or increasing efficiencies. And so we've been on an amazing trajectory. Last year 2022, we had a growth rate of over 80% in terms of our reoccurring revenue. We have similar aspirations to continue that trend. And MongoDB is just such a tremendous partner for us because for us, every customer is by association, a MongoDB customer.

So that's kind of like a little bit about me and about the Company in terms of the priorities that some of our customers are facing. I think it's the typical thing about change is the only constant. So whether it's geographical sort of tension, whether it's pandemics, whether it's sort of changes in demand or customer expectations, the reason why companies come to us for mostly from our competition, by the way, which are the likes of SAP, Salesforce and Oracle because they are limited in their ability to execute and they need that flexibility and they need to come to us for an answer on that.

Paul Blake

Thank you very much. Hello, everyone. My name is Paul Blake. I am from GEP, another company you've never heard of. So we've been in business for about 25 years. And we provide software, strategic consulting, and managed services to some of the world's largest and most interesting companies. We do that in a specific area, which is around procurement and supply chain.

So as over the last two or three years, supply chain has been very much in the focus and in the news and on everybody's minds. So, we've been working extremely hard with these large organizations to get everything right and to get supply chains and their procurement process is working properly. And that has to be done in software today. We're a software company. We -- as I said, we've been in business for about 25 years. I've been with the Company for 11 years and the changes that we have seen over that time have been remarkable.

And today, the challenges that our customers are coming to us with are all about, how do they manage, as Michael said, a changing environment, a rapidly changing environment, one which is no longer predictable. And yet, we're talking here about the oil majors, about pharmaceutical companies, global banks, the largest, most complex companies in the world, and they have all of their processes set in stone from about 20 years ago. The world doesn't work that way anymore.

So, they are now coming to companies like GEP and saying, we need agility, we need flexibility. We need to be able to work in a completely different way, but we need to be able to change that again in the future when the geopolitical circumstances change when the environmental circumstances change when regulations change.

So how do we do that? And the heart of that is how we manage data. And so, that's why I'm here today. That's why we're working with MongoDB. And it's in order to abstract all that stuff that's going on in the data into a format that the customers can use to manage their businesses more effectively.

Dave Conway

I'm Dave Conway. I lead a team of data engineers, analytic and reporting developers as well as data management infrastructure engineers at Morgan Stanley on the institutional security side. That's a mouthful because we got a lot of data. And data is front and center. It drives everything that we do, and it drives data science. Without good data, you don't have any science, right?

And my mom reminds me that every day, she calls me up, she goes, are you doing AI? I go, no, but my data drives AI, so she's very happy. So that's my going life. So the challenge is in front of us, primarily are AI and the cloud. I'm going to talk a little more about the cloud today because it's on my mind, and we've heard AI about 1,000 times. It's cloud, cloud, cloud. We're early in our journey, but we're quickly accelerating. And a platform like MongoDB Atlas has been an incredible enabler for us to get to the cloud very, very quickly.

Joe Croney

Good day all. I'm Joe Croney, Vice President of Technology and Product Development at Arc XP, which is a division of the Washington Post. And as you all know, the Washington Post is all about content as is Arc XP. We're a SaaS platform that combines an agile CMS with a digital experience platform and a monetization engine that powers thousands of sites around the globe today, full of content. And that's one of the reasons we rely heavily on Mongo, both at Washington Post for its own purposes, but also the customers of Arc XP.

We've got about 4.5 billion documents in our Mongo databases today, that appear in many different forms, whether it's video assets, audio assets, imagery or content articles. And one of the reasons we really love working with Mongo is the partnership that enables us to be agile and move fast. The story of Arc XP is one of hyper growth that has challenged our teams to move as quickly as the market wants us to innovate, but also to scale up the services we offer to our customers. And the Atlas platform has been fantastic in enabling our business transformation.

Andrew Davidson

Terrific. All right. Well, hopefully, that overview is helpful. One of the things that I think is really special and that we try and do during the session is give people some more detailed insight into how people actually use our product, right? It's easy for us to say it much better for them to hear it all for you from you. So maybe you can walk us through the use cases where you're using Mongo today, take it in any order.

Joe Croney

So, I'll dive in, start off. So as I mentioned, Arc XP is about content. And so when we went about selecting the right technology choice for storing our data, we knew we needed a document database, but there's many options out there. Prior to joining Arc, I'd actually been part of a firm that did our own custom implementation. So I knew the mistakes that you can make if you select the wrong technology.

One of the reasons Mongo really fits us well is that data store, but also because we're offering a SaaS offering, we're cloud native. And so we really required a partner that knew how to operate at scale, knew how to take care of security, knew how to take care of encryption, really could scale with our business. So when you think about when you access any site that runs on Arc today, that content originates and is stored in a Mongo database. We also leverage some of the services as well as some of the upcoming ones that are pretty exciting that we announced today.

Unidentified Company Representative

Yes, I'll go next we'll intonate along the line right. So procurement and supply chain processes are about transactions, as you would imagine, it's everything from purchase orders and invoice type transactions to informational transactions between different players in the supply chain. And of course, you can conceive of managing that through a standard relational database architecture. We have done that 25 years ago, that's exactly where we were coming from.

But now the requirement is for real performance. We are talking about hundreds of thousands of users at any one time on our system, millions of transactions, we process trillions of dollars of transactions through our system every year. And that has to happen very, very quickly at very high levels of security and very high levels of integrity.

And to be able to do that and deal with changing requirements, to deal with the fact that tax regimes change and political regimes change and the processes of purchasing and supply chain and the transition of goods from one place to another are ultimately affected by different rules, perhaps sometimes on a monthly basis.

You have to be able to be very, very flexible and to adapt to the new requirements. So having the old model, as we saw on one of the slides earlier, of an ERP and enterprise resource planning system that is heavily specified and setting concrete, it just doesn't fly anymore. We need something that is much more adaptive. And as we'll go on to talk about AI is going to be a huge part of that.

Dave Conway

So we have numerous projects running on MongoDB right now, but I want to cover a few and highlight some real success stories we've had the first and one of the earliest projects we went live with as is our risk calculation environment. Think every night, a financial institution like Morgan Stanley had to calculate its risk. This is a tremendous calculation requirement. This is huge massive calculations. And MongoDB provides the database behind all of that.

I think pretty much everyone at MongoDB knows this project because it's been challenging, but it's been a great success. Lots of capabilities were brought to the infrastructure as part of it. And this led to another project that we needed, which was a modernization of our equity swap life cycle management, let's say, platform.

This was a business need for us to keep up in the marketplace with new capabilities. And so, we needed a flexible, powerful database platform like MongoDB to be the backstop and the database behind such a huge renovation. One that comes to my next is AI one -- in fixed income, we are running our data science with Mongo to be in the background.

Just jumping over to wealth management, which is another we do institutional securities as well as wealth management. They are capturing data audit event, let's say, data audit events and they run analytics against that. And they're using Mongo to be to store that data.

And finally, I'll touch upon the document model, which we've heard about a lot today. A lot of the products that we trade are complex products. Just think of terms thinks of agreements, rates, reference data, all around these complex products. This fits so well with MongoDB's document model. This is where we store these complex products across numerous business lines in MongoDB.

Michael Scholz

Yes. So for us, it's actually pretty straightforward. We realized in sort of 2010 that the commerce platforms out in the market, we're really limiting folks to be flexible and scalable, so we are the first composable commerce platform that takes advantage of micro services and API first approach.

We are truly cloud-native and we also have a headless approach because we touch so many different touch points, whether they are a point-of-sale system, whether they're the typical desktop, mobile, social kind of like experiences. So for us, we wanted to build a very sophisticated platform and MongoDB is the market leader that we see and we want to collaborate with to achieving our flexibility and scalability for our platform.

And when we are pushing multiple billions of GMV through our platform, we need to your point about being the backstop, we need the data to be accurate, clean, persistent, all of those things. And we have a lot of companies that are retailers, but we are also across multiple different industries.

But if you think about a typical retailer having Black Friday, Cyber Monday type, like, scalability issues, I think we know that the Black Friday, Cyber Monday is not the Black Friday, Cyber Monday it used to be. You cannot plan for spikes, you cannot plan for peaks, because we have one of the largest telco companies in the U.S. And for them peak is when the new iPhone comes out, when the new Apple, like virtual reality headset is coming out. So whether it's an influencer on Instagram, whether it's other peaks from different companies, we want to be able and in a position to cater for that demand. And we want to respond to that. So for us, it's an integral part of our platform. It's the single source of truth for our platform. And it's also to the cloud native aspect, super, super important that we partner with someone that is available across all of these different public cloud providers. And also, about a month ago, we've announced our offering to be live in China. So, for us, it's super, super important that in mainland China, we can offer our platform based on AWS, based on MongoDB. And it's super, super critical to our success as well.

Michael Gordon

Terrific. Thank you for that. One of the things that I think is helpful, and you've touched on it, but given that we've got some time, the ability to go into some -- what you see as the strengths of MongoDB? And I think the specific examples really help people. So, we'd love to hear your takes on that.

Unidentified Company Representative

So first and foremost is the horizontal scalability. Before MongoDB, the traditionals might have been one server, might have been -- so, once you only have one server, the only way you can scale that is vertically. Put more CPU in it, put more memory in it, but there's limits. To be able to scale horizontally is an incredible feature that a use case like the risk calculation environment would not have been possible without that capability. Hand in hand in that comes, I'll call it, resilience, right? So, once you're in a multi server environment, once you have a multi-server platform, if you have a server problem within MongoDB, it's literally a non-event, unlike in the past, where this would have been a massive outage.

Part and parcel with that, performance. Right? You've heard about a lot of the performance comments here today. We would not have been able to accomplish the projects I mentioned without the performance capabilities that MongoDB provides. And I just want to close with encryption. I have a bigger list, but I don't want to go on.

Encryption is so key, you can't imagine how important it is. Our stringent security requirements mean that we must have encryption capability, especially in the cloud. And we would not be using Mongo Atlas, if it didn't have the encryption capabilities that it has today.

Unidentified Company Representative

To extend some of Dave's points, we had the document database performance security. The other angle that we enjoy from MongoDB is actually developer productivity, which is near and dear to my heart. And so, at this conference, you see a lot of talk about enabling developers helping them innovate. And that's truly what Mongo delivers for my team. Five years ago, we found ourselves growing so fast that our developers were saying, how are we going to keep up? How are we going to actually maintain all this infrastructure? Atlas answered that problem, where today, they don't see any problems in sight, with being able to scale with our customers. But beyond that, it's enabled us to innovate for our customers through the services that Atlas provides, whether it's search services or document storage, and really having the APIs available to my development team, having the command line tools for my development team, enable them to build more value for my customers, which ultimately is what we're all here to do is to deliver value to the market. So, that's one of the reasons Mongo really has been effective for us as a partner.

Unidentified Company Representative

Scalability is key for us. We can take on one customer and suddenly add 15% more usage of our system just overnight. Security, of course, we are dealing with around 25% of the global 2000 and we have all of their purchasing transactional information. It has to be secure, it has to be safe and accessible at all times. And so, that's where the multi-cloud thing becomes extremely important to us.

Cloud is starting to become something invisible from the customer's perspective. They want to be able to come to a company like GEP, and say, give me a global procurement solution. And to not have to worry about whether a cloud is supported for a particular territory or for a particular use case. So, that ability to extend into wherever you need to operate is an amazing, liberating factor for us. And that speaks to what you were saying, Joe, about developer productivity.

We're always seeking technologies and tools that allow us to concentrate more on delivering value to the customer and less on plumbing and engineering, because we grew up from a time where the servers were on the floor of the office. And now we get to a point where we don't even know where the servers are. We don't even know where anything is. We just have to worry about the fine nuances. And that ability to be able to just focus on the end layer, where we interact with the customer, is what allows us to then take the next step and give the customer the control of what the application does going forward. We saw a quote on one of the slides earlier about Gartner saying that by 2024, a certain percentage of applications will be built by people with no programming knowledge at all. I don't necessarily believe everything that Gartner says, but they're right in that.

Unidentified Company Representative

Some people think that's happening today.

Unidentified Company Representative

Yes. There's plenty of applications being built without any skill, for sure. But I think where it makes a difference, just to slightly contradict something you said earlier, Michael, because we are an out of the box software provider. Where you are right is that we don't do 100% of what any customer wants, there's always a gap. There's always a gap between what any solution does, in inverted commas, and what the customer actually needs. The great thing that we've been able to innovate in our system is the means to then stretch that final distance, either the customer doing it themselves or engaging a third-party to do that themselves. And the underlying data structures is what allows us to do that.

Unidentified Company Representative

I think what you guys said. No…

Unidentified Company Representative

That was easy. Wasn't it?

Unidentified Company Representative

That was super easy. No, for us, it's more of the same. It's the scalability, it's the flexibility, I think it's the robustness and the security. Those are all the tenants that we share, like the two companies. And that's I think, why this partnership and this relationship is working so well. We started out with MongoDB and then we moved over to a MongoDB Atlas, because we really believe in this best of breed approach. So, we want to focus on commerce. And we want to work with partners that know and do what they do best. We want to focus on commerce, let MongoDB handle, not only the database part but also the managed services part as a result of that. Because we want to be innovative the same way that MongoDB is innovative with what we can like really change the status quo of kind of like some of these digital experiences.

And to my earlier point, the only constant is change. And we want to make sure that our customers not only have all the required components to be successful and build these outstanding, like shopping experiences right now, but we also want to either drive or predict the troubles that they might get into and solve for those. And so, it's really, really important that we can be focused on innovating on commerce, and let MongoDB do the rest of the magic.

Michael Gordon

I think it's really helpful. We talk about concepts like developer productivity and try and sort of educate investors, but it's so much more powerful to hear it all from all of you. We talk about these concepts that each of you were hitting on around our way we try and summarize it is, not have you all bothered with the undifferentiated heavy lifting, right? So you all can focus and spend precious, scarce developer time on increasing functionality, improving user experience kind of driving those end results rather than a lot of sort of the back end, like I said, undifferentiated heavy lifting. So, it's just pretty great and such good color.

Unidentified Company Representative

May I just share an anecdote with you?

Michael Gordon

Please.

Unidentified Company Representative

That's cool. One of our customers is an oil giant. One of three you can name, right? In fact, we have all three, but that's not the point. The customer in question came to us with a particular requirement. They have a lot of people out in the field, out in on rigs and out in literally in the field, exploring for oil and extracting oil and so on. And they have a lot of requirements for maintenance, repair and operations parts, widgets and screws and bolts and things. And until last year, that was all pretty much done on paper, because these people are out in the field. They fill in request. They send them off. They get them back. And it's very, very difficult to control that kind of operation without on paper. And they came to us and they said, how easy would it be or how many millions of dollars would you charge us to build an app that works on a mobile device that integrates all of that into your procurement system? And in fact, it didn't cost millions of dollars and it didn't take very much time at all. It took around three months to go from initial discussion and actually deploying it, because the speed of development, the speed of prototyping, deployment, and testing is so much greater now that we don't have to worry about any of the -- anything other than that top layer. And we do that through a process called low code development, which again takes a lot of the writing of the code out of it. It's kind of drag-and-drop development. But it's really a model for how all of these systems are being accelerated, and the delivery of value to the end customer is where it's at. And we can't do that, if we are dealing with a static set of rules that are underneath. So, it's a real benefit in the real world and in real time.

Michael Gordon

That was great. Thank you for sharing that anecdote. Okay. For each of you, when you look ahead, where do you think you might use MongoDB in the future? Kind of map out what that sort of next horizon looks like. Michael, you want to start first?

Unidentified Company Representative

Sure. I think we're going to continue to double down on MongoDB and MongoDB Atlas, as we are expanding. So, we have more to achieve in APAC. As I said, we just went into China. So, there is plenty of opportunity there. I think search is so fundamental to commerce that we need to crack that nut even better. I think if you look at across all of our competitors, we are all sort of using some form of elastic search and we don't really differentiate ourselves from them, because we are so focused on commerce and other bits and pieces. But I think search could be that differentiator. So, using a tool like MongoDB Search would be amazing to really embed that and make it part of our stack. I think for us, the fact that MongoDB is -- we have talked about multi-cloud and sort of being cloud native. And I think a lot of people think about horizontal and vertical scaling, and that's obviously one approach to think about it. We think about it also that you are unlocking entire ecosystem of GCP or AWS or even the MongoDB like ecosystem. We also think about how we can scale out and build like innovative applications that way.

And so, I think there is a lot to be gained across industries, across business models. Search looks very, very different when you're talking to a B2C company like Sephora, like Ulta Beauty, versus you're talking to like an Atlas Copco that is a B2B company, a manufacturer or a distributor or a wholesaler looks very, very different because search in one case is about discovery and exploring; on the other hand, it's about finding things. And B2B behaves more and more like B2C but there's still fundamental points there.

And I think I'll close off with this notion of omnichannel, which in and of itself is an overused term. But if we're looking at us being the backbone from a commerce transaction engine and we're serving all these different touch points, so whether it's, again, the desktop, the mobile, the social piece, whether it's the kiosk in a stadium or in your McDonald's, or we're talking about a point of sale system, like whatever that touch point is, and whatever touch points are emerging in the future, we can cater to that. And having like MongoDB, as that accessibility layer for all data purposes, not in a black box like accessible to everyone is usually transformational for us. And we want to provide that opportunity and capability to our customers.

Michael Gordon

All right.

Unidentified Company Representative

I've done a lot of talking.

Michael Gordon

Yes. So you only got two of my top three cloud, it's all about the cloud. Second, tech search, a lot of potential there. But I would add one that we haven't heard yet, which is high speed cache, there's a lot of high speed cache products out there. And we've recently started to use Mongo instead. And it's been a great experience. And you don't really hear about that a lot. Maybe you do and you don't. But we certainly were very pleased at the performance we could get. And we could just not have to have yet another product in the bank to provide that capability.

Unidentified Company Representative

Yes. That's certainly a recurring theme we hear but just the ability to consolidate and to not have point solutions.

Unidentified Company Representative

I would echo what Michael shared that we have both B2B search scenarios and B2C search scenarios. So, you can think about a digital storyteller or a journalist trying to do research about the stories they wish to share, really need a different type of search than a reader or viewer that's on a site or on a mobile device trying to find that content. And so we have a wide variety of search technologies across arc today around different purposes, inclusive of Atlas' full text search. And I think we see moving more to Atlas in terms of satisfying some of those B2C scenarios.

The other thing we haven't touched on is that MongoDB provides options for app services for us to move workloads onto Mongo that might sit elsewhere. So, one of the benefits of being a cloud native platform is it's all serverless code. And so that's supposed to open up opportunities to run that code in different places, whether that's an edge and a CDN, whether it's in AWS, or in Mongo. So, I think that's another conversation we've been having a lot with our partners on the Mongo team about what services and workloads we could move to Mongo Atlas and have it closer to the data that those workloads are running with. So, I think that's another area where we see working together.

Unidentified Company Representative

For us there, there are three really interesting areas of innovation right now. The first is in terms of inclusion of data that was never available to our audience before. So traditionally, people who are dealing with procurement and supply chain issues, they're dealing with their own data, what they have and what they know, their own history of what they've done in the past. But increasingly, the kind of decisions that the Chief Procurement Officer or Chief Financial Officer needs to make have to be informed by what's going on in the rest of the world, particularly when it comes to managing complex supply chains with everything extending into global networks.

The second thing, of course, as my colleagues have already said, is search. Within the sort of end to end procurement process, everything pretty much is a search function. And you say, what are -- what should we do? Where is our greatest opportunity to make savings over the next five years? What strategy should we use to enact that? Which suppliers should we invite to be part of this process? When we get the bids in from the suppliers, which one most closely meets our targets? Which one delivers the best value? And then, what terms and conditions should we use to engage with that supplier in terms of building the contract? And then, when it comes down to the sharp end of people actually using those contracts, where can I find a new laptop? Where can I get a new office chair. And all of these things are search functions. But, at the heart of the whole process, there is this nasty little thing called a contract, which suddenly becomes unstructured, because lawyers get to get involved. Everybody in procurement likes to have everything set out in fields and items that they can search. And then a lawyer will get involved and present an entire blob of effectively unstructured text, which then needs to be restructured in order to make it searchable. The real power of things like vector search, will allow us to say things not like, how many contracts do I have with Commercetools and where are they? That's easy search.

It is, which contracts do I have across the world that expose me to a sudden change in United States import laws? Where are the risks in my contract that leave me exposed? And that's very, very hard to do, even with modern elastic search, it's very hard to get that meaning out of it. And so, being able to take a contract document, which is the heart of this entire process and turn that into something that is - becomes intelligence is a kind of a Holy Grail and it's something that we're working very, very closely towards.

And the final thing, of course, which is like the big thing right now, is AI, generative AI in particular. Because of all of those steps in the process, they're all query response. It's perfect ChatGPT folder. But it has to be correct. So what should I do? The CPO sits down? Okay, what should I do today? And you want the machine to be able to say you need to focus on cardboard packaging, because that market is changing rapidly.

Who should I employ? Who should I engage with to do that? What are the best terms and conditions? Where is my next opportunity for the next saving, and that is a huge area of development. My developers are telling me that what they get from MongoDB is a lot of connections to AI algorithms and engines out of the box. But critically, the ability to build new ones much more easily than ever before.

Michael Gordon

That's great. I know, we have to wrap this very quick. What are you most excited about, 10 seconds or less, from today?

Unidentified Company Representative

I'll go first. Vector search, the whole idea of data streaming super important for us, given the multiple touch points. And I think that approach to really go to market from an industry perspective is powerful, same with the developer community. We're propeller heads, we're a tech company. So those four things.

Unidentified Company Representative

What he said. No surprise, queryable encryption.

Unidentified Company Representative

Yes, I was -- I had my money on that.

Unidentified Company Representative

And I'll round it out with vector search as well. Using AI for journalism and storytelling is nothing new. A decade ago, we were using it for simple things like finance reporting or sports scores. Now we can use it for much more complex scenarios like Atlas Search will do.

Michael Gordon

Awesome. Thank you all for joining us. Thank you for being customers. Thank you for spending time here. Enjoy the rest of the day.

Unidentified Company Representative

Appreciate it. Thanks, everyone.

Michael Gordon

With that, I'm going to turn it over next to Dev who's going to host our partner spotlight. So Dev, take it away.

Dev Ittycheria

All right. Thank you. So, it's my pleasure to talk a little bit about how we partner with some of the largest companies in the world. Obviously, one of our biggest partners in our business is AWS. So, I'm really pleased to have your Chris Grusz with us. And maybe, Chris, you can just start by describing your role at AWS?

Chris Grusz

Yes. Cool. Thanks again for the opportunity, by the way. My name is Chris Grusz, and I run the technology partnership organization for AWS. And so, what that means is, my team works with anybody that's basically not a system integrator or reseller that's part of Amazon partner network. So, that's a software company like a MongoDB, it could be a data provider, it could even be a chip manufacturer. And our team’s charter is really to work with our partners in a kind of a build, market and sell relationship. And so, we will work with MongoDB to help to kind of figure out what those right integrations are into the AWS environment, figure out how we want to go to market, so, where are we going to go to market from a geographic or maybe a vertical perspective and then really work with our partners in a co-sell motion. And so, it's been a nice relationship we’ve had with MongoDB. Marketplace is part of that equation, in terms of how we are going to market. It's really becoming how we're automating the partnership. So, super excited to talk to the audience here today, and thanks for the opportunity.

Dev Ittycheria

Thank you. So just to -- before we get to MongoDB specifics. Maybe you can talk a little bit about like Amazon's philosophy around partnering, maybe in particular with ISVs.

Chris Grusz

Yes. So it's interesting. You will hear a lot of times when people talk about Amazon is that we are customer obsessed. And what that means is that we are always working backwards from our customer needs. And we are always looking for new ways to delight our customers. And when we look at partnerships, it's very much a version of customer obsession, because ultimately what our customers are looking for, whether it's a MongoDB customer, AWS customer or a joint customer, is, they are looking for a solution, right? They are not looking for point products. And so, by working with partners like MongoDB, we are providing a solution to our customers. And so, we very much look at that in line with our whole charter to be customer obsessed.

The other thing that's -- from a partnership perspective that's important to point out is, we look at partners as the way that we provide what we refer to the selection experience. So, when you think about Amazon, one of the things that people really like about Amazon is that it's the everything store and it provides anything that you want to buy. And that concept of selection translates over to AWS in the form of Amazon partner network and specifically how we deliver that with marketplace. And so we are always trying to deliver solutions to our customers and provide that selection experience. And so, that's really critical for how we, of course, go look at partners. And oftentimes on IMB for solutions that have some kind of overlapping functionality with AWS, which is especially important as we look at MongoDB.

Even though there might be some overlapping functionality, that's very -- that's fine from an AWS perspective because we are -- again, we're delivering on that commitment to be customer obsessed and provide that selection experience. And so, having a rich partner community to support that is -- always is very critical. And then, of course, continue to always improve our hand, right? We are always getting feedback from partners like Mongo on what we can do better in how we automate the partnership and how we scale it. And so, we look at this as something that's evergreen in nature that we are always going to work on.

Dev Ittycheria

So, obviously, the follow-on question be is we've been working together since 2016, since we launched Atlas. Could you comment on what the appeal is to partner with MongoDB? And be brutally honest.

Chris Grusz

Yes. No, it's -- well, first of all, it's not a new relationship. And to your point, Dev, it's been since 2016. So, we've built up a level of trust over the years. MongoDB, first of all, it's built on top of AWS. And it's not just utilizing our compute resources, they're using a whole variety of AWS services. And so, it's not just a vendor relationship, it's a partnership. And so, I think that's really important to point out as well.

The other thing that MongoDB has done that's very important for AWS is they've gone through our competency programs. And so, it's not good enough, from our perspective, just to have a solution that runs on top of AWS. We want to have solutions that are well architected, taken advantage of features that allow our customers really scale their products up or down as needed. And so, again, it's an additional level of work that MongoDB had to go through to get that. But that's very important from our perspective, because it provides a better customer experience. And then, the other thing that's very attractive to us is the common user base. When you take a look at MongoDB, they've got such a rich history and a large relationship with the developer community, which is a persona that AWS also has a very close relationship as well. And so, when we look at how we go to market, we've got nice synergies, because we have that core customer, which as developer as a common ground that we can go work on. And then, of course, be in the marketplace. MongoDB has really embraced marketplace in a material way. And that's the preferred route to market for AWS in terms of our partner community. And so, you add up all those things, and just a really good relationship that we can have when we go do co-selling between AWS and MongoDB.

Dev Ittycheria

So, on the co-selling point, you mentioned that now a couple of times. I think for people in the audience, they may not completely appreciate what that really means. But I think that in their mind, I think they do -- will have questions about how does our relationships show up to a common customer? And can you elaborate on the co-sell kind of orientation of the relationship?

Chris Grusz

Yes. I mean, because we have a common customer, we have a joint value proposition, right? We're not just kind of showing up independently at customer accounts. A lot of times we're going in together and having that joint value proposition, which is really centered around helping our customers innovate. When they're moving to AWS, they're trying to innovate. And MongoDB is very much in line with helping their customers innovate and get more access and more information on their data, right? I think both companies -- we both refer to ourselves as being data driven. And we help our customers get data driven as a result. And so, I think that's really important.

The other thing is that it's not just a North American relationship. We're here in New York today but we have a global relationship with MongoDB. And you can take a look at, even some of the words that we've given MongoDB over the last year that are really testament to that. Last year at re:Invent, as an example, we awarded MongoDB, the EMEA Partner of the Year award for Marketplace. And that’s because we're seeing over 100% year-over-year growth in that particular area alone. And then you fast forward to this year, and earlier this year, MongoDB was awarded the ASEAN Partner of the Year award. So, for Singapore and in that part of the world, again, we're seeing really good co-sell between AWS and MongoDB.

And then most recently, they won the Chile Partner of the Year award down in LATAM. So, we're seeing really good alignment, not only in North America here, but in Europe, Asia Pacific as well as other countries, like LATAM. So, it's been really nice.

Dev Ittycheria

So, in the spirit of incentives drives the outcome, it’s old Charlie Munger quote, that is true, has high esteem for -- someone to high esteem for. What is the incentive for AWS to work well with the partners? I mean, how are sellers compensated? How's the organization incentivized to do this in a way that's natural and not some sort of forced artificial relationship?

Chris Grusz

Yes. So, I mean, again, it kind of really feeds into our concept of customer obsession, providing those solutions. That's ultimately at the end of the day what we're really trying to do from a database perspective is really delight our customers. Now you go beyond that, what are the other specific things that are kind of in for AWS?

Well, again, is built on top of AWS. So when a customer buys MongoDB, they're indirectly buying AWS. And so, there's a strong financial alignment from that perspective as well. And so, that really helps kind of support that relationship as we go forward.

The other thing that you can also take a look at that's in it for us is the alignment from our field perspective. So you asked, like, what's in for the seller as an example and they get happy customers. And that's always a good thing. But our field is actually compensated when a customer buys MongoDB. And so, there's good financial alignment. MongoDB is in a program that AWS calls ISV Accelerate, which is our primary co-sell program. And that actually provides that financial incentive for our field, the AWS field sellers to sell side by side MongoDB. And they actually get compensated for it.

And then, on top of that, they’re also goaled on that. One of the things that we really tried to drive as a behavioral thing across AWS is to work with partners. And so, our field are goaled on things like private offers, and it's not $1 value that they're goaled on, it's actually a volume perspective. So, we want to incent our field to work with partners, because we think it just provides a great customer experience.

Dev Ittycheria

So, in the -- obviously, acquiring a customer takes a lot of work and effort. Who is involved in actually finding these customers? And maybe you can talk about like the mix of like, how much business do you bring to table versus MongoDB?

Chris Grusz

Yes. So, for our most successful partnerships, we really kind of have two co-sell motions. So, the first one is a self-service motion. And what we're trying to do on the self-service side is go well beyond what is traditionally happened in marketing, where you have an event and you have some leads that you follow-up on. What we're trying to do is automate that entire experience. And so, we look at that as a key part of why we work with MongoDB with marketplace. And in that regard, we'll actually do self-service campaigns with our partners. And the design point there is not to generate a lead, but it's actually to generate a customer. And so, we've got a really healthy self service experience with MongoDB. If I just look at the last number of months, we've done a number of campaigns with MongoDB, we'll have -- over 10,000 customers have actually hit the landing page on Marketplace. And those are actually translated down to 1,000 new customers. And so, that's a nice experience, because we're generating opportunities and customers for our partners.

And then on the flip side of that, we then will execute in the field from a co-sell perspective. And that's where Marketplace Private Offers becomes kind of the transaction vehicle. And that's where it might be a large opportunity that MongoDB is working with a customer and they want to buy through this Marketplace. And so, they can submit a bespoke subscription through Marketplace with specific pricing and negotiated EULA. And the customer can accept that off the Marketplace. And it just goes run the AWS bill.

And so, oftentimes on the Private Offer experience, because your sales teams are involved, they're kind of leading the effort there. But then we look at the self-service side as a way that we're generating business for those partners. And again, for our most successful relationships, we have both sides of that equation. And that's one of the things that we really have with MongoDB, that's nice. We don't have that with all of our partners.

Dev Ittycheria

So, I would be remiss -- and not only throw layups in terms of questions for you, but I'd be remiss to not asking, clearly there's some areas of overlap between AWS and MongoDB. Can you speak to how you deal with that, in general, in particular with Mongo?

Chris Grusz

Yes. And so, it's actually a big reason why we do have Marketplace. And so even though we might have overlapping functionality in areas between native first party service and a product like MongoDB, that's okay, because when a customer decides that they want to go with a third party product, we want to support that from an AWS perspective. And so, that's why we have specifically put in compensation programs that when a customer says we are going with MongoDB, we want our field teams to also get in line with that. And so, we are going to pay them on that subscription and make sure that they are really incented to go do that. Because again, at the end of the day, that workload is landing on top of AWS, and that's beneficial for us. They are using MongoDB. They are building with AWS, and so that's beneficial for us as well. And so, even though there might be some overlap in terms of the functionality, once a customer makes that decision, we want to support that. We don't look at that as a bad thing, because it's still driving consumption for the AWS platform.

Dev Ittycheria

I don't know if you were here for the keynotes, but we talked about some of the announcements and one of those was being awarded the Financial Services Competency award. Can you -- you touched on competencies before, but maybe you can just double click a little bit on what that award -- what that competency really signifies and what that means for the relationship?

Chris Grusz

Yes, yes. And so, we talked about -- well, the first competency I mentioned was the data and analytics competency. And that's where we work with partners like Mongo to kind of go through a full verification of how that solution runs on top of AWS, and making sure it takes advantage of key underlying functionalities. The product will work as efficiently as possible on AWS. And then on top of that, we are now having competencies around specific industry verticals like financial services, which is what was announced today. And that's an additional level of competency where we will actually sit down with Mongo and we go through a number of use cases that they might have for financial services. We actually go through some case study work, and we really come up with a number of use cases that are very specific to those industries like financial services. And again, it's all in line to help to provide a really good customer experience to our joint customers in financial services. And so that's just one of many.

You take a look at what Mongo is doing, they are also working towards our automotive competency for those very same reasons. And so, even though MongoDB provides a great solution that it can have a horizontal storyline, there is also vertical nuances. And that's really interesting for AWS to work with a partner like MongoDB, is make sure that we’ve got those use cases identified for customers like financial services or another good one to point out would be public sector, right? In recent FedRAMP Moderate approval. And that's very important for AWS customers as well to have that FedRAMP status. And so, again, just providing something that's very specific to a subset of our customers, but having that use case that's identified that we can work together on.

Dev Ittycheria

So, kind of the last question would be -- is what do you think we can do more in the future?

Chris Grusz

Yes. And so, we’ve had a long relationship. One of the key things that we really point to that we did about a year ago was the strategic collaboration agreement between MongoDB and AWS. And these are agreements that we put together that are multi years in length. This one is actually six years. And so, it's one of the more longer ones that we have. And it's designed to really kind of structure what we want to do from a build market sell approach over a multiyear journey. And we are just one year in. We’ve been super happy with the results so far. And so, that also gives us a good starting point for where we want to go.

The other place that we’ll be interesting to work on moving forward is again that vertical approach, right? So, kind of announcements today that you had around Atlas for industries, again, really maps well to what AWS is doing from a vertical approach as well. And so, really interested to not only work with MongoDB, as we have to that core developer persona that we’ve had in the past, but then also how do we go then work with financial services customers, public sector customers and some other verticals that we are focused on as well.

Dev Ittycheria

And I know that's a top priority for Adam, right?

Chris Grusz

Oh, absolutely. We are very much going in that direction.

Dev Ittycheria

Terrific. Well, thank you so much for your time. We really appreciate the partnership. And I appreciate you being here.

Chris Grusz

All right. Thanks for giving the opportunity.

Dev Ittycheria

Thank you, Chris.

Michael Gordon

A break before the final hour, just to let everyone take a bio break or whatever they need, and we'll be back in 10 minutes. Thank you.

[BREAK]

Michael Gordon

I was warned about giving you all a break. All righty. I hope that was helpful on the product and customer side. Before we get to the Q&A, which I know just even from the break that there are a bunch of questions out there. So, we look forward to covering those in detail. Dev, Sahir and I will all be up here. I did want to spend a few minutes giving a little bit of a business update. Again, we normally want to make these sessions focused on product and on our customers, but thought it would be helpful to take advantage of the fact that we had you all here together to give a little bit more insight into what we're seeing. So, thank you for doing that with us.

There are three things I really want to cover as we spend time today. I want to talk about the drivers of the Atlas business and make sure people understand those. We talk about those a lot, but really want to take the time to help highlight some of the key trends that we're seeing. I want to make sure and give a little more visibility and insight into the customer base. So, we'll do some fun slicing and dicing that will give a little bit more visibility into what we're seeing there. And then third, touch on the financial side briefly and talk about how we've been demonstrating profitable growth and how that's an important part of the story as well.

So, without any further ado, I will drive straight into the Atlas drivers. And as I said at the beginning, remember, we grow in accounts by acquiring workloads, right? Everything is this workload orientation. And so, we'll talk about new workloads, and we'll talk about growth of existing workloads, because that's sort of the dynamic that we have.

And I showed you this sort of illustrative journey that we had where we have to win that first initial workload. That workload will grow based on a number of application specific factors, but also based on the macroeconomic environment. And then what we'll do, though, is we'll continue to win workloads in the account. And organizations can have hundreds or thousands or more applications within there, so sort of this workload or dynamic sort of builds upon itself. And that's kind of the dynamic that we see over time.

And so, as we've said, Atlas growth in the short term is really dictated by the growth of those existing workloads. New workloads start small, and we'll walk a little bit through that. And that growth of existing applications and existing workloads is driven by the underlying usage activity. So, think of this as sort of the reads and writes, the query activity in those underlying indications as a second order effect of the actual end user interaction with the application. And so, we've talked about how we've seen slower growth of existing applications as a result of the macro environment, starting in Q2 of last year.

And so, we thought it would be helpful as to take advantage of the time that we have today to give you a visual demonstration or give you some insight on what does that actually mean and what does it actually look like? So here, you can see there's variability kind of quarter-to-quarter and this speaks to the seasonality that we've talked about. And what I'm showing here is average week-over-week Atlas growth rates, right? So, this is meant to sort of normalize for the fact that Q1 has fewer days and some of those things that we talk about that you understand. But what this shows is the week-over-week growth, and so what are the dynamics, what are the numbers that we pay attention to from an operational standpoint. And what you can see is it sits within a relatively tight range, as we mentioned, Q3 tends to be seasonally stronger. And you can kind of see that in the history. And we've drawn this dotted line on the left-hand side that you can see that it's kind of like the average before Q2. And again, some quarters a little stronger, some quarters a little slower growth, but within some regional band.

You can see pretty dramatically the step-down that we saw and we talked about and we disclosed at the beginning of Q2, in that Q2 number. And you can see how since then, it has not rebounded to the pre-macro level. So, when we talk about the growth and how the growth rates are trending, -- when we talk about the average that we've seen since the slowdown, this is what we mean and what we talked about. And here, you can see that stronger Q3 seasonality that we talked about. Here, you can see the more pronounced Q4 holiday slowdown that we talked about and then Q1 being back more in line with what we've seen since the slowdown.

So hopefully that helps put some sort of visualization and understanding around the words and context that we've been talking about to really understand some of the Atlas drivers that we've been seeing.

In the long term, though, Atlas growth is driven by our ability to acquire new workloads. That's really the key thing, because new workloads in the long run will drive most of the growth. But in the short term, new workloads represent a relatively small portion of the business. New workloads tend to start small, even though they grow quickly. And so, what we tried to do here is to illustrate what that means.

Now, every workload is different. So there are a bunch of simplifying assumptions here and everything else. What we tried to say is sort of in a given quarter, a relatively small amount of the impact of the incremental Atlas revenue is coming from new workloads, right? It sort of makes sense. You've got a large installed base. It's growing healthily. New workloads start small. But what happens is over time, if you play this out over five years, right, if you look over 20 quarters, what winds up happening, right? And the reality is the new workloads that you add over that subsequent workload wind up being responsible for the vast majority of the incremental growth. It's somewhat logical and intuitive and sort of math friendly. But we thought that maybe visualizing it would help complement the words and the dynamics that we've been describing. So, that's a little bit about the Atlas dynamics and what we've seen.

I want to switch and start talking about the customer base and do a little bit more peeling back of the onion and share some, I think, are interesting views of our customer base. As you know, we've got over -- now over 43,000 customers. Here, I'm going to use the fiscal '23 numbers just so we're kind of talking year-over-year, and we only do this investor session once a year. So, it just seems easier to talk about everything in full year terms. But obviously, we reported the Q1 numbers and had continued strong growth, more than 2,000 customers added in the most recent quarter, and we continue to see very healthy new business activity, despite the macroeconomic environment. And when we talk about total customers, we tend to be broken down into two different buckets. There's the self-serve customers and the direct sales customers. And then within direct sales customers, we'll talk about it a little bit, that actually breaks down to enterprise customers and the mid-market. And those who followed the story for a long time have heard us talk about that and talk about that breakdown.

Customers also continue to grow with MongoDB. So, on the left-hand side, you can see very strong and healthy growth of our customers over 100,000, and we report that every quarter and continue to see strong and healthy growth there. And on the right-hand side, here, you can see customers growing and now spending more than $1 million with us. And they continue to grow healthily as well. And these numbers for the last year have been about 25% or 30% year-over-year growth for the two different buckets, broadly in line with what we're seeing right now on a revenue basis.

We have a broad range of customers. We have a very-diversified customer base just in general. And you can see everything from sort of very large demanding telcos to established and cutting-edge technology companies, core industrials, large pharmaceuticals, innovative healthcare companies, highly regulated banks and financial services and institution firms. And this is just a partial list. There's consumer and energy and retailers and utilities and a whole wide range of customers who want using MongoDB. And you heard across whether it's a panel today, in some of the keynotes, just the breadth of what MongoDB does, the general purpose nature we do, makes it valuable for all these different use cases. It's not sort of just a single trick. It's not the hammer that's sort of looking for the nail or anything like that.

There's also a wide range of use cases. I'll highlight a couple. Again, we try to talk about this in the session with a customer panel and other things because I think it helps provide a little bit of context for people. Let's talk about healthcare. Patient data in healthcare is incredibly sensitive, highly regulated and deeply siloed. And so, one of the largest North American insurance companies is using MongoDB for its patient data interoperability. And what they're doing is using Atlas to collate and aggregate all the healthcare data across their multiple and disparate systems to achieve critical compliance needs, but also improve the patient experience with real-time data integration. So just one example of how people are using MongoDB.

Similarly, within the telco industry, like any industry, but particularly the telco industry, fraud detection is an incredibly important part of what they do. And so, one of the largest multinational telcos, build its real-time fraud detection, flood prevention platform on Atlas. They're running 50-plus, more than 50 AI models and they're processing over 10 million events per day. And what that's done is that helped reduce fraudulent activity by roughly 80%. So, again, you can kind of see the impact, the scale of MongoDB.

And lastly, I'll just highlight -- pick a retailer, a European retailer. Like many retailers competing for customers is incredibly demanding. You heard the Commercetools folks here, different situation, different use case. Personalization is incredibly important within retail. And so, one of the large European retailers is using MongoDB to be to power its personalized shopping experience for its more than 2 million daily customers to its website. It's a one-stop shop for more than 5,000 brands. And so it's relational, existing relational solution couldn't scale. It used to take -- think about this from a retail experience. It used to take 12 hours for them to update product pricing and availability, they switched over to MongoDB and now it's done within minutes. So just a little bit of some of the use cases that we're seeing. Hopefully that gives a little bit more flavor and insight.

If we talk more broadly kind of away from the individual, we're going to talk about sort of in the aggregate, we'll talk about cohorts and what we're seeing on a cohort basis. As I mentioned, customers do start small. So this is looking at customer cohorts, they start small, they grow very healthily. By the end of the first year, we've sort of indexed them to 100. And you can see over the next subsequent two years, they grow about 2x, 2.1x to put an exact number on it from a subsequent growth standpoint. So this is -- some of this -- these are cohorts that have reached three years, some of these cohorts are not affected by the macro. So I think you need to keep that in mind. We've talked about the impact of macro. But that's really the growth that we're seeing from our cohorts.

Interestingly, we also looked at this analysis for our larger customers. And so we said, all right, let's -- looking back over the three years of data, let's look at the customers at the end of fiscal '20, who are more than $100,000 in revenue, that's what the left hand side represents. Even those customers over the three-year period have grown 2x. And on the right hand side, we took the customers who are already $1 million or more at the end of fiscal '20 and follow that cohort over the next three years. And that cohort similarly also doubled over the course of the next three years. So you can see this is sort of the logical conclusion, when you think about everything that we're talking about of, huge TAM, a market that's dictated workload by workload. So the opportunity not just to land within the account, but then continue expanding within the account. And I think that's what these numbers help paint out.

This isn't one of the earlier slides just talking about the size of the market that I walked through, I think it's important to remember this and to underscore this. And we're really quite early on in capturing this market share. In aggregate, if you add all this up, you'll conclude that we're closing in on 2% market share, right, when you do the math. I think what's really extraordinary is we're still in the early phases of winning, even within underpriced accounts. Here's some stats that I thought was interesting in terms of sort of slicing and dicing the universe. So if you look at the Fortune 100, we have just under 2/3 of the Fortune 100 now as customers. If you expand that to the Fortune 500, just under 40%, but 1/4 of the Global 2000. So even though we're winning significant numbers of new customers, and we're chipping away at the larger customers, there's still an enormous amount of opportunity that we still have. And in fact, if you look at the market size, and you kind of break it down into the Fortune 100 and the Fortune 500, and what they spend on databases, you can see that, that same closing in on 2% narrative holds. So we've got a very broad representation of the customer base from the most demanding customers in the world to the newest startups, and equally penetrated across all of them. But I think the key takeaway is still pretty early on in pursuing this market opportunity.

When we think about our customers, it's a broadly diversified customer base. We'll come at this in three different slices here in the hopes of helping paint some visibility. I mentioned the different channels. So within the enterprise customer base -- I'm sorry with self-service customer base, self-serve is about 12% of ARR. That means the rest -- the other 88 is more in that direct sales bucket. 75% of that or 75 percentage points, excuse me of that 88 come from enterprise customers, and about 13% for the mid market. Enterprise is the largest chunk. It's quite geographically distributed, a little over half in the U.S. You can see just under 1/3 in Europe, and the balance in APAC. And then we think about relative customer concentration, our top 100 customers account for just over 1/3 of the business with no customer accounting for more -- 2% or more of ARR. So it's quite diversified. And even within these largest customers, while we've had success penetrating them, we still have relatively low wallet share.

If I spend another minute just sort of double clicking further on the top 100 customers, we thought it might be interesting to take a product slice of things. We've talked about how we're agnostic in terms of the product that we sell. And we here at MongoDB aren’t really in a position to tell any of the panelists up here that we had no issues building applications, you put it in the cloud, you just run it on prem, that's really their choice.

And so what this shows is, customers pretty neatly cleave into either primarily Atlas, or primarily EA. And so you can see there about 47%, just under half, are mostly Atlas. So we just picked above 80%, just to help people understand. And about 38% are mostly EA, these are the dollars of ARR of the top 100 customers, and the small chunk, about 15% that really are sort of in a more hybrid environment. And then if you try and look at them on a cohort basis, and you say, okay, of your top 100 customers, the ARR from your top 100 customers, where's that coming from? Not surprisingly, the bulk of that 59% is coming from people who've been on the platform five years or more. And when you think about the market that I described, and the fact that it works workload by workload, that shouldn't be surprising, right? That shouldn't be a revolutionary takeaway. And similarly, well, new workloads start off small, you wouldn't expect new customers that you just won in this year to be heavily dominating your top 100 customers. So the newer customers have this much smaller slice of things.

So I hope that helps paint a little bit of a picture in terms of the customer base.

And then lastly, what I wanted to do was talk about the financials, talk about the P&L and talk about how we've been demonstrating profitable growth over time here. If we take a step back to revenue growth, since the IPO has been fairly significant -- excuse me, we've seen about 8x revenue increases, 8x over that timeframe. Obviously, the public company guidance around $1.5 billion for the current fiscal year. At the same time that we've been growing, we've also been scaling operationally. So here you can see the history of our operating leverage, and the operating margin improvement. At the time of going public, we were in a negative 38% margin and then last quarter hit 5% margin. So we still have a ways to go in terms of our long-term target margins. But we've done a fair amount of work over the last few years, not just in terms of penetrating the market and driving revenue, but also in terms of the operating model and the operating leverage. And so wanted to make sure that we underscore that.

We're able to do that all why Atlas scales. Atlas, as you know, includes the underlying storage and compute, is lower gross margin. And at the time that we went public was in the single-digits in terms of our revenue. Atlas is now just under 2/3 of our revenue. And we've been able to very successfully execute on our gross margin plan. And here you can see on the right hand side that we've been able to do that despite the fact that Atlas has grown quite significantly.

If we look at operating leverage line item by line item, so let's look at sales and marketing SG&A and R&D. If you look over the last several years, you can see significant progress. So G&A has gone from 17% of revenue to about 8% of revenue from the time of the IPO. We have seen significant scaling in R&D as well, going from 34%, down to 19%. And then finally, also significant scaling within sales and marketing, jumping down from about 62% of revenue, closer to 43% of revenue. So I think it was just helpful to kind of put some of that in context in terms of how we have been trying to, as I joked on the last call walk and chew gum, growing the business fairly significantly, really making sure that we are investing in long-term to pursue our market opportunity, but also taking care of the operating leverage side of the equation.

So we'll keep investing in sales and marketing. As I mentioned, we have a limited footprint compared to the opportunity. Our win rates are exceptionally high when we were in situations. We are just not in enough situations and we are trying to put some dimensions around our footprint coverage. Of the 20 countries in the G20, we only have sales presence in 13 of those. If you focus more domestically within the U.S., oftentimes, people talk about NFL cities as sort of a proxy for the largest cities within the U.S., even though they are 32 teams, or 30 cities. And we have two or even more than two reps in only 60% of those. So again, just trying to give you a sense for how big the market is and how early on we are in penetrating that market.

In terms of R&D, we will certainly continue to invest in R&D as well. We have an ambitious product roadmap. You heard a number of announcements, which we will talk about in the Q&A session, that comes from the result of investing in our core database offering, and building to expand our developer data platform. Those are both incredibly important to us, and we will continue to invest in those as well.

All that said, our unit economics are incredibly strong. Those show through in the numbers. We will continue to see improving profitability as we scale. Don't think of that as a literal every quarter. I think we try to talk about, there will be times when there are either seasonal or other variances, but the general trajectory and the general trend is clearly towards improving profitability as we scale. And I think it's valuable to sort of go back to the long-term target model that we had provided at the time of the IPO, and underscore the key aspects of it.

I think the two things we are focusing on here: First, actually, I'll hit the numbers. They shouldn't be new to anyone in the crowd. We have talked about these before. But gross margin 70% plus, non-GAAP operating margins at 20% plus. I think the two key things that I would mention here is, if I think about where we sit today, and my confidence, our confidence, and our ability to hit these, they are significantly higher than they were at the time of the IPO. Again, as I mentioned, at the time of the IPO Atlas was single digits in terms of revenue, meaningfully margin dilutive, and we have accomplished an enormous amount there. So confidence and ability to hit these numbers is much higher. And the second I would say, we are more focused on the upside of these numbers, and trying to drive against the upside numbers. So the plus is sort of more important than it was in the past. And so I just wanted to underscore that piece of the puzzle as well.

And with that, I think we will go to Q&A. So, if I could ask Dev and Sahir to come on up and join me.

Question-and-Answer Session

Q - Kash Rangan

Kash Rangan at Goldman Sachs sitting right here. Fantastic session. Anybody that wants to take it on Dev, maybe you. The market is so massive 86 -- 80 plus billion and you have a small share. Looks like there's a lot of replacement opportunity. So today's announcements, the general availability of Relational Migrator plus lot of the Vector Search capability to stream. If you want to rank order, what are the biggest unlocks in the market? So we all know that these markets don't move linearly, they go through a big step function, changes in competitive dynamics replacement and then they kind of stabilize. In your view for the next four to five years in the world of generative AI, what could be the big unlocks for MongoDB?

Dev Ittycheria

Yes, so what I would say is, we're really excited about, I would say, Relational Migrator, because the TAM opportunity in terms of being able to get people to consider replatforming of relational, given Michael's talk, you saw that we have less than 2% share. So there's a lot of relational out there. So the easier we make it for -- and the lower the switching costs and moving off relational to MongoDB, that is -- potentially could be a massive opportunity. Now with that, we're fairly balanced, no one just wakes up every morning and says, hey, I want to replatform, it's typically some catalyst, the performance from application is really so bad that my end user is complaining. It's very hard to add new features, because the data model is so brittle, or just the value to cost proposition is completely out of whack. And we just need to refactor that.

So there's got to be some compelling event but since there's so much latent relational out there, even a couple points of share would be obviously very meaningful.

Fred Havemeyer

Thank you very much. Fred Havemeyer with Macquarie. I'm really focusing in on Vector Search as I think the thing I want to be asking about today. And firstly, I think, with the announcement, thank you, it will change how I'm hacking on the weekend a bit. And I'll no longer be donating some of my money to some of the startups out there that are doing Vector Search. But I'm curious here. Two part question. Firstly, Vector Search, is this something that you think would be expanding the volume of data that you're going to be storing within MongoDB? And if so, do you have any kind of initial thoughts on how that sort of attaches to some of the documents that you store presently?

And then secondly, I mean, I'm running a generative AI project at my company, we're doing quite a bit. And it's quite clear that there's a lot of both read and write opportunity with the amount of two-way information inquiring that's going on. So do you have any additional thoughts also on how this may impact longer term, the volumes of queries that are also run on MongoDB and through Atlas?

Dev Ittycheria

I do think it affects both to your point. In terms of data volume itself, today, if somebody is building an application that requires a specialized vector database, they might be storing the metadata or the source data in MongoDB or as Andrew mentioned, some of the characteristics about the usage of those embeddings back into an operational database, but the vectors themselves are not stored in Mongo. So with this new index type, it's definitely going to leverage some of that. Now there's also benefits because we don't duplicate the data completely either. So that's cost advantage for the customer to use one consolidated solution versus both. So it's not going to be like-for-like compared to two databases.

Conversely, it's a new index type. And every time there's a new index type and query set of operators to your point, that's going to drive throughput, which drives the memory and compute usage of the actual database clusters or the environments that we're running at. So as those applications get to scale, obviously, there's a lot of prototype in happen right now, a lot of toy applications experimental, but as more of these companies take these capabilities in the existing app or a brand-new app to scale to kind of tie to Michael's kind of life cycle of an app description, certainly, that will drive more throughput on the engine.

Brent Bracelin

Brent Bracelin with Piper Sandler. One clarification on Vector Search, you guys announced basically previews for relational and QE last year, a year later, the GA. Are you thinking about a different time line for GA around vector search, given the pace of interest is changing. That's the first clarification.

Second question really is around vendor consolidation. We're a little surprised to hear Morgan Stanley by end of the argument. They want to consolidate these specialty things. That strategy seems to be working. Is caching becoming an area where you're seeing more folks looking to consolidate that into Mongo.

Michael Gordon

Yes. The first piece of it with Vector search, I think sorry, I lost the first part of the how long on for -- yes, this is customer-driven. I mean these are hard data projects. So definitely getting the metrics we need to hit in terms of stability and throughput and all of that does take time versus a stateless application. So that's why a year time line, any data service you see out of the market typically has that time line, but we don't have it pegged desk. It's definitely MongoDB local next year. It has a lot to do with the scale of applications that we now see in the public preview, which will be an order of magnitude more than what we've had or multiple order magnitude perhaps compared to the private preview.

And we feel like when we hit the quality gates and the performance gates that we've set and the customer satisfaction and feedback around that is solid, then we'll flip it to GA. And that's typically the goal we have anyways.

Brent Bracelin

Caching?

Michael Gordon

Yes. On caching, I think there's opportunity for us to potentially get into that space with certain use cases. In fact, the raw memory performance of MongoDB's in-memory engine is similar to a lot of caching solutions already today, but there's some capabilities we would want to expand there. But I think it's an and, not an or. There's also an opportunity to create better integrations to some of the common technologies because there are scenarios where people want to cache multiple source data sets from multiple database solutions together, and we certainly need to be open and extensible to be able to support that well and want to be shut out.

Tyler Radke

Tyler Radke from Citi. So a smaller conference, but I feel like two or three times the volume of product announcements. So very impressive. I guess I wanted to ask two questions on Vector and on stream processing, which were kind of the key highlights. So first, on Vector, could you just talk a little bit more about the technology stack? I think it's built off Apache Lucene, but just kind of your view on how Vector under MongoDB is positioned against, call it, Pinecone or Weaviate, some of the other vectors out there.

And then secondly, stream processing. I did not expect to hear that announcement today. I think a lot of folks were caught off guard. But could you just talk about like why now? And is the approach leveraging Flink, which is one of the popular stream processing, open source technologies or just kind of your view on your differentiation from a technology perspective?

Dev Ittycheria

Yes. On the streaming side, we are not built on top of Apache Flink. We've extended our own query processing layer and engine over to the streaming platforms and be able to plug in and tap into a Kafka topic, for example. We did and always look out at the market at technologies, we can either incorporate and integrate ourselves or even M&A. The big challenge we see is all of the typical players out there that are Flink-based or even alternatives to Flink are not really good at handling flexible document models.

So that, in many ways, kind of pushed us to expand organically our engine to deal with continuous processing and streaming data as opposed to just wrapping something in that scenario was something we definitely have looked at quite carefully.

On the vector side, today, our Vector Search engine does rely on Lucene, though we're very -- and that's, I think, playing out so far to be quite a positive because there's a lot of other vendors that are also contributing code back, not just us. We've seen a lot of push around the vector size limits and dimensionality happening. So we're watching that space very closely. But we've also made the decision to architect it in a way that over time, we could support multiple engines for different use cases, but still create a query abstraction and have operations where it still integrates the same driver, the same API up to the application.

And so it's meant to be over the long term extensible. And I certainly wouldn't say that Lucene is the only engine in the long future that we would support. We might need multiple.

Sanjit Singh

Sanjit Singh, Morgan Stanley. So here you're busy man on say, which is great to see because of all the product innovation. Maybe I'll toggle to Dev. If I step back and look at all the things that you've announced, Michael's point about being underpenetrated in terms of sales coverage. How should we think about the shape and durability growth going forward versus what we've seen in the past, which has been great. You guys have 8x revenue.

Is there anything to think about in terms of law of large numbers or a structural change in buying behavior or customers getting more cautious given what seems like a really open-ended opportunity? So just your views on how we should think about the shape of growth going forward and the durability of that growth? And then I have some questions for Sahir as well.

Dev Ittycheria

Yes. I would tell you that I feel we're better positioned today than we kind of almost mirroring Michael's comment on the profitability targets and the long-term margin targets. I would say I feel like we're better positioned to pursue the opportunity today than we were 6 years ago when we went public almost seven years ago when you went public.

I say that because it's clear that if you look at the stages of MongoDB -- the first stage was -- is ongoing to be a toy, can be really trusted for mission critical. Then the second stage was they're building a cloud service, can they really compete they basically road kill for the hyperscalers, and now the third stage is can they really be a platform play. And I think you've seen us chip away and on every stage of a skeptic, I think you're the one that said the bare case of MongoDB has been written so many times. And I think one of the thing that drives us is just customer feedback. So all these decisions we made, the product announce you heard is all driven predominantly by customer feedback.

Customers said, I don't want to use a search engine and at MongoDB, why don't you just put it all in MongoDB that drove us to build full tech search so forth. So I'm Michael will shoot me if I give you any specifics about like long-term growth models. But I feel.

Michael Gordon

I remind you of the law of large numbers is real.

Dev Ittycheria

But I mean, we're also proud, and I want to reinforce the point that Michael made, we're really proud of the operating leverage we've shown because we are trying to build a durable business. And getting the next generation of leaders in MongoDB understand that capital is not cheap. You can't throw money in people at problems that you have to be judicious about where you invest and sometimes where you divest because something is not working. That, I think, is a very healthy muscle for us to build. So we're not a growth at all cost business, but we feel like we can grow for a long time.

Sanjit Singh

Great. And then Sahir, just in terms of -- two quick questions on vector databases. Should we think about the vectorization opportunity specifically for data that's already in MongoDB? Or can customers if they want to vectorize some of their unstructured knowledge repository because they said that to MongoDB and so being more of a just outside of the MongoDB engine? And what indexing algorithms in terms of ANNs are you supporting out of the gate?

Sahir Azam

Yes. So on the data side of things, you can't index any external embedding and just persisted into our vector engine. It's not dependent to be pulled for MongoDB. And in fact, we're not actually creating the embeddings. We're integrating into that layer to all the different models that create the embedding. So today, where Mongo is used without a vector database, those are -- that's net new data coming into just the core operational indexes that's typically metadata and information about the embeddings. Now we'll actually have the vectors either again, embedded at docs or side by side. So it supports both models. And that's kind of the source data versus the metadata store stuff that Andrew was talking about earlier. Again, on the model side, we've built basically on open source models, and we made it extensible. So we have today, the operators baked into the search capability we'll be building an extensibility layer to the operator so we can actually swap in multiple KNN algorithms and still in our query language over time.

And we're right now, most of it is just basic nearest neighbor, just on MW stuff that we're using, but I think that will evolve. And so Doug, who leads engineering for us on this initiative has been very strong on keeping it composable and extensible. So we have the flexibility, now what will stay the same is the developer experience. That has to stay unified and integrated northbound into the application.

Michael Cikos

Mike Cikos from Needham here in the front. I'll probably echo Tyler's comments at the stream processing kind of code off guard. So kudos on all the announcements today. I think two things from my side. First, -- my understanding is that you guys are actually a technology partner with Confluent. So with the stream processing announcement, can you help paint a picture for like how this partnership plays out? Is there more competitive overlap? And is it relatively compliant to Flink? Or is it broader in scope when I think about what you guys are bringing to market versus what Confluent has out there today?

Michael Gordon

Yes. So we absolutely partner with Confluent. They're obviously quite pervasive with Kafka and all -- a lot of our enterprise accounts. We've had relationships co-developing the connector, which will also stay. The connector doesn't go away. There's plenty of use cases for basic data integration CDC that that's still very relevant. That will continue. We also don't provide this transport layer at all in MongoDB. We're the processing layer because we think that's the layer that's really strategic in terms of integrating into an application experience. And so that does overlap with Flink, which is a acquisition that Confluent just made in the last six months. So this is a new space that they've also entered into exactly. So we certainly overlap with the capabilities of Flink and some of the other relational oriented data processing and query engines at that layer. So that's certainly some competitive overlap. But I think even where we have overlapping technologies, we see Kafka, Kinesis, Google Pub/Sub, Redpanda, a whole slew of different transport layers we plan to remain open, so we can tap into any of those and perhaps even make that experience easier over time out of the box in our platform.

Jason Ader

Jason Ader with William Blair. Two questions. First, are you planning on monetizing any of the new features you announced today beyond just Atlas consumption? And then second, as you think about AI's opportunity to make it easier to switch out of relational databases, to MongoDB, does this also reduce long term, the stickiness of the database and makes it easier for others to switch out from MongoDB to other databases?

Sahir Azam

Yes. So I think on the latter point, we have to compete on the merits of being the better database and developer experience, scalability, price performance. And we often say internally that if the switching costs were zero, more data and applications would naturally flow towards MongoDB, not away from it because we're a much more modern architecture and that developer experience and ease of use is a real beneficiary. So yes, technologies like AI and others that can help with data modeling certainly cut the other way. But in aggregate, we feel strongly that, that's a tailwind to more coming to Mongo because we have the more modern product than a relational database system.

Michael Gordon

I would just maybe add quickly to that. If you go back to some of the market size slides, we have a lot more to gain -- and so marry that with making switching easier and our competitive advantage. Like I'd take that trade any day. Yes. And in terms of monetization, the new features our price, they will -- as people use them, the consumption will be charged for the underlying compute and usage of that. However, it shows up through Atlas consumption, and that's very purposeful because we want everything from free tier user getting started, kind of those 40,000 developers signing up every week to experience the entire platform, build from the start with any of the capabilities and not be gated behind certain contracts to get access to certain features. And then the usage of those different capabilities, if it was just using a database illustratively, maybe we get $1 for that particular workload, but if they use stream processing or search or other capabilities in the platform, we're not just getting that $1 per workload, we're getting $1.20, $1.30, $1.40 and so on, the deeper they use the capabilities.

Jason Ader

Illustrative numbers, not?

Michael Gordon

Illustrative numbers, yes.

Brad Reback

Brad Reback, Stifel. Historically, you guys have talked about, I think, the better part of two to three years for net new apps to sort of reach a steady state of usage. That's because they're net new. But if you think about relational migration with an existing app that's being replatformed, should we think about that getting to higher usage levels much faster from your previous experience?

Michael Gordon

Yes. I mean I think the way that I would describe that is if you have an existing application that you're moving over. There's a known workload. There's a known set of usage. And so compared to like the average new workload, yes, certainly, that will consume more out of the gate in that month 1, year 1, whatever kind of time period you want to look at. And I think the corresponding factor for that specific workload would also be -- the normal pattern is we see pretty healthy growth for first few years. It slows off, it's still growing, right, but the growth moderates over time.

I think you'd see sort of a different dynamic where it would start larger and probably be at more moderate growth because it's already like an existing installed application. So there are kind of trade-offs in both ways. But if you think about the market, while we will be better positioned to win many existing relational workloads and each year, we've won some more dollars of relational displacement. There's still so much new that's being built, right? If you look at the growth in the market, right, the market size stats have $12 billion or $13 billion of new every year, right? And if you take the $80 billion that we have today and just for simple math, amongst ourselves, just decide on a 10-year average life, there's sort of $8 billion of replatforming and so the relative market still was more in the new even than they were platforming, although clearly, we're getting better and have more opportunity to win in the replatforming side.

Sahir Azam

I think there are also a couple of different patterns that happen. Sometimes an entire kind of monolithic app gets shifted over and that's a mature app and certainly, that can start larger. But with many of these complicated environments, they're peeling off functionality kind of piece by piece. So they're kind of taking a monolith and breaking it down into micro services, and that ends up being more incremental growth over time. So it depends on the pattern. And I would say the same thing applies to MongoDB migrations. We see community or enterprise advanced migrations, those tend to come in larger than a new application because it's mature through.

Howard Ma

Howard Ma with Guggenheim Securities. Kudos on JemPak in a lot of substantive content in a clear and concise manner. Can you guys talk more specifically on the monetization time line for Atlas stream processing. To what extent could you talk about it within this context? Like to what extent are your customers building applications on top of process real-time data today? Like is it in the minority? Or is it the majority? And what is the process of getting off of, I'll call it, a competing solution. I mean, they could be custom-built, it could be Apache Flink or Spark or Storm or even in Hadoop.

And my understanding is that sometimes it takes that the migration from batch to real time can take a while. So how should we think about the monetization playing out?

Sahir Azam

Sure. I think the idea of event-driven applications or real-time applications is definitely emerging. And even if you look in the -- like the revenue of the streaming transport and platform players, a lot of their use cases are things that are focused on generalized CDC and plumbing around -- of data around the infrastructure. That's not really that interesting to us. What's much more interesting to us is how those -- that data empowers the application. That today is a minority percentage of the overall streaming revenue pie, but is growing because applications are your point, getting more real time, getting more event-driven. And that's we want to skate to where the puck is going and not try to be just a commodity kind of plumbing player.

I think the product is early. We just released a demo today. We'll go into a private preview and go through that typical arc of making sure the quality performance is there before we really hit the gas pedal on lighting up our enterprise sales team and running heavy enablement and all of that to push that out...

Dev Ittycheria

But I do want to add, our conviction is very high here because what I talked about at the keynote is that we believe stream processing is a natural fit for a document model, the flexibility, the scalability, the data is mainly Jason, it's all developer-centric, it's kind of our sweet spot.

So there's plenty of work to do, but our conviction is high that we have a real opportunity here.

Michael Gordon

I would say the other thing away from stream processing specifically, but just macro when you think about monetization, when you think about the developer data platform, I think it's tempting and in some conversations, you all ask about, okay, what's the uplift from X or what's the value attribution to why? And I think in some context, it's also important in the context of this much larger market with so many workloads to win. Some of the time, it's actually creating the winning of the workload in the first place, right? It's the breadth of the offering and the integrated experience and the simplification that, that all provides. And so there are a lot of different ways to think about monetization that might notice be like, oh, what SKU is showing up on an invoice and what revenue can you directly attribute it? So I would just encourage you all to keep that in mind as well.

Rishi Jaluria

Rishi Jaluria, RBC. Really appreciate all the detail and announcements today. Maybe continuing on that trend. If we think about a lot of these newer offerings like search or streaming or vector, -- what do you think about the ability to actually land net new customers with those products rather than I think a lot of us are viewing this as you land on database and then you expand into these newer use cases. And what would you need to do from a product or go-to-market perspective to maybe see that happen more often?

Sahir Azam

Yes. Our core focus is to Michael's point, accelerating the pace at which we can acquire more workloads because we're more differentiated by having all this capability collapsed into a single system. So I mean it's a crude and allergy. But like an iPhone has 3 or 4 different devices collapsed into a phone. We wanted to feel like there's 3 or 4 different separate components or more over time, collapsed into a single database. So the way we measure success is the velocity of new workloads that are lightening on platform. And then secondarily, the dollar share that we drive per workload, but through the depth of usage and how broad of the platform they use, as opposed to saying, okay, we have to go after XYZ market share of some other segment of the data market.

We're in a fortunate position where we have almost endless runway in the core operational data market. It's about differentiation, and unit price for workload, I would say, more so than it is trying to pivot the go-to-market to a completely different model. Now these technologies have different competitors, different value propositions. And so there's certainly an amount of sales enablement and training that goes into it. It's not automatic. But it's not like completely different business unit with a different sales team that has to go after a different buyer. It's all very much streamlined the line to the -- go to market.

Dev Ittycheria

Yes. And to that point, I mean, if you look at search, we are winning workloads that we would not have normally won, not just on the search component, but the entire workload because people see that as 1 big workload and now that the value of putting it all together in 1 place, has enabled us to win workloads we would not have won if we just had our OLTP engine.

Ivan Feinseth

Ivan Feinseth, Tigress Financial Partners. Congratulations on all the great announcements today. On the number of customers that are over $1 million in billing, how many have grown from a lower level that your functionality and services have helped drive that growth? And then what would you say has been your key advantage to winning large customers? And then the announcements you've made today, where do you think you have either first mover or best mover advantage that will accelerate that?

Michael Gordon

I think almost all of our 7-figure customers started as 6 or lower, bigger customers, right? I can't remember the last time we just started with a new customer who started at 7 figures. So to the chart that Michael showed where greater than 5 years, the size of those customers were demonstrably larger our whole methodology in terms of how we go to market, to win workload by workload, which also means that you need to have a long-term orientation with that customer. So for example, we -- our sales incentives and some of you have followed how we've kind of evolved our go-to-market operation -- our sales incentives are very inherently driven for long-term behavior. We're not trying to get salespeople to go close a 7-figure deal this quarter because one that really happens.

And two, the more confidence customers have with the first, second and third workload, the more business comes. I think I've talked about in the past, you go from like the side door where you've kind of chosen because the existing tech stack doesn't work, then you go to front door now and you go in the proved vendor list. But the goal is really to be on the loading dock because you're like a standard and they're saying, our default standard is to go with MongoDB. And that does take time. And those five-year customers who are north of 7 figures, we've become the standard.

Julie Bhusal Sharma

Julie Bhusal Sharma at Morningstar. Just going back to the relational database opportunity. In 10 years from now, what would you expect like that mix to be of MongoDB workloads that originally came from relational conversions?

Sahir Azam

Yes. I think the rough numbers in any given quarter today are 20%-ish, 30%-ish, if we don't manage to that metric really. In fact, I give my product manager on Relational Migrator a hard time because I don't want him measuring on the percentage of our total workloads because we want as many of the new workloads as possible, and we don't view that as a zero-sum game. But certainly, it's conceivable that if we remove more and more friction in the ease of mature applications moving on to the platform goes up that, that number could go up because today, it's still a very highly manual process.

Dev Ittycheria

Yes. I think, I mean, 10 years ago from now, there'll still be a lot of relational. I think there's a large ecosystem of other tools that people use. That's just learn behavior, changing behavior is difficult for people -- for some people, -- and then as I said, there's got to be some catalysts to replatform just going to wake up and say that app sitting in that corner, I just want to now replatform. So there's got to be some compelling event for them just consider replatforming. But we think we should have obviously a lot more share over the next 10 years.

Michael Gordon

Yes. The other thing I would just caution about is the over-index on the percentage of the numbers, you can get pretty quickly lost in the weeds where all of a sudden you talk about someone who's replacing functionality, but because they're doing so much of a rewrite, maybe also moving to the cloud and modernizing it, all sort of things. If you ask them internally, they may call that a new application, not a replatforming, even though you're actually replacing relational technology. So I wouldn't get overly hung up on the percentages or the specific numbers, but certainly, we see the opportunity in the trend.

Miller Jump

Miller Jump from Truist Securities. So I guess, Dev, you had mentioned search earlier is just an area where you all are seeing some success. That was obviously an area where there's some enthusiasm during the customer panel today. So I was just curious, when you actually look at that market, is it that you're going in and displacing other search tools throughout all of those use cases? Or can you just talk about the extent to which you can add new use cases through your search tools as well.

Dev Ittycheria

I'm not sure to answer the second part of your question?

Miller Jump

So I guess, is it always displacement sales with these search use cases or the --

Dev Ittycheria

It could be a new workload where they recognize they need to have key tech search functionality, but they're deciding should I go with -- you have to remember, when a customer thinks about building an app, they're revisiting what tech stack do they use, right? So almost it's like a micro decision for every new app you want to build, like, okay, what tech stack to use for this particular use case. So in that scenario, they may not even have an existing search data base, but they're saying, okay, do I go with like some combination of Elastic and Mongo or do I just go straight with Mongo?

So -- but we are -- for -- we have seen displacements where customers said, I have an architecture. It's [indiscernible]. I want to move everything to MongoDB. And as -- and again, I would still say we're in the very early days of search, and that we have a lot of opportunity as we improve the add more features, add more capabilities that continue to drive the performance of those capabilities, there's a lot more displacement opportunities available for us.

Sahir Azam

Yes. And I'll add, the displacement opportunities we're laser-focused on where we see all this runway is application use cases that are driving the actual software experience. We're not focused on observability here security analytics. We see that as sort of a different segment of the market that requires completely in some cases, different go-to-market model, and there's so much appetite for customers to consolidate technology on how they build these applications that we -- there's a long runway ahead.

Michael Gordon

And with that, we're at time. Thank you, everybody, for coming. And have a good rest of the day.

Dev Ittycheria

Yes. Thank you all for coming.

For further details see:

MongoDB, Inc. (MDB) Investor Session at MongoDB.local NYC 2023 (Transcript)