Great. Thank you to everyone for joining us today. My name is Mike Cikos. I am the lead analyst here at Needham, covering infrastructure software. With me, I'm pleased to say we have the management team from MongoDB, CFO and COO, Michael Gordon, as well as the SVP of finance, Serge Tanjga. Thank you to both of you guys for joining us today. We really do appreciate it as part of the Needham Growth Conference.
Thanks for having us, Mike.
Thank you, Mike.
I know we're going to be tight on time here, so we're just gonna tackle it right up front, but one of the things I received a decent amount of inbounds on, obviously, has been the December security incident. Just to kick it off, can you kind of put any parameters out there as far as how extensive the unauthorized access was with respect to the customer base, as well as just set the table? I'm sure not everyone was following the blogs like I was, but anything else you could put around that would be great.
Sure, yeah. Thanks again for having us. Happy to dive right into it, and let's start with that. So as we shared, we were the subject of a phishing attack that gained access to certain of our corporate applications. The unauthorized person got access primarily to customer contact info and other account-related information. We found no evidence of unauthorized access to Atlas clusters or the Atlas authentication system. Those are two different systems. So that's sort of important to note. At this point, our investigation is complete and closed, and so I think that's sort of the quick headline. I know these are somewhat common, and unfortunately, increasingly common events, you know, across the landscape.
We tried to take a very transparent approach, you know, with customers and everything else, and so, from within a matter of days of getting, you know, of determining that there had been that unauthorized access, we alerted customers and therefore kept, you know, the public abreast with various updates on our alerts webpage and everything else, and I've gotten a number of kudos from customers for doing that. So that's the quick summary.
Maybe just from a logistics standpoint, but is it fair to assume then that there might be incremental costs related to forensic partners on the security side of the house or cyber insurance, Non-GAAP that out? Like, how do we think about that?
Yeah, nothing material. I mean, obviously, yes, when you, you know, responding to one of these, you have some incremental costs, you know, that you had intended. We did retain, you know, third-party, you know, help, et cetera, et cetera. But as of right now, nothing that we would attend to, you know, Non-GAAP out or anything like that.
Great.
I think from a materiality standpoint, obviously, you've got to run through all the assessments, everything that while we disclosed it, you know, publicly, you know, that was more because we were disclosing to our customers rather than because it was material financially.
Understood. And thank you for the qualifier on that.
Sure.
Want to shift to consumption for a second, but just so the audience knows, and I know I'm gonna be bobbing around a little bit, but there should be a chat box on your interface, so if you want to send in a question, feel free to do so. I'm going to try and get to as much as I can while we have Michael and Serge here as well. But please send those questions in. On the consumption, so again, just taking a step back, can you help us think about the consumption trends that we've seen through calendar 2023? And really, I guess, what occurred in Q3 versus your expectations, and how did that influence your assumptions when thinking about the Q4 guide?
Yeah, maybe I'll take a first stab at that, Mike. So, I'd actually start a little bit earlier-
Yeah
... than fiscal year 2024 or calendar 2023. So starting in the late first quarter of fiscal year 2023 for us, so calendar 2022, effectively-
Mm-hmm
... we started to see a macro-induced slowdown in consumption. We were among the first people to call it out, incorporate it in our guide and so forth. We've sort of done it before it really started, but we thought we saw enough evidence at the end of Q1 to make it a part of our Q2 guide, and then in Q2 of last year, so at this point, five or six quarters ago, we did see that slowdown materialize. Since then, we've had periods of seasonal strength and seasonal weakness and frankly, you know, some just natural variability in the numbers, and we've tried to kind of be transparent along the way and give investors sort of our latest thinking.
But now, with the benefit of hindsight, if we look at that period, effectively starting in Q2 of fiscal year 2023 through Q3 of fiscal year 2024, and also how we thought about guide for Q4, is we've seen a relatively stable environment, just the growth was at a lower level. So there'll be periods of strength, like the back half of Q3 tends to be seasonally strong. There'll be periods of seasonal weakness, like around the holiday season, and we try to take that into account, when we provide guidance, and certainly when we provide commentary in terms of how we've done vis-a-vis our expectations. But generally speaking, there's sort of like a range of consumption outcomes, and if you you might recall, we showed that chart at our investor day that kind of shows-
Yeah
... like consumption at a, at a certain level before Q2, and then at a lower level on average since then. And yes, there's variability around that average, but we've been in kind of that slower, stable world since then. So let's just take a general construct. For Q3, and now we're in a world in which we have been in the world of slower macro for more than a year. So what we're trying to do is give you color versus our expectations, but also versus last year, and you should expect that we'll, we'll kind of continue doing that going forward. But, in Q3, consumption trends were in line with our expectations. We did see a seasonal recovery in Q3, meaning seasonally, Q3 was stronger consumption than Q2.
However, the seasonal recovery was not as strong as it was in Q3 of last year. Now, you might ask yourself, "Okay, well, if it was not as strong as last year, why did you expect that?" The reason why we expected that is because generally speaking, we are seeing less variability in consumption in fiscal year 2024 than we did see in the back three quarters of fiscal year 2023. We have some, you know, reasons and hypotheses why that might be the case, but that's what we're observing. So as a result, we sort of thought that we would have less of a seasonality benefit in Q3, and that's what's transpired. When it comes to Q4, two things to keep in mind.
One is that we told you in December that we expected to see a seasonal holiday slowdown that plays out in through December and January. That's usage-based, like everything else in our model. Underlying application usage is what drives our consumption growth, and we just see application usage take a breather during the holiday season, and that drives our consumption growth as well. Then another thing that we called out when it comes to Q4 guide, which isn't a consumption phenomenon but is important as you think about revenues, relates to unused Commitments. So in Q4 of last year, we talked about several million more than normal unused Commitments.
That happened because, frankly, that was the last big batch of customers that kind of signed committed deals before macro slowdown, and as a result, on average, there was more than normal unused commitments. That was important to call out, particularly when it comes to sequential guide and how people thought about the beginning of this year. But the thing to keep in mind is that we have unused commitments every quarter. It's normal course of business. It's a minor portion of our business, but it's always there. In Q4 of last year, we had more of it, and that's why we called it out, in the context of a Q4 performance of last year.
Now, as you think about Atlas year-over-year growth rate or sequential growth rate, for that matter, in Q4 of revenue, you got to keep in mind that last Q4 benefited from $several million incremental of unused commitments, and we do not expect that to reoccur this year.
Got it, got it. And you're already answering my next question. So just to tease that out, again, as far as quantification, we haven't gotten anything more specific, but $7 million, and then it is something that impacts your each quarter. But the reason for the call-out specifically in Q4 of last year was because it was larger than what you guys typically experience.
Yes, and just to be clear, we didn't say seven. We said several.
Several, several.
Uh-
Okay.
Yes.
Okay, good.
So, it turns out that the bid ask spread on several is larger than we thought it was, but that's as specific as we got it, so we're gonna stick with that.
Yeah, and I think you got this, Mike, but just for the full audience, that's sort of the incremental. The several million is the incremental over and above what we kinda normally would have expected or sort of normally see, with that, given the dynamics that Serge talked about, where you've got, you know, people who had commitments before macro slowed down, and therefore what we wound up was kinda disproportionately more.
Got it. And maybe to tease out one more item on the consumption, but we actually hosted another consumption rev rec model-based company last week, who's actually talking about a potentially steeper than expected drop-off in relation to Christmas, because Christmas this year ends up on a weekday instead of a weekend. Is there anything that you guys have seen? Again, I'm trying to think because we're all in this new consumption environment, trying to figure out how these holidays flow through these consumption models.
Yeah, we haven't specified in terms of the size of seasonality we're expecting to see in Q4. The thing that I would say, though, is our underlying source of variability might be different than other people.
Mm-hmm.
This is where, like, you know, you've heard Michael and me say in the past that, like, consumption is not a business model. Consumption is a revenue recognition sort of requirement. So the driver for us is the underlying application usage. So literally, as you just think of yourself as a person who interacts with apps as a consumer and then interacts with apps in your place of business, you just do less of that during the holidays. You also do less of that during the summer, and then when you're back in the fall, you do more of it, which is why we see positive seasonality in the back half of Q3, and that's what we just see around the holiday.
What day of the week doesn't really matter, 'cause people don't work on Christmas, or we wouldn't posit that it would matter for us.
Mm-hmm.
And so as long as people are taking vacation, as long as they're using those vacations to, you know, detach from applications in their life, we see a slowdown in usage and therefore a slowdown in consumption growth for us.
I do, I do think it's an interesting point, though, Mike.
Yeah
... to your comment, and I know a lot of people are trying to understand or familiarize themselves with the trends or understand it at a deeper level. And without standing up on our soapbox, to Serge's point, just because it's a common rev rec model doesn't mean that the business model is the same. And so I think for any company, it's a good idea to sort of ask that question or to probe further and say, "What is driving that underlying usage and consumption?" Right? And so, for us, to Serge's point, I don't think it happens to particularly matter a ton whether where Christmas falls in terms of days of the week. And for others, it may, right?
If the consumption is driven by analysts deciding to run queries, and those analysts are, you know, on a holiday or not on a holiday or this, that, or the other thing, like, that'll all affect things just like... But ours is at a more sort of fundamental, you know, read, write transactions of the database. And the beauty of having as diversified a portfolio as we do... is you can't just pinpoint and say, "Oh, it's this one thing." You know, we're all about e-commerce, and so we get this bump here or this lull here. You know, we've got a portfolio of applications, not just given the size of our customer base, but given the breadth of use cases.
But it does have some of these underlying seasonal trends that Serge was talking about.
Got it. And two points I'd like to highlight with respect to, I guess, population of workloads as well as the Atlas versus EA. And so, first, on workload population, what I'd say is like, while the growth of underlying workloads was impacted by this macro downturn over the last 12-18 months, right? That I think management's been consistent in saying that the number of net new workloads being brought to MongoDB has been relatively consistent or persisted. And so where I'm going with this: is it fair to think that, there's this large volume of, orphaned applications, if you will? And so if the macro were to improve or the consumption environment were to improve, that this, this cohort of applications should torque higher at the same time, like you get a springboard effect naturally.
Is that a fair characterization, or is that maybe overstepping or mischaracterizing?
So I think, I don't think of us as having orphaned applications-
Mm-hmm.
or certainly not having, if I followed the logic train, more orphaned applications as a result of macro. The, here's the way that I would describe it-
Yep.
... and the way that we've talked about it is that we have done a good job, despite the more challenging and uncertain macro environment, at continuing to win new workloads. The value prop resonates, and we continue to bring those new workloads, you know, on board, and have been satisfied with that progress. The growth of existing applications has grown more slowly, and that's this read-write, underlying usage dynamic that we're talking about, that sort of macro effect in. And in the shorter term, when you think about, you know, a large installed base, in the shorter term, the results will be much more dictated by the growth of existing applications than the impact from new workloads that you win.
Over time, right, if you take a 5-year time horizon, it's gonna be much more affected by, you know, the new workloads that we're winning now, you know, over that time period than the growth of existing. But in the short term, the growth of existing sort of, you know, outweighs that. We haven't seen a dynamic, like I said, that would lead to some sort of, like, orphaned, you know, application or whatever. And if you want to explore that topic, we can definitely talk about it more, but that, that's not something that we've seen.
Certainly, new applications, new workloads are applications, and so while they ramp, you know, more rapidly than your average application, or they grow more quickly in those first, you know, couple quarters, than an existing application, they are macro affected, right? And so they are, they are growing at a slower rate than a, you know, on quarter X than, you know, a new application would have pre-macro, right? And so that's a dynamic. And certainly the last thing, and maybe this ties to your kind of, you know, torque up question or part of the question or whatever, but is, we've sometimes been asked about, you know, inflection points and re-acceleration and things like that. And I think from what we've seen is we've been, you know, in a pretty consistent and stable, you know, macro.
And so to point to an acceleration from here, I think you would have to believe in an improvement in the macro. There are other scenarios as well that can lead to that, but sort of for this conversation, the one that's sort of the most relevant would be an acceleration of macro. We haven't seen the macro get better. We haven't seen the macro get worse, so we have no reason to call that. So when we think about our guidance, that hasn't been a call embedded in our guidance. And obviously, we'll continue to monitor the things. And in March, when we give our full year outlook, we'll kinda update it with the latest, you know, that we have then, but that's kinda how we think about it.
Okay. Okay. And again, on the Atlas versus EA that I wanted to address as well, and again, just wanna make sure I'm not mischaracterizing this, but like, when I look at customers that are bringing workloads on to EA, I think management has been consistent in saying, "Hey, we're, we're gonna meet you wherever you are in your cloud journey.
Yes.
But like, my, my view is that if you're bringing a workload to EA, it's just an on-ramp, essentially, for workloads over the long term that are probably eventually gonna end up on Atlas.
I-
Again, is that fair, or do you say, "Hey, there's regulatory constraints," or maybe it's just a modernization effort, that's not necessarily the case?
I think that's directionally right. It's shades of gray, or the customer specifics matter, right?
Mm-hmm.
But we that narrative that you're describing of sort of EA increasingly being viewed as an on-ramp to the cloud, I do think is correct. That doesn't mean that 100% of workloads will move to the cloud, right? You can talk to different customers, and that there are plenty that are still on-prem or mostly on-prem. You know, we shared at our Investor Day the ARR from our top 100 customers, and we kinda broke it down into who is mostly EA, you know, meaning 80+% of their ARR was EA, or mostly Atlas, meaning 80+% or more of their ARR was Atlas. And 85%, you know, of the dollars are one or the other, right?
Mm-hmm.
And so, people... Well, you know, there is an increasing hybrid world and all those kinds of things. The people who are running EA really are not in the cloud. They're concerned about it. To your point, it could be for regulatory reasons, or a whole long, longer list of reasons. You know, it could be data privacy, government sovereignty-
Yeah.
... you know, there are a whole long list of reasons. And in those places, you know, can you find developers who are frustrated that they can't modernize or do things? Absolutely. One of the ways that they can start to modernize is by picking MongoDB, right? And even if they're still running it in an on-prem fashion, they're doing a bit more future-proofing, and they're getting closer to their ultimate end goal for whenever they can kind of adopt public cloud. And I think we've also seen that evolution in the other way, where maybe a few years ago, moving to the cloud and modernizing were viewed as a little bit more synonymous than they really are.
I think people realize and understand that sort of adopting the cloud is just sort of one aspect of that, and that there are many other aspects to modernizing. So we see people pursuing it in all different flavors.
Thank you. And shifting over to product now, right? So I think vector search is the first one I wanted to tackle. MongoDB announced that vector search was in preview in June. In our view, I think one of the things that MongoDB strikes and says is, you guys have done a great job, let's say, featurizing or integrating newer technologies as they become available, right? And that's kind of established you guys as this general purpose database. Atlas Vector Search became generally available in early December. Just to start off with there, but how has customer feedback been? And then secondly, have you guys thought about maybe the percentage of customers that the Vector Search is applicable to? Anything you could do to frame that out.
Yeah, maybe I'll take a first stab at that. So, what we've said, really even before GA, which was early December, so, you know, a few weeks ago, is that we've been very pleased with the feedback that we're getting from customers. And incrementally, what I would say is pleased that, you know, there's been a sort of like a third-party validation of that feedback. So we mentioned the Retool survey, but there are sort of other things we've heard indirectly from people that gave us the highest NPS score of all the vector search products. And that was because... Sorry, that was before we went GA. Now, you might ask, if that's an unusual state of affairs, right?
The most liked product isn't actually yet even generally available compared to all the other alternatives that are out there. And I think that fundamentally speaks to the value proposition that we're bringing to the table. And the value proposition is the simplicity of working with our vector s earch offering, 'cause it's seamlessly integrated with the operational database. And that demonstrates, that speaks, A, to the value of the product, but indirectly speaks to the pain of having to stitch multiple individual services together to create this offering, which, if you're going with a standalone vector search solution, you would need to be doing, right? So I think that the validation that we're getting is for the work that we've done, but also for, like, really understanding what is the pain point.
The pain point is operationalizing this and making it, making it easier for the developer to actually deploy and get some value from it. I'll just maybe sidebar before I get back to vector search for a second.
Please.
What I particularly like about the Retool survey, and the fact that, you know, it kind of demonstrates sort of the value of our product market fit and sort of the specific value of our value proposition, is that it actually applies more broadly, sort of related to your point, to other things that we've added to our portfolio. You know, whether it is traditional search, whether it is some of the stuff we've done at the edge, whether it is analytics. Ultimately, customers don't wanna have these multiple point solutions. They don't wanna deal with the pain of integrating them in the background.
Ultimately, the developer data platform vision is all about making the developer jobs easier by solving more and more of the developer problems that relate to data in a sort of behind-a-single-pane-of-glass and sort of with an elegant developer experience. It's kind of, kind of great to see that, that value proposition resonates in a space that is particularly of focus to customers and investors right now, and where we're so early on, i.e., this was done before we even had the GA. So that's in the traction. When it comes to, like, how broadly applicable it would be, I guess the only thing I would say is two things. One is, it's very, very early days. Most of what we're seeing in AI really sits in the proof of concept category as opposed to, you know, deployment of actual production applications.
That should not be a surprise.
Mm-hmm.
And not only is it not a surprise because, you know, AI, even though it might not feel that way to the investor community, is still a relatively new priority to, you know, your enterprise IT executives. Secondly, they are increasingly realizing that their data is not ready to really help them build AI-enabled applications. That's an opportunity for us in the long term, but that's, like, the first impediment, sort of to kind of think about a typical enterprise and their data estate. So it will take some time. The thing that we have said, and again, this is exceptionally important, but really in the long term, is like, we think most apps will, one way or another, be AI-enabled, whether new ones or rebuilding the existing one.
But that's like over a really, really long time horizon, but obviously, you know, incremental benefit to us.
Yeah, I think it will become... You know, this requires, you know, a look out in the future and prognosticating a little bit. But if you just think about where applications are likely to go, it won't be the core part of every application, to Serge's point, but I think this will be pretty common feature functionality. And we've used the example, you know, that there was a point in time when indexes from a database standpoint were innovative. Right? And then they just became used as part of everything, and this has an aspect that's like a reverse index. It won't be used in every single application.
It won't be the core of every single application, but I think it'll be pretty foundational over time to just how applications, you know, are used, much like text search or, or other things. And so I, I think having it integrated in your operational transactional database is an advantage for us.
And probably more of a tech-based question here, like a two-parter, though. So when a customer brings a workload to MongoDB for vector search, like, when is the data being vectorized? Is it upon ingestion? And then the second part is like, when is the embedding model then being employed? Is that like when the query is being called? Again, sorry. I'm just trying to figure out how this process flows through.
Yeah, maybe I'll take a first stab at that. So, actually, both the data and the query need to be vectorized. And in both, and at both times is the embeddings model used. So the way it works is-
Okay.
If the application is ingesting data, whether actually creating it or getting it from an S3 or somewhere, at that moment it's vectorized, and at that moment, you use, like, a third-party API, you access an embeddings model, you create the vectors, and then you store them into MongoDB. So that's, like, step number one. And step number two, now there's a query, there's an actual question, there's an-
Mm-hmm
... RAG architecture use case that's being applied, and there's a question being asked. You need to vectorize that question using the same embedding model so that you can do nearest neighbor search and actually find the data that is in the multidimensional space most similar and most relevant. So it happens in both times.
Okay. Okay, thank you for that. I know we, we do have some questions that are coming in from folks. One of them, just at a high level, but how should we think about how much more consumption-intensive AI or vector search workloads are versus, I guess, the workloads we've seen more traditionally?
Yeah. So we get, we've heard that question before, and I would say two things. One is, it's early, so, it's kind of difficult to draw any conclusion based on where we are in the process of development that... But secondly, what I would say is, I'm not sure that will be the major driver. And what I mean by that, what we've seen over and over again with other applications, is that it's the popularity of the application that really drives the intensity of usage as opposed to the usage itself.
So if you have two video games on our platform, of which we have many, and one is a worldwide phenomenon hit, and the other one is just another video game, the order of magnitude difference between the usage of those two use cases is what drives the consumption much more so than, like, take all the video games on average versus all the other workloads on average, and try to figure out, like, sort of what's the incremental uplift for like, you know, the usage intensity of the video game. So really-
Mm
... the question is gonna be, how popular are these use cases gonna be? How many of the really popular ones are gonna end up on our platform versus somewhere else? And that's gonna be the bigger driver than some sort of average uplift from usage.
Okay, thank you for that. And if we just shift over to Atlas search nodes, which also went GA alongside sector search in December. Just for background for the folks, but it allows customers to scale vector search workloads, which can have more demanding memory requirements independent of transactional workloads. And so wanted to get a sense here is, is search nodes, is that inherently tied to adoption of vector search, so the two go hand in hand, or not necessarily?
Primarily, the independent search nodes are driven by actual traditional text search, if you want to call it that.
Mm-hmm.
'Cause where we've come with sort of in the evolution of that product, so if you go back to our search announcement, it was in calendar 2019, and, you know, obviously, we're sort of disrupting that space where there's legacy, you know, players, and it's a very well-established market and one that's existed for a long time. And kind of like a traditional disruptor, you know, we start with relatively small use cases because, again, our value proposition is the integration. And then, as our product is improved, we're kind of moving upmarket slowly in this search market. And we've now gotten to the point where we see enough of the large search use cases, not vector search, traditional search use cases, where we heard from customers that feedback that independently tuning their search deployment-
Mm-hmm
... separate from the operational deployment would be beneficial to them. And so that's why we announced separate search nodes. Because it will allow them to scale the search separately from operational, which is sometimes helpful and certainly allows them to better optimize their use cases and their deployments.
Is that why, like I know, again, the company's discussed being able to run 60% faster query times with search nodes. Is it because of that independent scaling or not necessarily?
I don't honestly recall where the 60% number comes from, but-
Okay.
Either way, you're right. Like, we do expect that the queries will be more efficient, and generally, the search deployment will be more efficient. It comes down to two things. One is, you now have separate resources, so they're not in contention, right? Like it's not-
Mm
... one single cluster or node that's trying to do both operational read/write operations as well as search. So it kind of goes to, it stands to reason that with more resources, there'll be more efficiency and better performance, right? So that's number one. And then number two is back to sort of what I was saying, which is like, if you have a separate search node, which is only used for that, now you can optimize how it's being used specifically for search, and that ought to do better than if, again, if you're trying to ping the shared resource. So, so-
Yeah
... it is gonna be better performance, and it's gonna be more cost-effective for the customer.
Yeah, I think of them as both beneficial, related, but slightly different, right? I think the performance is the performance, and I think that the cost, which some people can include as part of the performance, but in this case, I break out the cost, is different. So part of what you would have had, maybe the simplest way to think about it is by having separate search nodes. To Serge's point, you can scale up or down the search nodes separately from your operational nodes, which, depending on if, you know, you're less search-intensive, more search-intensive, allows you to better optimize price performance along that continuum in a way that is advantageous to you.
Okay. All right.
That best fits kind of the contour of your workload.
Okay, and sorry, the last product here, it's you guys got a pretty robust roadmap coming over the next year, but stream processing, right? So has the company given a sense for when that's expected to become GA? And then secondly, just to flesh it out, while we have you, but can you discuss why tying stream processing to the database is the way to go in your view? Others would have you believe that stream processing should be its own independent engine.
Yeah, so I’ll take that to start, and Mike, feel free to add, obviously. So we haven't specified when we expect the GA to come out. If you look at our history, it tends on average to be about 12 months after it's been in preview. Not to say that that's, you know, a forecast or anything like that, but, like, that gives you sort of like the mean outcome compared to history, and hopefully that's a little bit helpful. And then on this question of tying, what do you tie stream processing to? It's not necessarily how we think about it. We saw a problem space in stream processing that we thought we could - we had a unique right to play in.
And what I mean by that is, streaming data tends to come with rigid schemas, not terribly flexible. We hear time and time again how developers are struggling to work with it. It's a nascent market, right? It's a nascent market in the sense that, like, no—you know, there's no TAM that you can go and ask Gartner or IDC about it. It's a new... Even the sort of the established players are relatively small in the grand scheme of things. But I think—we think part of the reason why it's nascent is because it's hard to work with streaming data with the existing solutions.
But outside of that, we saw a lot of similarities with sort of the state of the database market, when we decided to start the company and try to disrupt that market, which is difficulty working with data, rigid and inflexible schemas, opportunity to both provide better performance as well as make the developers more productive. So, like, those are the pieces, and on that level, we find great similarities between stream processing today and where the database market was like 15, 17 years ago when we started, and the problem that we tried to solve. So we're very, very excited about, like, sort of our individual right to play in this market, given our history and success that we've had with the document model. So that's point number one.
Now, point number two goes back to what we were talking about, even in the context of vector search. So now, if we're gonna build this product, which we think we can build a better mousetrap individually, you know, in and of itself, we're gonna, in addition, make it easier to work other products, right? And, and have the unified developer experience and make it so that, developers don't have to, you know, tie together too many individual technologies. And we think that that works for all our products, and because they're seamlessly integrated with all our other products, it ought to help the adoption of all of them at the same time. That's ultimately sort of the business rationale, if you will, behind the developer data platform vision.
Serge, maybe it's worth just two seconds talking about the difference between stream processing and stream kind of plumbing.
Oh, yeah, sorry, that wasn't obvious. So, like, stream processing is actually-
That may not be obvious to everyone, so just-
Yeah. So, streaming is a far more established market, which we sort of refer to as, like, the infrastructure or the plumbing of moving data around in real time. Stream processing is advanced operations and building that data inside the applications, which is still a relatively new market, while streaming obviously has been around, has many companies participating in, and the Kafka ecosystem is reasonably well defined. Stream processing is different and very, very new.
Right. Okay, thank you for that. Thank you. And just to be true to my earlier comments, I am gonna start introducing some more of these client inbound we've received. First, is there any rule of thumb on a multi-quarter basis for the degree of Atlas acceleration we should expect relative to average AWS or Azure acceleration? It sounds like people are looking at you guys versus the hyperscalers and thinking, is there a ratio like there are for maybe some other consumption names out there?
Yeah, we get that question every once in a while. We understand that some of the broadly defined consumption peers find this as a helpful sort of rule of thumb for their business model. We don't think it's very helpful for us. Like, ultimately, at the end of the day, we are driving the sale of our product. We keep our fate in our own hands. We partner very closely with the cloud providers, but it's not that, you know, AWS sends us buckets and buckets of workloads to sign up on our platform. They're also a competitor, don't forget.
And so we think that, we think that there's no, like, you know, fixed multiplier of, you know, if the AWS growth is this, then Mongo is gonna be in this type of range. And of course, generally speaking, if the cloud adoption, as a general rule, goes faster or goes slower, like there will be some correlation between the business models. But it's nowhere nearly as precise as like, let's put a ratio or even like a relatively narrow range. That's because ultimately, we drive our own sales.
Mm-hmm. And then the other question that we received was, as you guys shift away from a focus on big upfront commitments, which I know we haven't even had time to touch on the go-to-market here, but you've obviously seen headwinds on deferred revenue because you're prioritizing consumption now. How long is that headwind on deferred expected to last? Is this a multi-year item, or is it more just a couple of quarters? How close are we to getting through the other side of that?
Okay, yeah, let me just provide a little bit of background, then address-
Yes
... the deferred revenue question. So as you know, Mike, and as most investors know, we've been on a multi-year journey to reduce the importance of upfront commitment in our Atlas business. And this began, you know, in calendar 2020, actually, before COVID. Because frankly, we saw in the data that commitment introduces unnecessary friction to our sales process and slows us down, and probably provides suboptimal customer experience, and therefore, was not additive to us from the purposes of maximizing long-term value. There was a number of steps on that journey, since 2020, but in the fiscal year 2024, the year that we're about to finish here, we did arguably the biggest one, which is that we no longer pay on one-year commitments.
So far, up until this point, we made it more attractive to get paid on consumption, but still paid on commitment. Whereas this year we say, "Look, no commitment. One year commitment, you don't get paid anymore." You sign a $5 million one-year deal, doesn't matter, you will still only get paid on consumption related to that deal. And so why do we do that? Because, again, with large commitments, we saw that they were still a source of friction and misaligning us with our largest customers. And now that we've built multiple years of success and showing to our reps that there's a reason why we're doing this, and they, they will still do well, and the company will do well, we kind of took this big step.
So that started at the beginning of the current fiscal year, and it sort of went the same way we see other changes, which is, you know, the fiscal year begins, you roll out the change in your comp plans, you enable the sales team. But it's usually not until a few months later that you actually start to see changes in behavior, because they need to internalize it, they need to see their commission check, and then you start to see the impact. And the impact is, frankly, we see far less Atlas commitment. That's not surprising, 'cause our reps are not pushing it, and so to the extent that it's still happening, it's because customers are pushing for it.
And they're pushing for it, because particularly on a one-year basis, 'cause they hope they can get some incremental sort of discounting benefits, but those are really de minimis. So as a result, when neither party is particularly interested, you see a huge decline in commitments. And so you've seen that, and really, the first time you've really seen that it was in the second quarter of this year, and sort of the gap that we've seen between the op income and the cash flow line. Like I said, this sort of started this year, but it didn't really pick up pace until later in the year, so we would expect there to continue to be an impact from this change going into fiscal year 25.
Understood. And just last point here, and then we'll, we'll leave it. But is it fair to think, given... I know you've been on a multi-year journey with this, but last year was a big change, right, for the sales organization. So are there any learnings or anything we should keep in mind, again, when thinking about comparisons, whether on a revenue consumption basis, and then new workloads or sales payout that occurred last year, which may, may not be recurring this year?
No, not really.
Okay.
I would say that, you know, we've, 'cause it wasn't our first change.
Mm-hmm.
We learned a decent amount about change management and how to implement this and roll this out in fiscal year 2024. That's frankly the reason why you do it over multiple years. You do it to build conviction that you're doing the right thing, but you're also doing it to, like, demonstrate to the sales force, like, why you're doing it, and there's a rationale for this. And so it wasn't actually terribly disruptive, given the size of the change that it was, not in terms of sales attrition or anything like that. So it was a big change. You see it flow through the financials. We also see it on the volume of new workloads, which is where we started the conversation, and how good we feel about that.
But as you think about, like, what does that mean in terms of compares or mechanics or the financial model for next year? Nothing particular to call out.
Okay, then we'll leave it there. We'll leave it there. I, I do wanna be honest about that last question. So thank you very much, guys. I really do appreciate the time today.
Thanks for having us.
Appreciate it. As always, Mike, thanks for hosting us.
Take care. Bye-bye.