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

The first time I met Dev was 2006. He had this amazing company called BladeLogic, which was a fabulous IPO and passed it public for a couple of quarters and then you're now back at an even more exciting company. Congratulations and congrats to you as well.

But let's talk about at a high level, MongoDB, what -- Dev, what are your goals? What are your aspirations for the company 4 to 5 years? Let's say, you come back to the Goldman Sachs Communacopia and Technology Conference, what is it 2027, what would you like MongoDB to look like at that point and what are your strategic goals and how do you plan to accomplish that at a high level?

Sure. So we're going after probably the largest market in enterprise software, and it's been dominated by one vendor for a very long time. We believe we're offering a very disruptive way of working with data. It's proven by the fact that we are the most popular modern data platform in the world today. And right now, we have a small percentage of shares. Even though it's a big market, we're a $1 billion business, even with a small percentage of share. But we think that the opportunity in front of us is enormous, and we're aggressively pursuing it. So we would like to be the -- essentially the default where people build modern applications, and we think we're on that way on that journey there.

And how big could that be? I mean, it's a big market, and I was just -- we had a chat with Judson Althoff, who is the Chief Commercial Officer and he said that he thinks about you guys, by the way, good partners of MongoDB. And we were struck by the fact that the database market is now the fastest-growing market in software. Used to be GDP-type growth where people like, oh, it's boring. Now it's the fastest 17.6% growth rate, right? And you have a small share and you have this amazing potential. How big can MongoDB be?

We think we're going to be a very large, if not a seminal software franchise. But I think the reason for that is when you look at software, I mean almost every company today, some form of their value proposition is enabled, defined or created through software. Which means that developers obviously very, very important to every enterprise or company's journey in terms of enabling or transforming their business. And developers have gravitated to tools that enable them to be very efficient and effective in the way they work. And one thing we've proven very clearly is that we enable people to innovate very, very quickly using MongoDB which is the reason why we're so popular. If you look at any kind of studies out there, we're considered to be the one of the most popular database platforms and the most popular modern platform out there. And the only people who are more popular than us are technologies that have been out there for over 30-plus years. So I think we've proven product market fit. We've proven that we are truly a mission-critical platform by virtue of the size and diversity of our customer base and also the use cases that people are running for, using us for. And so for us, it's all about kind of driving future growth.

Got it. So on the topic of future growth. I mean things that work for our company, congrats you went from $100 million to $1 billion. Such strategies get you to that point. And there is less than stellar successful rate going from $1 billion to $2 billion, and $2 billion to $5 billion, $5 billion to $10 billion, $10 billion to $15 billion, $15 billion to $30 billion. What -- as these study companies that have gone through those phases, infrastructure software companies, what are the things you've learned and how do you plan to adapt your strategy to achieve your goals?

Yes. So because we're going after such a big market, we quickly realized early on that you can't just have one mode of going to market. The typical way is hire a bunch of field salespeople, try and cover as much territory as possible, scale them as fast as possible. But we knew that didn't make sense because of how large this market is. So we have not only just an enterprise sale organization, we have a mid-market team that's predominantly inside sales. And then we have a self-service business. We also have a partner organization. And the partner organization works with both like large partners like our hyperscale partners as well as SIs and ISVs because this market is so big and it's a very large ecosystem. So I think we've been very innovative in terms of thinking through how to go to market, not everything start at day 1. We've listened to customers. We also changed the way we engage with customers with our cloud business. The classic enterprise software motion is to get someone to sign up for a big commitment upfront. But in the cloud business, when the customers don't even know how large or how much their app is going to grow, it's very hard to get them to commit out early. And we realize given the high retention rates that we have and that databases and data platforms are so sticky, let's just get them on the platform, and that's paid huge dividends for us as evidenced by Atlas' growth the last few years.

Got it. I know this is the basic tenet of Mongo and how you're structured as a database. You have foundational technology and how that's relation -- different from the relational model. If you could just touch upon that, where do you see this as an enduring competitive advantage on the company? You've got millions of dollars in revenue. To go farther, can document model really help supplant the relation database technology out there? So what is -- what are the challenges that you need to conquer more to make this even more mainstream as successful as you've gotten to this point?

