The absolute worst spot.
Yeah. Hey, guys. Welcome to our next session. Great to have the two of you on stage. Given that we just had Q3 results, maybe we start with actually, like, a summary from both of you. Like, how do you see the quarter play out? Like, how, you know, what were the highlights from your perspective?
Yeah. Maybe I'll start.
Sure.
And you can add some color. You know, we feel good about the quarter. We beat on the top and bottom line. As we said, consumption was slightly better than our expectations. We obviously were the beneficiary of some, a few multi-year deals on EA. I think EA speaks to the attractiveness of our run-anywhere strategy, where customers have the optionality to run workloads in the cloud, on-premise, move workloads from cloud to on-premise. And that's very attractive for customers, especially large enterprises who, you know, have very hybrid environments. You know, retention rates were very strong. Some people noted our NDR was at 120, which I think some people were surprised by. So, we feel the fundamentals of the business are very good.
Yeah. It was a good quarter. As Dev said, you know, strong new business both on EA and on Atlas, and then within Atlas, the consumption trends were slightly better than our expectations. So, all in all, a very good quarter.
Good. Okay. Perfect. And then you called out the multi-year deals, and I wanted to stay on that a little bit. It, it's like when I talk to investors, it was like, "Whoa, there's multi-year deals." Like, but that's a positive thing. Like, can you kind of speak to that a little bit? And I think it was in both, there was in EA and the other revenue a little bit. Like, I don't know if you have more color there.
Yeah. Sure. Happy to talk about that. So yeah. So the EA business, you know, first, just we take a step back. You know, we run the business on a channel basis, right? You know, customers have an IT strategy. They have a point of view on how they wanna, you know, run their applications. And so MongoDB coming in there and saying, "Run this in the cloud," or, "Run this, you know, self-managed," or whatever, really isn't how it works. And so our goal is just to make MongoDB easy for customers to use, regardless of their deployment choices, whether they're running, you know, on-prem in a hybrid model, in cloud, multi-cloud, etc., and so yeah, I think it's generally a good thing. I do think people tend to sort of sometimes, maybe over-rotate to Atlas. To Dev's earlier comment, the run-anywhere strategy, you know, really does resonate.
And so we've seen continued strength, you know, within EA. In this most recent quarter, we saw strength, EA broadly, but also incrementally in multi-year deals. And so the reason why that's important is from a business standpoint, it's great, and a positive to your point, because what that means is the customer is looking ahead, seeing more demand, wants to standardize or invest more in MongoDB. And so rather than signing, you know, a year-to-year deal, they kind of wanna lock in some certainty, 'cause they've got conviction in MongoDB as a platform. And so that's a good thing for us. And we continue to see that. The reason why it matters and affects the numbers is because of the accounting and ASC 606 were required to recognize the term component of the upfront, I mean, the license component, upfront.
And so in a multi-year deal, you end up recognizing more. And so just because that affects the numbers both this year, it also increases the variability and reduces the comparability and affects kind of the year-to-year numbers and everything else, is why we kind of talk about it a little bit, and when helpful, quantify it, to help people be able to kind of piece part things together.
But it's like, it's not. You're on the license side. It's not like, I mean, if I remember correctly, you were like 20%-25% upfront.
It's about a quarter upfront. So if you just.
Quarter.
Simplistically think about it, if you did a three-year deal, right, versus a one-year deal, if you had a one-year deal that was $100, you'd roughly take $25 upfront and the $75 over the remaining 12 months of the contract.
Yeah.
Whereas if you had the three deals, same concept, 100, 100, 100, let's not have a ramping deal or add complexity here.
Yeah.
$100, $100, $100. You'd recognize $75 upfront, and then that remaining $225, would go over the 36 months.
Yeah.
And the reason why that's important is because when you think about the comparisons, I think generally you all are very good at understanding what it means in terms of the base period, right, and what the how the denominator is changed. But I think what sometimes people forget about is the numerator doesn't have that term license component that it would have in year two and year three. And so that's what makes some of the comparability hard. The last thing, Rama, to your question on sort of the EA versus other.
Yeah. Yeah.
Or non-EA, non-Atlas. What we talked about is we talked about seeing more than $15 million of multi-year in this Q3 versus Q3 a year ago, really just from a few deals. One of those deals will show up in that non-Atlas, non-EA. While most of our deals, whether they be Atlas or EA deals, are one-year deals, that kind of OEM licensing, you know, kind of other, other category is probably the one area that sort of structurally is oriented to multi-year deals. We've talked about, you know, Alibaba as an example of what's in there. This quarter, that Alibaba was not what was driving it, but just illustratively 'cause that's one that's been named and they did a press release on. It doesn't make sense for them to do that one year, right?
They're offering an authorized MongoDB as a service offering, and so they wanna have multi-year, you know.
Yeah.
Certainty and access to our intellectual property.
Yeah, and then on that theme, like, and we talked about EA being stronger last year, and I wanna kind of link it to the theme of, like, app modernization. Is that kind of actually not kind of linked, that people want to start to modernize their applications and, yeah, it might go to Atlas, but you might wanna do it as on-premise as well?
Right, so just stepping back, so why do customers wanna modernize? You have to remember a large enterprise may have 10, you know, over 1,000, if not five or 10,000-plus, applications. Some of those applications were built 10, 15, 20, 30 years ago. Now they're looking at their architecture. A lot of those legacy applications have a tremendous amount of technical debt, so it's very hard to innovate. The cost and tax of managing and supporting those applications is very high, and for regulated industries, their regulators are saying it's your there's a systemic risk of being reliant on these legacy applications that need to be modernized.
There's some end-of-life issues, like Sybase has announced it's going end-of-life, so a lot of customers are having a, "Oh my God," moment of like, "I, I can no longer kick the can down the road." And so there's a confluence of events where customers are very interested in figuring out how to modernize. The biggest challenge in modernizing is not moving the data. It's not mapping the schema. The biggest challenge in modernizing is rewriting the application because there's, you know, potentially hundreds of thousands, if not millions of lines of code, and that, you know, would take a lot of man-hours to basically rewrite on a new platform. That's where GenAI comes in.
All of a sudden, people are saying, "Now with the use of GenAI, I can do a few things." One, I can analyze existing code because in some cases, those developers are no longer in the firm, so they only know, you know, what that code does. So they can analyze existing code. Two, they can then generate tests to really understand what does what, what does this code do, and based on this input, what outputs are generated. That's very important because when they reproduce new code or generate new code, they can then use the same test to say, "Does the new code do the same thing as the old code?
Yeah.
Because that no one's gonna migrate if they can't have certainty that the new code does what it's supposed to do. So all that work, which is very tedious, mundane, and labor-intensive, all of a sudden a majority of it can be automated, and that's creating a lot of excitement and interest. Then the question is, if I'm gonna migrate, why migrate to MongoDB? Well, people see it's a much more modern architecture, much more scalable, much more flexible, easier to iterate on. Not every app will go to MongoDB, and it's not like we need every of those thousands of apps to move to MongoDB, but a meaningful portion moves to MongoDB that will really drive long-term growth for our business. So we are very excited. Now, the sales process has multiple stages.
First, you have to prove, are you just, you know, are we selling snake oil or is this real? So we go through a proof-of-concept process with the customer, typically scoped somewhere roughly on three months. Some are shorter, some are longer, but that's roughly time to prove, can we do actually what we're saying? Because people wanna see it on their app with their own developments, people and all that to make sure this is real. So in many cases, some of those POCs have actually stopped because they've seen enough evidence to say, "You don't need to show me more. I'm ready to go." The second stage then is like, "Okay, which, you know, how quickly do we start?" And depending on the app, like, for example, we have a large global insurance provider who wants to rewrite their whole underwriting platform.
And so they're starting because it's a global platform and runs in almost every country they're in. They're starting with some countries in Southeast Asia, making sure that works before they deploy it to Europe and North America. So that will be a multi-year process, but we should start seeing revenue from that in the next six to nine months, if not sooner. Then some other apps that are smaller that we may see revenue sooner or may take longer depending on the variability of the app and how long it takes to migrate. We're seeing a high demand from large enterprises, financial services firms, insurance firms, you know, you know, telecom companies. Everyone's saying this is a big, big problem. And so we have a high conviction that this is a big opt-in for us.
This unlocks a big part of the TAM that we really could never go after because the cost of switching was just too onerous for companies. We had lots of customers migrate apps, but, like, there's some apps that just the people just felt like it's just gonna be too hard to do that. With GenAI, that's taken that off the table.
I heard that from the industry as well that, like, database migrations are gonna be so much more easy. Like, how much can you influence that in terms of providing the GenAI and the tools to that, or are you just basically an outcome? Like, you know, they know.
No.
You do it, and then you need to pick a database.
So, one of the things customers like is that they, you know, incentives drive behavior. Our incentive is to move that app off the legacy platform and run on MongoDB. Our incentive is not to have some long, elongated services engagement where we bring an army of people. So customers like that they're motivated to modernize as fast as possible, so are we. Obviously, we'll see an uptick in services, but that's not why we're doing this. We're doing this to drive more incremental ARR from these legacy applications.
Yeah.
And so customers like that. We'll obviously use a combination of our own services, people and partners because we just can't, you know.
Yeah.
Build out capacity that quickly.
I'm meant more on the tooling side, like on the GenAI tool. I mean, are they like, I get conceptually that you can use GenAI for that, but, like, where are we in real life?
Yeah. So we are using a combination of open-source tooling and third-party tooling. We've looked at all the, you know, we've evaluated a number of the code generation tools. We've given feedback. The code generation companies are super excited because this is, you know, one of a very compelling use case.
Yeah.
Like, you know, decomposing an, you know, an Oracle app with Oracle stored procedures is not for the faint of heart, and they're realizing, okay, this is, it's hard, but it's also gonna be a big, big opportunity, and so, so we're working with a bunch of them, and we're obviously picking and choosing which tool makes sense for which engagement. On top of that, we're building our own tooling because obviously we're optimizing it to migrate to MongoDB, so either we're using those tools and train those tools optimized for MongoDB or using open-source ourselves.
Yeah.
And so we have a whole engineering team focused on this endeavor. We have some field engineering people who are also working with our services people and the people on site to understand the learnings. You have to understand that this is a big but wide, highly diverse problem. There's multiple database types, versions, libraries, programming languages, development techniques that can run the gamut. So it'll be impossible for this to be like a one easy button, press this button, and voilà.
Yeah.
All the code is.
At the MongoDB.
You know, regenerated. There'll be a combination of services on top of that, but over time, that services component should come down.
And then, going back, Michael, now, I put you on the spot. Like, my pet project, or not pet, not my personal, was like, you know, last year we started talking about EA actually being stronger than you had guided.
Yeah.
And then it was part of that was people wanted to start modernizing. Is that like, if you think about, you know, what's gonna happen more and more now, is that gonna be like an Atlas or EA or both? Like, how do you think that?
Yeah. I think we see it in both. And we've been talking about, you know, for several quarters now, this sort of move-up market. I think, you know, some of that will be, you know, in Atlas for sure, but some of that will be, you know, in EA as well. And so we've continued to see strength in the EA business, for the last few years. Obviously, there is some variability with the multi-year, and we'll keep close and call that out. But a lot of the work on app modernization, is in the cloud, is Atlas. But, you know, as much as we talk about cloud and things like that in conferences like this, the reality is there are, you know, a huge number of organizations that have most of their, you know, applications, you know, still in a self-managed or on-prem environment.
Yeah.
And so I think it'll show up on both sides.
Yeah. I mean, to that point, I mean, a lot of European banks have been very slow to move to cloud. So if they're migrating, they're probably migrating to EA.
Yeah.
Right? So that's one example.
Yeah. Okay. Let's shift gear a little bit on. Let's talk about Atlas a little bit. So, like, if you look at the industry, you know, we have like Datadog coming after you, et cetera. Like, all the guys that are kind of like cloud native in their offering all kind of slowed down somewhat in the downturn, and it's like optimization, you know, less traffic for some of the digital natives, et cetera. If you think about your Atlas business, you kind of like, I saw it more positively because you kind of almost, you know, you're kind of stabilizing in the growth rate. And yes, you know, Michael is still guiding for slightly slower growth in the coming quarter. But, like, how do you think about the Atlas kind of story for you?
Yeah. So I think, you know, there's this tendency, you know, to think about or try to think about, you know, patterns and do pattern recognition as investors.
That's our job.
Yeah. Exactly. And people hear the word consumption, and they say, "Okay, they're all these companies must be the same or must have the same dynamic.
Yeah.
To your point, the dynamic is a little bit different. So it's obviously easiest for us to talk about what we see in our business, and obviously to the extent we could be helpful in comparing and contrasting it, what our best assessment of what others 'cause we do try to pay attention, you know, including to help, you know, inform or stitch these threads together. So what we see is we see an incredibly tight correlation, incredibly tight relationship between our consumption and the underlying end-user activity of the applications built on our platform. So let me elaborate on a couple of those things. When I talk about consumption, we talk about consumption growth. We talk about consumption trends. What we're talking about is the week-over-week growth in the underlying, you know, Atlas MRR, basically, right? or ARR, however you wanna think about it.
And that, as I said, very closely matches, you know, the underlying. Obviously there's some variability, but the underlying reads and writes in the database, right? And so the activity is driven based on how, you know, I'll use a generic word, but how popular, you know, the application is and whether that's an internally facing app with a customer, whether that's a revenue-generating app, whether that's a partner-based app. It'll be that interaction, you know.
Yeah.
With the database, those reads and writes that will affect, and drive the underlying growth. And so what we've talked about for probably a year and a half now, is we saw a step down, you know, related to the macroeconomic environment, of slower growth in those reads and writes, right? And that's really what's driving, you know, our behavior and what we see.
And then, I want to get to go-to-market changes a little bit. Like, but you talked a little bit. So that's the existing customers doing more with, you know, or more or less depending on where their business is going. But then you can further influence it by kind of adding new workloads.
Yeah. Right. That's the dynamic of an existing workload, right?
Yeah. Yeah.
The way that we talk about the business is, there's new business that we win.
Yeah.
That's kind of each quarter. We've, you know, despite any of the macro challenges that I think we've done a really good job of, kind of throughout. That shows up both in EA and in Atlas. We've had successful, you know, execution pretty consistently in winning new business. The dynamic that I was talking about in terms of that consumption growth.
Yeah. Yeah. Yeah.
That's of the existing workloads that are ones on the platform. And the reality is there's very little that we can do about that.
Yeah.
The other thing that we've talked about, you know, and maybe this is helpful in the compare-contrast category versus sort of some of the other players that have consumption dynamics is, for some of those, if you have, you know, we kind of put ourselves in the shoes of the customer, right? If you have a runaway bill, in some of those other players, my first instinct is, how do I optimize that? Right? How do I improve? How do I reduce my spend? et cetera. Whereas the more typical dynamic in MongoDB, if you had a runaway bill on Atlas, it would be because your application was very successful. That would be sort of the typical pattern.
That's part of the way that our dynamic, you know, particularly as a consumption, you know, player is different.
If I summarize it, basically you have two components. You have the existing.
Yeah.
And there are the workload growth within the existing wasn't. The new is basically there was no change. You basically consistently kept adding.
Yeah.
Yeah.
Yeah. And again, maybe it's too simplistic a framework, but we've talked about it this way with you all before, which is sort of like the things that we can control are winning the new business.
Yeah.
Right? How the application grows after that isn't. There's not a lot that we can do to make someone's, you know, internally facing app more successful or the revenue-generating app more successful. It's kind of like how we've talked about, you know, the AI applications that we have on the platform. Like, not, you know, a lot of them are struggling to find the product-market fit, 'cause we're still early on in that cycle. That's not something we can help them with.
And then, at the beginning of the year, you talked about, like, kind of headwinds you guys were facing. And there was one of them was, you know, when you kind of started to compensate your sales guys. That was, I think, the year before on consumption. So then, you know, like, if growth slows down, everyone tries to find an excuse or, like, finds an explanation. And so there was a lot of, like, you know, kind of focusing on that go-to-market changes or go-to-compensation or compensation changes. Can you speak to that? Like.
Yeah.
Is that kind of what's going on there?
Yeah. Let me just explain. So, when we originally kind of went to kind of what we call all in on consumption, which is really encouraging our salespeople to find as many workloads as possible, we assumed a portfolio theory of, like, as long as they acquire a large number of workloads, there'll always be some workloads that start growing very quickly, and that'll be net positive. As we, you know, examined our results from last year, we realized that, the reps do have some influence about what workloads they can go after. Sometimes a more complex workload will take longer to sell, but that may have higher growth prospects than just another workload. So we made some slight modifications to the comp plan to put more weight on the net new ARR component of the workload versus just winning the workload itself.
Like, there was a net new ARR, but we just weighted it slightly more. And we are seeing it's early days because you don't really see the full trajectory of these workloads after a couple of quarters, but we are seeing that the size of the workloads we're getting this year are better than prior years.
Yeah.
It remains to be seen how they grow. As Michael talked about, a big part of that is how the underlying usage of those applications grow. That was one change. What we announced in terms of go-to-market changes was, I think there's a lot of investors who thought they were more disruptive than they really are. Obviously, with Michael's pending departure, we moved a part of his COO functions under Cedric Pech, who was our CRO. We basically elevated his title so that he now owns really two more functions. One is the pre-sales engineering team and the professional services team. Under him, there's a gentleman who ran North America and Europe who we're now promoting to CRO who will own all the global sales teams. That's really the change.
And, to me, it's this makes sense given, you know, the, you know, moving some of the COO functions under Cedric and just the way we're organized going forward. So, I think people over-interpreted there's some big change in our go-to-market.
Yeah.
Yeah. I would just add to that because the other thing that came up was we were giving people an update on the priorities we laid out at the beginning of the year, one of which included moving more up-market or prioritizing dollars up-market. And I think people read that as an in-quarter or a prospective change and didn't understand that that was something that we were kind of just checking in on a couple quarters in from something we'd said beginning of the year. And so it just underscores what Dev's saying is there hasn't been some sort of major.
Yeah.
You know, pivot in the way that we've picked up a little bit over these last, you know, day and a half or so.
Then the other question that came up is, like, you at the beginning of the year. I think you talked about $40 million of headwinds.
Yeah.
And now to the question, right? I guess it's right for this, like, so if I kind of adjust that out, like, so how is Atlas growth doing if I kind of adjust that out? I don't know if you wanna kind of speak to that.
Yeah. No, I'll try and tackle that and at least do a little bit of marketing that to market, and then also recognizing that we obviously, you know, won't give fiscal 2026 guidance yet. I know people are sort of updating their models, and so can at least give, like, a couple of markers for, like, how we're thinking about it.
Yeah.
Things to sort of pay attention to. So in the fiscal 2025 guide, you're correct. We really talked about and quantified two specific headwinds. One was, in the move away from upfront commitments, we expected to have about $40 million, you know, less, i.e., 40 going to zero, or near zero, of unused commitments kind of going away that we benefited from in fiscal 2024 that we weren't expecting to in fiscal 2025, so that has been playing out as expected. That'll be a headwind that gets removed when we go into fiscal 2026. The other headwind for fiscal 2025 that we quantified was roughly $40 million. Unfortunately, it's basically the same number, which is mildly irritating, but.
Okay.
Because it leads to some potential confusion. But what we re-recognized roughly $40 million more of multi-year deals in fiscal 2024 relative to fiscal 2023. We talked about the surprising strength of multi-year deals in fiscal 2024 and driving some of the outperformance that we saw in fiscal 2024. So our assumption coming into fiscal 2025 was that fiscal 2025 would look more like fiscal 2023. What we talked about just on Monday's call was we've continued to see success of EA, yes, broadly, but also specifically on multi-year. And we talked about seeing more than $15 million of multi-year in Q3 of this year than we did of last year. And so if you're sort of kind of marking that to market, that basically means the $40 million headwind is more like $25 million.
Yeah.
And then as that relates to fiscal 2026, we'll kind of have to see how that goes, as we finish the quarter and everything else. The third thing I'd call out is we have talked about Atlas consumption, right? And again, that's sort of the week-over-week. And so it ignores the unused commitments, and everything else. Not a revenue number.
Yeah.
But it's a consumption number. It has been decelerating, right? It is lower on a year-over-year basis. It will be, and our expectation is it will be lower in Q4. So that's a factor to keep in mind for fiscal 26. Then the last thing, which I think sometimes people forget about but is quite important, is, you know, we have the performance on Atlas, the consumption growth. What do we see in Q4? How does this holiday season compare to other holiday seasons? We typically see a slowdown. So the way that the consumption results for Atlas in Q4 play out will be important because that really sets up the starting ARR of fiscal 26.
Yeah.
So those are kind of some of the things to think about.
Yeah. Yeah. Yeah.
You still didn't give me a 26, but okay.
No.
Yeah. Fair enough. Okay. So we can all address that. Dev, now that we have you here, we need to talk about AI a little bit or GenAI a little bit. If you think about it, like, there's a big debate, like, how does it impact your industry? And maybe start. I start tech debt broadly, and then we can kind of narrow it down. Like, from your perspective, you're a database vendor. What should it mean to you?
Right. So I think generally, and I'm thinking, like, zooming out, I would say AI by definition will be a tailwind for a business for a couple of reasons. One is that if you look at every platform shift, the cost of building applications has come down. We saw that from mainframe to client server, client server to internet and cloud, and then mobile. So we just saw this explosion of apps. The more apps you have, the more databases you need. So that's one. Two, we think that architecturally, we are the ideal database for GenAI applications. Why? One, GenAI applications need to be able to query rich and complex data structures, like semi-structured, structured, and unstructured data. We're optimized to do that. GenAI workloads need to elastically scale. We're designed to do that. They need to perform at a high level. We're designed to do that.
They need to be able to make changes very quickly. We have a very flexible and agile schema. We're designed to do that. You know, we can. We have very sophisticated ways to do aggregations and, you know, very sophisticated indexing mechanisms. We do that. We've bundled in vector functionality into our platform. We don't have a standalone vector database. Vector is bundled into our platform. So as you need vector embeddings and be able to search and do nearest neighbor kind of queries using vectors, that's built into our platform. So as one customer said, rather than having an OLTP engine, a search database, a vector database, and maybe a caching database, I could do everything in MongoDB. So architecturally, we think we are well-positioned. The other thing is real-time, right? So a simple example would be, say you have an AI chatbot.
You just put in an order. You never got a confirmation that the order went through. You go to the chatbot and saying, "Hey, what's the status of my order?" That chatbot needs to have access to real-time information, not historical information from weeks ago, but literally what you did minutes ago, and so the real-time nature also, we're designed to do that.
Yeah. Yeah.
So from and then, you know, we are the world's most popular modern database. Developers love using MongoDB. So given all those things together, we think we're well set up. And the third vector is, no pun intended, you know, the going after legacy app modernization, right? Because that was, again, a part of the market that was structurally hard for us to go after just because the switching costs were so high. We just talked about this. But that, you know, we think was gonna GenAI is gonna unlock that market opportunity for us.
For us, it's difficult because you have a lot of techie guys. And because it's a new world, everyone can make bold claims.
Yes.
and so it's very, and for us, we're just sitting here and we don't know.
Yeah.
How do you think of, like, you know, obviously the one with the boldest claims at the moment, like, and actually they're mostly tiny little startups. It's like Postgres that comes up a lot. How should we, what should we look at or, like, how do you see this going to play out?
One thing I would say is one of the things Postgres is the beneficiary of is that people are standardizing on Postgres off Oracle, off SQL Server, and off MySQL. Postgres is kind of becoming the standard relational database. Relational databases have two intrinsic challenges. One, the data model's not very agile. It's not because it's hard to make changes because you have to use this very tabular structure, and it's not very natural in terms of how you work with data because you have to decompose programming objects in your programming language to data across a bunch of different tables. That's a cognitive load. It's called an ORM process that developers have to deal with. The second challenge is that relational databases are not designed for performance and scale because they're designed to be single-node systems.
So in the old days, you just buy bigger and bigger machines. Now people do some funky things to kind of make it more scalable. But it, it basically says, you know, like, there's a constraint architecturally. MongoDB addresses both those issues. That being said, we don't, we don't view, like, Postgres has to die for MongoDB to succeed. It's not a zero-sum game. The market is huge. We're seeing a fair share of business. Obviously, if you're a SQL developer and all you know is SQL, you're gonna probably have bias to Postgres. What we found is that even in our largest accounts, it was kind of eye-opening for me over the last, you know, six months was that I'll give you a simple example. We had a financial services customer who grew from $1 million two years ago to $22 million in about 24 months.
So pretty, pretty impressive growth.
Yeah.
But when I was talking to the account team, there's still a very small percentage of developers in that account who know MongoDB, right? It's, you know, it was just shocking to me. And it just told us that the wallet share we have in these large enterprises is still very, very small. And so the more education we do, the more we help them think about, like, for the next application, how they can model that in MongoDB versus relational, it unlocks more workloads. So that's part of the move upmarket, is to deploy not necessarily all quota-creating resources, but more technical resources to just accelerate that education and enablement effort on MongoDB.
Yeah.
And so the point being is that, we see a big, big opportunity. And I don't expect every workload to go to MongoDB, but the workloads that require a lot of agility, you know, a lot of innovation, maybe performance and scale, you know, they're ideal use cases for MongoDB.
Yeah. Perfect. And I think our time's up. That's a good closing statement as well.
Great. Thank you.
Dev, Dev Michael.
Thank you. Thank you.
Thank you.