Yes. So we obviously -- for those of you who followed us and noticed -- probably known that we've built out our capabilities, and so we are addressing a wide variety of use cases. The document model is really a super set of other models. It's a super set of not just relational, but key value store. It's a super set of things like bill graph, we already have a time series capability. So by definition, our developer data platform is, in some ways, enables a vendor consolidation play. So what we've heard very clearly from customers is they don't want to use a net new use case for every net new -- I'm sorry, net new technology for every net new use case. And so because the cost of learning, managing and supporting all these different technologies just becomes overwhelming. And so we're seeing customers gravitate to our platform to run a variety of use cases, and I'm sure a lot of you have done your channel checks. And so we have some of the largest companies in the world running very mission-critical workloads as well as startups whose entire business runs on MongoDB. And so that gives us a lot of confidence. And I would say, what I also want to add is, a lot of people don't realize the limitations of relational databases. Essentially, there's 3 core limitations that we address. The first one is that how you model data in a tabular format is very counterintuitive to the way developers think and code. You think about like a product SKU or a customer SKU. You have to disaggregate that data and put it in a bunch of tables. So the cognitive load on a developer is very high as we think about modeling and managing their data model. The second issue is that it's very hard to add features, right? So as the data model grows, it becomes more and more difficult to add new features, so you slow down the pace of innovation. And the third issue is that relational databases are not designed to scale. They're designed to be truly single-node systems. So MongoDB was designed from the ground up to be a highly distributed platform. So we address -- the intuitive nature of how developers think and code is very analogous to documents. You can set up relationships between different entities in a very easy-to-understand way. It's very easy to add new capabilities fast and allows you to scale massively. So we have some of the largest applications of the world running on MongoDB. So given those attributes, that's why developers are flocking to MongoDB. And which is why they're using us for so many different use cases.

Yes. Somewhere later, I do plan to ask about the financial services discussed with the $1 trillion balance sheet customer. But moving over to Michael, current macroeconomic environment. I know you reported just recently, consumption models. Everybody is just so focused on consumption models. Can you give us a bit of a primer? How much of your Atlas revenue is a fixed component versus a variable component? Is that likely to change? Is that contract by contract sort of different? How different are you maybe -- are you -- maybe you're similar to Snowflake, maybe there are some differences. Help us understand.

Yes, sure. Happy to, and thanks again for having us here, Kash. I'll walk through a couple of different things. I think the key thing to remember is, if you think about our business, Atlas, which is our Database as a Service offering, is 64% of revenue in the most recent quarter. GAAP requires us to recognize that revenue on a consumption basis. I think it's important to remember as consumption has become a little bit more of a topic among investor circles, it's not really a business model, so much it is as a rev rec. And the business model is sort of the underlying value that you deliver for your customers. For us, when you think about the way that the opportunity plays out, both over the long term as well as the short term, it is easiest to bifurcate the universe and to think about new customers that we're winning and new workloads that we're winning within existing customers as sort of one dynamic. And then there's a different dynamic as it relates to the expansion of existing applications that are already on our platform. And in terms of the new applications or the new logos, those are the biggest driver of our success in the medium to long term. Shorter term, it's more disproportionately affected by the growth of existing applications. And so when we look out on things and we see what's happening in the market, obviously, there are macroeconomic challenges. Despite all that, we've continued to have exceptionally strong new logo wins, incremental penetration of existing customers in terms of new workloads. That shows up in the numbers in Q2. So in Q2, we had a record quarter of net new additions to our direct sales channel. We didn't see any of the elongation of sales cycles or deal slippage or other issues that some of the other companies that reported commented on. We haven't seen any uptick or increases in churn or any of those kinds of dynamics. And so all the leading indicators that are the primary governors of our success over the medium and long term are actually quite strong. They're basically flashing kind of bright green. In terms of the short term, though, to your point, we -- our business model is -- the underlying data platform, our developer data platform, the value that our customers get, the value that we provide to our customers is very close, directly correlated to the underlying usage of the application that they're seeing. And because we're general purpose and because we're so broad-based and so well diversified, it does mirror the underlying economic activity. And so what we've seen this quarter, which we started to see at the very beginning of in Q1, is slower growth of existing applications, still growth, not contraction, but slower growth than what we had historically seen given the more muted economic environment. And so if you think about single workload. If I had a normal life cycle where I went along and then there was more activity and I kind of needed to upgrade to the next instance size given all the requirements and the storage, compute and the reads and the rights and everything, that's just taking a little bit longer. And so that manifests itself through in terms of our revenue and then with the consumption, the way they recognize it. I'd say the only other thing to, sort of not necessarily compare contrast but sort of point out a difference versus other people who also wind up recognizing revenue from a consumption standpoint, our value prop is the piece that's so closely linked to the value that customers are driving. And so we talk about slower growth. It's really a second order effect of the underlying usage of that application as opposed to the customer intentionally doing something, right? They're not looking and saying, "Oh, it's a difficult environment. I need to optimize my MongoDB spend." That's not really the dynamic that we see. It's much more about the underlying activity. Because if you think about our customers, they've usually spent their most scarce resource, right, engineering, developer time, right, what they're trying to drive competitive advantage from to build this application. And so they want that application to grow and to be successful. And of course, yes, on balance, they'd rather pay us less than more like anyone. But that's not really what they're trying to do. They want to see that application be successful. And so as we're seeing slower growth, it's really just because of the underlying usage.

Let's say, I'm one of these digital natives and I do a $1 million ACV with MongoDB and all of a sudden, the business slows down 365. I'm just hypothetically making this up 365 days a year, like doing nothing. In the last day, I just light it up. So what does it leave you with your ability to collect the revenue that I have effectively contacted with you for? At what point do you say, okay, your time is up. We don't care if you're doing -- not doing well, doing well, we're going to recognize revenue because you pay us.

Yes. So a few different things there. So first in that scenario, you're talking about an annual contract. Most of our contracts are annual contracts. Typically, what customers do because at the end of the contract, if I -- if it is sort of a user to lose it commitment. People tend to commit for less than they think they're going to spend and usually a lot less than they think you're going to spend. Because I know it's actually a commitment, right? And so that's part of the dynamic that happens. And so one of the things that we've done, though, over time, over the last several years, is we've purposely tried to reduce that friction around us negotiating, is it $1 million, it's not $1 million. You're launching this new application, you don't really know exactly how big or successful it's going to be. If I'm a salesperson and my commission's entirely driven off of how big a commitment I get, I'm going to spend all my time trying to convince you to do $1 million. You're like, I'm maybe only comfortable $700,000, whatever the number is. And we're wasting all this time and all of these cycles from our standpoint. And so what we've done is we've sort of reduced that friction. We've encouraged the sales folks to get the application on. If it's going to do $750,000, it's going to do $750,000. And because, as Dev said, we're going after one of the largest markets, one of our biggest challenges is our footprint coverage of sales, right? The database market, $85 billion in 2022, going to $138 billion in 2026. We have quota-carrying headcount measured in the hundreds of reps, right, versus our competitors at 1,000 or 10,000. And so anything we can do to synthetically increase our footprint coverage is helpful to us. And so we don't want to have the salesperson wasting their time on this negotiation with us haggling with you about the commitment. We'd rather just say, you know what, you're comfortable with $700,000, great, fine, commit, move on. Look, let's not worry about that extra. We watch the application grow. Obviously, I have to set it up for success and things like that. Because what we know is when we're in competition, we have exceptionally high win rates. And so the challenge for us is just making sure that we're in the conversation and part of that speaks to footprint, which is why we continue to invest in sales and marketing.

Got it. So that's -- so it's a good way to think about the consumption model. So 2 thoughts. One, maybe two questions. One is what does it look like coming out of the cycle? How does the consumption model for Mongo Atlas particularly behave and what are the things we should be expecting to see? As crazy as it might sound, how does it look like coming out of this in a more positive cycle? Jan Hatzius is my boss boss's Chief Economist, he's talking about a soft landing, and that could be not bad at all, right? So if we do have a soft landing and things sort of gradually normalize, how does that consumption model behave? Do people say, oh, so shortsighted. I mean, $750,000, why am I worrying about this, maybe let's step it up and catch up. Have you seen things that happen before? What is the likelihood?

Yes. So a few thoughts. One, obviously, we'll leave the economic call to Jan, but -- exactly. But -- and then also, we'll -- we've provided guidance for the balance of this year. Come our March call, we'll obviously talk about fiscal '24. But I think to the point, we have a very diverse customer base. We're very broad-based. We're general purpose and so we see use cases across the board. And so I think when there is more economic activity, we do benefit from that. We've got a historic -- we're building up a history with Atlas, right? Atlas isn't that old, but we're building up some history. We have some pretty normal ranges of what expansion looks like. We've talked about how recently we've been on the lower end. A year ago, we were at the higher end of those ranges. And so we'll obviously have to watch and wait and see. But certainly, more macroeconomic activity is good for the continued growth of the underlying database usage.

We're going to give you a bit of rest and resume the consumption debate. And I want to switch to you, Dev. Relational database replacements have been a thing -- a theme in your quarterly earnings conference calls. What do you see as a trend in your pipeline? Do you see bigger bolder things as far as replacing RDBMS is concerned?

Yes. So it's pretty clear to most people that they want to get off legacy platforms. And so then the question is, how do they do so? One of this -- one motion is just stop paying the Oracle tax. The other motion is like, hey, I really want to modernize in my environment. And so we're seeing...

Run it on OCI. I mean take the database and run it on OCI and becomes cloud.

We have seen that many customers doing that. So I would say -- so the -- what we see is a lot more demand or a lot more interest from customers about accelerating the replatform so much so that we actually introduced a new product called Relational Migrator to help automate some of the work and effort required to migrate from a relational or legacy platform to a more modern platform. Again, it's in early days. It's only being used by professional services team and it's meant to help basically people quickly model what would the schema look like in MongoDB versus the existing schema on relational database. And we already -- and this is a journey. We've already had people doing that in the past. We've had SIs build their own tools because they see so much demand for this. And so we wanted to come out with our own product, and ultimately, we will give it to both our partners and ultimately to our end customers. But we want to make sure we work out all the kinks because there's a lot of corner cases you have to work through to kind of make sure that you can serve and support a wide number of use cases. But there's a lot of demand. And yes, you're right. On the earnings call, we talked about a bunch of examples of customers who are migrating off relational to MongoDB. And by the way, it's not just started, it's been happening since our IPO, but we're seeing clearly more demand for that for 2 reasons. One, obviously, the economic environment is driving that. The second reason is that I think people are so much more comfortable today than, say, 5 years ago when we went public to truly run mission-critical workloads on MongoDB.

And you referenced a customer that it took 4 years for them to see the light at the end of the tunnel and then on the document model. Is that an Atlas deal, Dev, or is that platform?

So what's happening is that a lot of these large financial services customers, they're one of the sectors that's been slower moving to the cloud for a variety of reasons, one of them in regulatory constraints. And so as those constraints start loosening, they, by definition, so they're going to make a platform shift and maybe even shut down their own data centers, they're starting to look at what are the new technologies. And so 4 years ago, and we used to -- we know them well, and they were user -- reasonable-sized user MongoDB. We used to challenge them like how come -- why don't you just standardize on us because we can do all these things. And they were -- they had to say, hey, we have one of everything. So we're not ready to standardize anything. Fast 4 years later and essentially, what they saw was that their development teams have flocked to MongoDB en masse. And so this say MongoDB popping up everywhere for a whole bunch of use cases both internal use cases on-prem as well as they're starting to run even workloads in the cloud. And so that's when they came to us and said, we need to essentially put our arms around this, have an enterprise agreement because it's clear that you're becoming a de facto standard, let's make you an official standard. So it's still very early days for that customer. We still have very low wallet share, but the opportunity is very large.

And that it's a consumption model. So if this bank is successful.

So it's a mix. It's a part EA and then there's some cloud.

So your revenue should scale along with the deployment [indiscernible]?

Again, that's another important thing. Our unit of value is workload or application. We want to get more workloads on our platform as fast as possible. Sometimes that's through acquisition of new customers. And that's -- and for existing customers, there's acquisition of new apps that they've already built or plan to build.

Got it. Coming back to you, Michael. So 2020 second quarter, second quarter was a tough quarter for many companies. And then third quarter, you start to see the beginning of some kind of improvement and then fourth quarter, things are up and running. When you look at the MongoDB business model due to maybe partly because of the fact that it's Atlas -- you're tilting towards Atlas in a pretty big way, your improvement, your acceleration really did not happen until Q1 of 2021. And then after that, you're off to the races, right? Is there anything discerned from that? Is there a lag between improvement in actual new business bookings that, let's say, ServiceNow or at Workday or Salesforce saw in the third quarter versus the first quarter? And then you obviously -- every quarter, you showed back-to-back acceleration. Anything you take away from that?

Yes. I'd maybe say a couple of things that are hopefully helpful. I'd go back to this framework that I offered up at the beginning of sort of the difference between new workloads, new logos, new workloads within existing logos. They tend to start off small, but they wind up having a bigger impact over the medium and long term as you sort of add on the layer cake of workloads or cohorts or however you want to think about it. So that's sort of the first thing. And so yes, as we continue to win those, you wind up seeing the benefit from those several quarters down the road. And then the second thing, which is worth calling out, which I know all of you as investors are not only good at math, but you understand the benefits of compounding, but that plays through in terms of our numbers as well. So if you think about last year, in Q3 of last year, we talked about how we had an exceptionally strong expansion of existing applications within that quarter. And not only did that benefit Q3, but they want to bet in Q4 because Q4 not only had very strong growth in and of itself. But the starting ARR, if you will, at that growth rate was applied to, was higher than it would have been otherwise, right? And so that's sort of the compounding as it's billed its way positively. We've had a number of questions from folks, including during the day today, around our guide for the full year and sort of the implications of what our second half guide is and kind of the implied Q4 guide. And it's really that same dynamic in addition having a difficult compare sort of working in reverse, right, because we're now looking here and we see the compounding where we've had slower growth over what we expect will be a couple of quarters such that when you start Q4 on November 1, 2022, even if the growth rate suddenly reverted to historic growth rates, which is not our forecast, but just illustratively, it would still be a lower quarter because you'll be applying that to a starting ARR that will have been impacted by the slower growth that we have received in the preceding quarter.

You think the revenue would not be a leading indicator. There are other things that will be a leading indicator.

Right. And so that's some of the winning of the new workloads and some of the sort of flashing green lights that I was describing earlier.

Which you saw in Q2, you had like green lights. You've just been cautious in the third quarter, fourth quarter. I plan to ask this, but maybe it's a good discussion. Under what circumstances could that guidance prove to be conservative? And under what circumstances could that guidance not prove to be conservative, especially as we look at the Q4 implied 15, 17, right?

Yes. So one of the things that we've tried to do pretty consistently is be fairly granular and transparent about our thinking and our framework for how we're looking at things, and there have been a couple of moments in time particular. So I think at the March 2020 call, when the sort of first few days of the general global lockdown was happening with COVID as well as what we did in the June call of this year of June of 2020, where there was sort of signs of some macroeconomic weakness, but they hadn't really shown up everywhere. And what we tried to do is we just sort of said, "Look, we want to educate you as to how we as a management team are thinking about things." We sort of went through a fair amount of detail and kind of laid out our framework for what we're thinking about. And in the most recent call, we sort of marked that call the market, if you will, kind of gave ourselves a scorecard as all of you are...

Like mark-to-market?

Forecasters or we've had to put a stake in the ground, right? You got to sort of follow that, own up to that, have some accountability for how you did. What were the puts and takes. It's interesting because in March of 2020, we turned out to be more wrong than right, right, because part of what we saw was more risk on the horizon of deal execution and everything else. People sort of forget that because things work really well, and we executed very well, and so it's sort of all positive and people sort of forget that our -- some of our assumptions turned out to be wrong. If you go forward to 2022, most of our call was correct in terms of what would happen and how we'd continue to see some of the initial weakness that we saw in self-serve spread across the business, both by channel and by geography. Obviously, we didn't get everything right. There's some puts and takes and some things are right and wrong. And in particular, there's more weakness in Europe and more weakness in the mid-market. But as we've mapped out all those things, I think if you're an investor, part of why we give that to you is so you can say if you have a different macro view or a different lens you can dial up or dial down the assumptions because we've been fairly granular about giving you the piece parts about how we're thinking of it and you could say, okay, therefore, I think that, that's an aggressive assumption or I think that's a conservative assumption. That's part of the reason why we do it is we feel like our job is just to help give you as much information as we can to make your own point of view.

With that, I'm going to do a pulse check given the number of clients in the room. Questions, please ask.

If we go back and use your layered cake analogy that I think is really illustrative during COVID when a lot of digital transformation technologies were kind of ramping and ripping, you guys use the layered cake as example to explain why this wasn't expanding as fast as other in place. Why is it working in kind of reverse now when you talk about the existing part of business that if your underlying customers are slowing, why are you feeling that? If you weren't kind of -- it was a layer in the layer cake is in then and it's really about ramping new workloads. So is it about the workloads they're not migrating and they're not ramping new workloads?

No, I would -- I think I'd take a slight issue with the once the layer the layers in. Like once you land a workload, like it's not the next several quarters or the next several years of that aren't immutable, right? They will be affected by economic factors and underlying usage and everything else. So maybe the simplest way to think about it is, again, try to isolate an individual workload and understand like what the journey looks like. And if you think about if I'm a new customer, I pick a workload, I pick an instance size, I launch my application, I have some activity, I start to see more activity. I need to increase my instance size, and that happens in step functions as you move up. And if along that set of step functions, it takes me longer, right, I stay longer at that same level, my growth rate will slow. And that's basically what's happening in these applications. It's the underlying rewrite intensity of the application is growing more slowly, and that maps to, therefore, the underlying usage and like how much more I want even to spend per application. And it's all those all stacked on top of each other.

Got it. Good question. Any other question?

Maybe one on [indiscernible] portfolio. As we think about the portfolio growth that are required to [indiscernible] how do you think about the incremental like S&M for sales market [indiscernible] required to get to like a lot of kind of get that incremental [indiscernible].

Yes. So the buying behavior of using like infrastructure software is quite different than, say, kind of business application software. A good example would be like Workday. So every organization is going to standardize on one HRIS system. It'd be silly if like finance used one version, and marketing will use another and sales use another. No one does that, right? There's one top-down decision and everyone uses the same HRIS application. But then the trade-off in that business is that an account may have made a decision to go with Oracle. You really can't go revisit that decision for at least 3 to 5 years because it takes -- that's how long it'll take before an organization starts reassessing that decision based on maybe the contract size or how much time -- how long it takes to see they're getting full value. Whereas in our business, there's no such thing as an Oracle shop or a MongoDB shop or a Postgres shop, et cetera. I mean, in our largest customers like that bank that was referred to by Kash, I mean they had one of everything or multiples of everything. And so we have to win almost every new workload through sales and marketing, more sales at that time once you're in an account. Now it does get easier. And there's some seminal things that happen in account that makes it much easier. One of them is being declared a standard, right? So I joke with people that the early days of accounting goes through the side door because the existing team can't use existing tech stack to address this use case so they use us. We prove our value, then we kind of get endorsed is like, hey, you should consider MongoDB. At some point, we become part of the mix, but we're not necessarily declared a standard. Then the third step is now we're in the loading dock for every new application, there's maybe 3 T-shirt sizes and 2 of those include MongoDB and 1 maybe doesn't, right? And so now you're part of the standard framework. And so in this cloud world, one of the seminal events for us is negotiating what's called a cloud services agreement. It's quite an onerous negotiation because as you can imagine, both the customer and us will haggle over like indemnity around breaches. And we obviously don't want to be responsible if someone didn't put any passwords or incorrect passwords or create some $100 billion on their own, and they obviously want to make sure that we're doing all the right things to secure their data. But once you get through that, that, by definition, becomes they're essentially giving us a hunting license to go win new workloads and now it becomes much easier. But they're not going to do that with every vendor they work with because the negotiating is still onerous. So most customers first start with the hyperscale provider that they're kind of working with, and then they'll go to the next couple of vendors that they think are going to be the most pervasive in their enterprise. So by definition, you only have that conversation if you've proven that there's lots of interest in MongoDB and you can address a wide variety of use cases. That's where our sales teams work on, which yields this negotiation with the CSA that ultimately then unlocks a ton of opportunity. And so that's typically the buying behavior of especially large customers. Smaller customers tend to standardize on one stack. And so most of our customers are running either all of their business or big parts of the business on MongoDB. And by definition, you're the standard from day 1.

And back to that comment about existing applications. That's not really where it's helpful or a good idea for us to spend lots of sales cycles on growing an existing application. That will either happen organically or maybe there's some customer success angle in terms of getting them to enable some of the incremental features, search or other things. We really want the sales folks focused on winning new logos or winning new applications within existing customers to sort of further drive the penetration to Dev's point.

That would actually compound the cyclicality of the rebound in a very nice way because you have got more and more customers that even if a few of them -- or even if each and every one of them grow the transaction volumes, it's slightly faster compounds to a good effect. Right. Yes, please?

Where do you think we are in terms of [indiscernible] legacy software providers like [indiscernible] and how long is that [indiscernible].

Right. So I think we're still in the very early days. I mean there's tons of legacy applications running in large enterprises and so we're in the very early days. And yes, you have to also understand that people don't get up 1 morning and say, "I want to re-platform." Right? There's got to be some reason to do so. And it comes down to usually 1 or 3 things. One, the performance of the application is degrading just because of by virtue of adding more data and more users and people say, like it's impacting user performance. Or two, you can't add new features quickly enough because the data model is so brittle that developers have to spend an enormous amount of time refactoring the data model to add any new features. Or three, the cost structure of that application is, relative to the ROI, it's providing us with untenable, so people want to migrate. So -- and so -- and large enterprise could have anywhere from 5,000 to 15,000 applications, they're not going to suddenly replatform everything. So they'll start picking on where they see the biggest returns in terms of time, replatform this app, whether it helps transform the business, end user pain or cost, that will drive their decision. And we're still very early. And so one of the reasons costs has suddenly become a bigger issue is because of this macro environment and people saying, "I know I have to get off this legacy platform, well, let's accelerate some of that." So that drove our release of Relational Migrator to help our customers start automating or helping our professional teams start helping customers automate the process to do so. But we're still in the very early innings of that.

You mentioned large financial service customer, chances are they have new Microsoft products in there as well. How do you think about the -- what's your strategy to send off Azure and AWS [indiscernible].

Yes, thank you for the question. So one of the things that's also important for investors to understand is that we have a very different licensing model. So a lot of the cloud -- many of the cloud providers build these large data franchises by essentially taking open source technology that was permissible based on the license, take the free version, adding extensions to run on the platform and offering as a service. I would argue actually open source as a service is the best way to monetize an open source. And so we have a very different licensing model. We originally started with AGPL, which is a more restricted license than, say, the GPL or Apache license. And then we actually changed it to have an even stronger license called SSPL. The net effect of that was that the cloud providers couldn't take our free version and offer competing MongoDB as a service against us. What they had to do was then emulate our features and functions, but building a clone service and Microsoft did this as well as Amazon, but it's built on a relational back end. And essentially, there were enormous feature and performance trade-offs. And we've actually benchmarked -- we talked to benchmark every new versions on our site. And literally, they have about 30% to 35% of the features that we do and the performance suffers greatly because again, relational back ends are not designed for scale. So essentially, over the last -- so I remember the time, in January 2019, Amazon announced its competing DocumentDB service and it kind of freaked people out, our stock took a beating. And I made the point at the time with investors saying, this is actually a huge validation for this market. And we knew that we could go ahead and compete against them. But obviously, people don't watch the space, they did actually assume that oh my God, is MongoDB roadkill. And if you look at our growth, Atlas has only grown faster since then, right? Because one to validate the market and our win rates against them, as Michael said, were very, very high, same with DocumentDB. The deals that we worry about are not the deals that we're competing on. It's the deals that are happening as virtue of their larger distribution channels, and we're just not party to. So we want -- that's why we've been trying to increase our footprint, both organically and synthetically to try and find more customers to go talk to. What's interesting is we've seen a sea change in terms of the cloud providers because what they have noticed is that as we win more workloads, we actually drive more value to their clouds. In fact, our Atlas business is significantly larger than both DocumentDB and the Cosmos DB API that Azure has. But we drive so much more business that there's been a sea change in terms of their approach to us. So much so that Amazon and now Microsoft incentivize their salespeople to get quota credit and commissions for Atlas deals running on their cloud. And customers can apply their commitments through Atlas purchases. So it is incentives 2 ways.

There's gravity.

Correct.

Atlas is greater than the API, you made a reference -- financial reference, I wasn't sure if I completely got it.

So what we're saying is that Microsoft has the Cosmos DB API, which is their emulated DocumentDB service. We have pretty good information to suggest that our business is -- our Atlas business is meaningful, larger.

In terms of the relational back end, okay, got it. Yes, got it. With that, I think we're 16 seconds, 15 seconds down. Thank you so much for your attention and your amazing collaboration making this nice and live and proactive environment. Thank you, Dev and Michael, for participating. I hope...

Thanks for having us. Thank you.

Thanks so much. Next time, we'll find a bigger room. Sorry about that.