I'm Mike Cikos, analyst with Needham on the infrastructure and analytics space. With us today, we have the management team from MongoDB. Michael and Serge, thank you very much for joining us.
Thanks for having us.
Thanks for having us.
Maybe to start the fireside here, for folks who are brushing up on the name or newer to the name, can you kinda just walk through the value proposition here, what MongoDB is solving for for your customers, and how you're differentiating versus other offerings out there?
Sure, yeah. Maybe we'll just take a step back. The database market is one of the largest in all of software. The latest IDC numbers have the 2022 market at $84 billion, and that's growing to $138 billion in 2026. Very large market, but also actually growing at a fairly healthy clip. One of the questions is why is the market, you know, so big, and why is it growing so much? I think it's really because this is sort of at the heart of the strategic nature of what software is all about.
If you hear these phrases like, software is eating the world or every company becoming a technology company, those are all shorthand for the fact that companies today are driving competitive advantage on the basis of their internally built technology, specifically their internally built software. Right, off-the-shelf software isn't actually a competitive advantage 'cause everyone can go buy it. The way that I drive competitive advantage is I go build software. Every application that I build has a database at its heart, at the center of it, and that's really what determines the nimbleness, the speed, the agility, the scalability of your business. People today are hiring developers. You hear about Wall Street banks talking about having, you know, more developers than large, you know, brand name consumer technology companies.
Those developers are expensive. People wanna get more out of those developers. Developer productivity, speed, and rate and pace of innovation is really where, you know, we kind of come into play. The technology that sort of predominated previously is relational technology. That was really built for a different era. That was built for an era where storage was the big constraint. Storage was incredibly expensive in the 1960s and the 1970s when relational technology was pioneered. That's now not the case. We sort of help bring a different paradigm, almost a better mousetrap to help solve the challenges today. Happy to go into any of the details, you know, if that's useful or interesting folks, for folks.
That's really where, you know, our value prop, you know, resonates and the reasons why people are increasingly picking MongoDB. The other advantage, in addition to sort of having that developer mind share, is the general purpose nature of what we do. Rather than being sort of a point solution or built for sort of a specific use case, we have this general purpose positioning, that allows, you know, companies to ultimately standardize on MongoDB as their modern alternative. Why don't I stop there? I can go on and on.
Yeah. If I just think about the market for a second, right? If we're talking about the IDC estimate, let's use that.
Sure.
$84 billion in 2022 going to $138 billion in 2026. Have you guys broken down like how much of that is locked up by incumbents? How much of that is still held by, let's say, the relational databases, and how much of that growth is expected to come from non-relational databases?
Yeah. I'll say a few different things. I think the distinction relational, non-relational is sort of interesting but not relevant for us because we can serve all the different workloads.
Mm-hmm.
Many of the other folks who are challenging the incumbents came up with technologies that can only do certain things or have very narrow applications or sort of work for a specific use case. We're a little bit different way. Obviously, industry analysts have to come up with some way if you're Gartner or IDC or some way of like kinda describing or characterizing the market, but it doesn't tend to map our reality. We, you know, we win and, you know, a healthy chunk of business from relational people who run into, you know, if you're a customer and you're a prospect and you're running into a challenge with scaling Oracle or one of the other traditional legacy players, MongoDB, you know, can be picked for that.
It sort of underscores the fact that this sort of relational versus non-relational or relational versus NoSQL sometimes is how it's referred to, is not really the way the market plays out. How to think about the market, maybe a quantitative exercise we can use. I mentioned that sort of $84 billion going to $138 billion over four years. That's a little over $13 billion of growth every year, right? That tends to be new applications, new opportunities, people building new applications. Just for perspective, you know, large organizations will have, you know, not just hundreds, but thousands or even tens of thousands of applications that they've built internally. They don't tend to be just sort of one monolithic application.
We've got $13 billion of new growth in the market a year, and that $84 billion that exists, it's predominantly with the incumbents, to your point, doesn't do an RFP every year, right? Like it can be working perfectly fine, and if it's working perfectly fine, there's no reason to go change it out. If just for simplicity's sake amongst the group of us here, we say an average application is a 10-year life cycle, that means there's about $8.5 billion every year that's coming, you know, up for grabs. You marry that with the $13 billion, you've got sort of north of $20 billion a year that's kind of in play. From a technological standpoint, we at MongoDB can address that.
I think the one of the challenges, you know, that we have is developers are opinionated. They're smart. We've continued to evolve our product over time. The MongoDB product today is not the same MongoDB product that it was five or six or seven years ago. If you experimented with it back then, and we've got, you know, an open- source component to what we do, and so you're engaging with it in an uncurated fashion, you would've already said, "Oh, well, it was good for this, but not good for that." We've subsequently, you know, addressed that from a technical standpoint, so there are no technical constraints for why you couldn't use MongoDB, but we continue to invest in sort of the awareness and perception of all the improvements that we've made.
That's great. One more on the market opportunity, but you just cited, let's say this 10-year application life cycle, right? The way that the world is shifting, is it fair to think that there's a collapsing of those life cycles and they're...
Yeah, I think in general.
Going to move on to freeing up over time?
Yeah, I think that's right. I think of the 10 years as admittedly somewhat arbitrary and imperfect, and we could have.
Sure. Yeah.
... A whole session just debating how long that is. I think there's no question that whatever the starting point is, they are shrinking, right? Those life cycles are compacting, and you're seeing higher velocity, because, you know, just if you think about the way... your expectations as a consumer of how you interact with applications, you bring that consumer mindset to your work mindset. Even if it's not a consumer-facing application, even if it's a B2B application, you expect to interact with things in a fast, easy, intuitive kind of way. I think that's one of the many forces that's sort of driving application lifecycle shorter and ultimately making applications more, you know, making applications smarter, really. And we benefit from that trend.
Great. Shifting gears to let's talk end market demand, right? Especially in the current macro, what has been some of the changes you've seen, whether it's customer adoption, customer growth and consumption trends, can you just set the level there, as far as the audience that we have today?
Yeah, sure. One of the things that we've tried to do is sort of help break down the underlying dynamics that we've talked about, sort of winning new business and new workloads, and then the performance of existing workloads that are on our platform, and we found that to be a helpful way, not just for us to think about the business, but also to share and communicate out with all of you. To date, we've not seen any impacts on terms of new business from the current macroeconomic headwinds. It's been, you know, pleasantly surprising to see it's a testament to the product, it's a testament to the fact that we're in this big market and we're a relatively, you know, small piece of the puzzle, and it's obviously a testament to good, strong execution.
None of that, of course, precludes that from happening, you know, in the future, but to date, we really haven't seen those headwinds. We haven't seen the deal slippages or other things that some other software publicly traded software companies have talked about. We have seen an impact on consumption of existing applications, and that really relates to the fact of, you know, the consumption of Atlas, which is our Database as a Service product, directly mirrors the underlying end user activity with the application. It's really more of a second order effect of what we're seeing for our customers' customers or our customers' end users interacting with their applications. We've seen those grow at slower rates. We're still seeing, you know, growth within those, but we've seen those rates of growth grow more slowly.
It's broad-based, it's been across the board, across sector, across geo. As we sort of map and triangulate and kinda slice and dice, ties back to, underlying, you know, slower macroeconomic activity. The last thing I'd say, if you kinda try and tie the piece together, in the short term, our results are more impacted by the expansion of existing workloads and/or behaviors of existing workloads, just given the size of the installed base. Over the medium to long term, the much bigger factor, is how many new workloads, how many new customers, you know, are we winning. That kinda helps paint the whole picture.
On that last point, I do wanna come back to the Atlas and consumption trends.
Sure.
Why do you think the new workloads has persisted as far as the growth? Like, there's no change in new business you're seeing on those workloads, right? I'm just curious why that has persisted in this environment.
Yeah. I think there are a cpuple things. I think that, you know, what we're doing is incredibly, you know, high value. There is a stack ranking, right? That people are doing in terms of what, you know, what deals they're going to move forward with, where they're going to just spend money. People are being more selective about that. Doesn't mean we always, you know, win out. I think in general, the problems that we're solving are at the top of the list for folks, we've benefited from that and been able to execute well, sort of despite the headwinds.
I would also say, you know, it is a huge market, and so even if there are pressures or even if, you know, IT budgets wind up coming under scrutiny or things like that, we're, the vast majority of the time, a share gainer, rather than, you know, an incumbent who's got, you know, a lot to lose. I think in the third piece is we've done a good job from an execution standpoint. You know, our sales team is very focused, on execution. We have, you know, even unrelated to today's current environment, long-standing views around pipeline qualification, assessing things. I've heard some of these stories or examples or anecdotes that people have talked about with, you know, deal slippage or, companies, you know, customers, prospects introducing, additional approval thresholds.
You know, previously, you know, the CFO of company XYZ only needed to sign off $1 million deals, and they moved that down to a $500,000 deal, you know, because they're trying to provide scrutiny over the spend levels. Internally, from a salesperson, that would be a terrible excuse, right? Part of your job as a salesperson in terms of qualifying a deal and getting a deal across the finish line is to understand the paper process at the customer, right? You know, especially in the current environment, it's very logical that people change their approval thresholds, do all those things all the time. Part of just the day-to-day managing of the sales process is being aware of that and getting ahead of that.
Internally, it wouldn't fly very well as an excuse to go figure that out. I chalk it up to our execution and our focus on just kind of rigorous pipeline qualification.
Great. For the Atlas consumption trends this year, right? During 2Q, I think they came in lower than. There was a weakening in those consumption trends, right?
Yes.
In 3Q, we did see an uptick.
Yes.
Can you talk about the various puts and takes that led to that? Then we can start to talk about maybe some of the commentary you guys had as far as the guidance you had for Q4.
Yeah, of course.
Yeah. I guess I'll start us at the end of Q1. Walk us through at a high level what happened since then, and we can dive into any specific as a follow-up. Near the end of Q1, we started seeing slower growth in certain parts of our Atlas business when it comes to growth of existing applications, specifically in Europe, specifically in our self-serve and mid-market business. As we looked to sort of the underlying dynamics behind that slowdown, it became apparent to us that this is a macro slowdown. From there, we concluded that macro slowdowns tend not to be limited to a particular geography or a particular segment, but tend to be broader than that. Going into Q2, we expected business to consumption of Atlas to slow down everywhere.
That's largely what happened. We saw consumption slow down, and we provided a relatively detailed sort of checklist of how we expected things to play out when we provided our guidance in our Q1 call, so that would've been May. Q2 largely played out as we expected, but with some puts and takes. Most notably, and this was a, you know, significant topic of conversation with investors at the time, the European enterprise business and our mid-market channel globally grew slower than we expected it to. There were other areas that were better, but those two came a bit lower than expected. Fast-forward to Q3, consumption did better in Atlas across the board than in Q2, and that wasn't what we expected, and that wasn't implied in our guide.
There were two factors driving the improvement in Q3 versus Q2 as we understand it. First is, based on how Q3 played out, we believe we benefited from seasonal strength in Q3 versus Q2. The way we see that is that the back half of Q3 was better than the first half. Similar thing happened last year. It was driven by the underlying usage of the applications, and it was pretty broad-based. What we think is going on is sort of a seasonal back to school, if you will, or back to work after the summer phenomenon where people engage with the applications in their lives more than they did during the summer. We saw it last year, we are seeing this year.
It's only two data points because Atlas is a very young business still, so we can't precisely pinpoint and quantify the size of it, but we definitely think it was a factor in Q3, and we wanted to make sure we share. The second piece, which is over and above the seasonality, those areas that were particularly weak in Q2 or slower than we expected them to be, namely, European enterprise and mid-market, those did better. What we think happened there is that those customers paused the investments in the growth of their applications 'cause those were segments that were most immediately impacted by macro. You know, Europe shouldn't be a surprise in mid-market also because those tend to be younger companies. They went back to investing more in Q3, seems to us.
Doesn't mean that it's, like, the new normal, doesn't mean that, you know, we bottomed it in Q2 and that, and that, you know, Q3 is the right level to think about it going forward. It's just we wanted to make sure you understand that we did see those two areas of improvement. One is seasonal, and one seems to be more, you know, related to those specific segments.
Just to close the loop on the seasonality, right? 'Cause I think, during the earnings call, you guys called this an emerging seasonal trend.
Yep.
Right. To your point, Atlas was much younger if we rewind three years ago as far as its growth and its size.
Mm-hmm.
That's why we're defining it as being emerging currently, right?
I guess.
You referenced those two data points.
Yeah.
That's really why we're citing.
Yeah. I think, I just think of the emerging as, you know, shorthand for, like, a current working hypothesis or something.
Sure.
Like, we don't have enough data points...
Sure.
To sort of state it definitively or declaratively. When we look at it and use our best judgment, that seems to be a contributing factor.
Is there anything to think about for that seasonality besides back to school or vacations or is that kinda it as far as the way the world works?
That's what we see right now because it was pretty broad-based. Yeah, we can't sit in here, "Oh, it's like prep for the holiday season or anything like that." It was pretty broad-based in every geographies and across all industries, so we think it's fundamentally the way people talk, work with their apps.
Okay. Okay. Also on the consumption, you guys had specified that November, the consumption trends were, correct me if I'm wrong, about in line with what-.
Yep.
You guys saw in Q3, right?
Right.
The 4Q guide implied, I guess, consumption growth decels from what we had in November during December and January.
Mm-hmm.
I'm guessing that's based on, again, typical seasonality, holidays, maybe fewer days in those months.
It's not fewer days.
Okay.
It's literally the mirror image of what we saw, the strength in September and October, which is during the holidays, people engage with apps less.
Okay.
It's just less usage. You do other things during the holidays.
Is there a way? Like, if I rewind a year ago when we were in January, February, I know we've all learned that consumption models are different, right? Like, there was weakness cited from consumption models from Datadog, from New Relic, from Confluent. Like, there was a host of consumption models that we're talking about. Maybe developers were returning to work on a slower basis than what they had historically seen. Maybe there was vacation angst coming out of COVID. Did you guys, if we rewind a year ago, did you see that, and has that in any way been incorporated into the Q4 guide as we think about it?
We did not see that a year ago. Nothing other than normal, usage-based slowdown is baked into the current guide because we see no reason. Some of those parallels, like you said.
Mm-hmm.
Consumption sounds like it's all the same, but in fact, when you look under the hood, they're all very different. You gotta be kinda mindful of what is the actual driver for each of those companies.
Yeah. I think in those examples, at least as I understood them as I heard people talk about them, they were describing internal behaviors within their company.
Mm-hmm.
That were, you know, affecting things, or internal behaviors within their customers. What we're talking about is, you know, their developers, you know, showing up, people taking more vacation, whatever. What we're talking about is end user activity, right? So this is not confined to our customer. This is our customer's customers or our end users, consumers if it's a consumer application, you know, business users if it's an internal application. It's just sort of a different, you know, dynamic than what others have.
A more basic question on the consumption, but the pricing mechanisms, right? If I think about, let's say storage or compute or anything, like, is there a way you can give us broad brush strokes for how much revenue is being derived from each of those?
Do you not look at it based on those different mechanisms?
We don't look at it that way, and the customer doesn't buy it that way. The way to think about it is you have your application, it has a certain set of characteristics when it comes to reads, writes, transactions, usage of data storage and so forth. Based on that, you pick the instance size that you buy. That instance size is sort of fixed until your application growth changes it. For vast majority of the customers, vast majority of the time, the applications tend to grow. We think of it as sort of like a staircase of usage, whereas like you use a certain size of instance.
As the application grows, you get to the point where you now need a bigger instance to provide the same type of performance and characteristics to your customers. You upgrade. As you kinda move up that staircase, each individual customer has their own pace, and that kind of combined set of dynamics is what drives Atlas consumption.
Great. If I could just take another stab at it. If I'm thinking about the growth, like we're talking about new workloads versus existing workloads, right?
Mm-hmm.
Can you help us frame, like in a given quarter, how much of the growth is coming from existing versus new? Has that relationship been relatively steady? In the current macro, are you seeing maybe existing workloads growing at a slower rate versus previous cohorts? Like how do we think about all those factors?
I'd say a couple of things. Number one, in any given period, vast majority of growth comes from existing workloads. That shouldn't be a surprise, because new workloads, especially Atlas workloads, start very small. You know, most of what we do in Atlas is net new workloads, so they effectively start from zero. It really takes time for them to build and sort of make that impact. If you think in any given quarter and sort of in the near to medium term, vast majority of growth is driven by existing workloads, and that changes, but, you know, given the size of the base, it changes, you know, maybe slower than you would guess. Existing workload is a meaningful driver for near to medium term. To your second point, though, it's also very important.
Obviously, we get to look at the business not just in totality, but also across cohorts. What we've observed over the last couple of quarters, Q3 improvement notwithstanding, is that we've really seen a slowdown regardless of sort of the age of the customer, right? It's not just like that, like, you know, 3+ year Atlas customers have slowed down, but really across the board and yet again another reason to believe that this is, you know, fundamentally and exclusively a macro phenomenon.
Yeah. I would just add that all this consumption discussion is about Atlas, which, you know, this last quarter was 63% of revenue. The Enterprise Advanced business, which is, you know, the vast majority of the balance, does have ASC 606 revenue rec. It's affected by term license revenue. New deals can meaningfully change those numbers, you know, right out of the box, just so people aren't confused by that.
Great. If I'm thinking about like the, I guess, the customers on Atlas versus EA, have you guys spoken to, I guess, what's been the typical trend? Like is there a typical customer as far as migrating from EA to Atlas over time? How much of that should we think about as being a source of growth or does it in any way catalyze the existing revenue? Is there an uplift in spend over time because of that?
Yeah. The typical pattern would be of an existing Enterprise Advanced customer who's adding additional workloads and decides that they've changed their view as it relates to public cloud. We run the business on a channel basis. We want MongoDB to be easy for our customers to use regardless of their IT strategy. As much as people talk in conferences like this about cloud, cloud, cloud, the answer is not as many workloads are in the cloud as you would guess. We're still relatively early on, you know, in that journey. There's certainly particular industries or companies that tend to be more less cloud forward, you know, more focused on, you know, they either have regulatory concerns or other issues.
Over time, what we've seen is even within that customer base, which may, maybe some would characterize as a little bit more laggard or otherwise, starting to adopt Atlas workloads. That tends to be for new workloads to MongoDB. We haven't seen a lot of behavior or activity of someone taking an existing EA workload and moving it to Atlas. That certainly could happen or happen more, you know, over time. Unless someone's sitting here saying, you know, "I wanna get out of all my data centers immediately tomorrow. You know, I'm gonna move everything." You typically sit here and say, "I've got an application, it's working well. Like, why do I need to go move it?" You're looking for increased functionality, increased scalability. There are new applications or existing applications that aren't performing as well.
Those are good candidates to move to MongoDB. If you've evolved your posture around public cloud, maybe you say, "You know what? I'm gonna start to put those, you know, in the public cloud." The last thing that I'd say more broadly is I think historically there's been this sort of temptation to think about, even though we run the business on a channel basis, to think about, you know, EA customers as being sort of laggard legacy types and Atlas folks being new modern. That's increasingly not the case. You can see increasing adoption of Atlas within enterprise customers for mission-critical applications. That shows up in the numbers, you know, and that's been great to see. We expect to see that happen over time.
We're also increasingly seeing Enterprise Advanced customers thinking about as they expand their Enterprise Advanced footprints. Thinking about that as sort of a first step to cloud modernization, because you can run MongoDB in any environment, maybe they have regulatory or other concerns about public cloud, but their engineering teams want to be modern. They wanna have modern tools to appear to their engineering team so they can keep their engineers satisfied. MongoDB can be really effective, you know, in that regard as well. I don't think there's quite this sort of you know, universe that's divided into these two things. You know, over time, we're sort of obviously seeing more public cloud adoption, you know, clearly throughout.
Maybe the last thing I'd say is because we run the business on our channel basis, maybe it's helpful to think about, you know, the self-serve channel is basically all Atlas. The mid-market is, you know, the vast majority, you know, is Atlas. Ultimately, the MongoDB product mix will be determined by enterprises and how quickly do, you know, large, you know, Fortune 500, Global 2000 folks adopt public cloud.
Great. Another point really to kind of accentuate the difference in consumption models. Optimization is something that's come up from folks. Like, are you guys facing headwinds from customers trying to optimize their usage of MongoDB?
It's not a phenomenon that really affects us. The best way to think about it is that we are very back to the beginning of our conversation, we're very well aligned with our customers. They built the app, they invested their precious developer resources to create this thing, how much the app grows and how much that app interacts with the database, and therefore how much that grows as the app grows, is really fundamentally what drives how much they spend with us. They wanna see the app successful. When the app is successful, they aren't surprised that as a result, they have to pay us more. You know, just like all of us with everything in our lives, given two prices for the same thing, I prefer to pay less.
Ultimately, paying us more is a sign that what they invested in the first place was successful, we're happy to have that alignment with them.
Yeah. I think about the key factor being, even though, you know, people think of consumption as the common trend, and therefore, you know, there being such a thing as a consumption business, I tend to think of consumption more as a revenue recognition model, and the business model is really about what is the value relative to what you're charging. For us, we've got this very tight linkage between, you know, what we're charging for is based on the end user activity of the application, to which to Serge's point, they've spent money to go build. They want that to be successful. We have this very, you know, tight linkage that doesn't really lend itself to some of the dynamics that seem to be affecting other folks.
Another question on, I guess if we shift from Atlas to EA, can you help us think about, like, I think EA has demonstrated outperformance almost every quarter versus what people were expecting. What's driving that outperformance this year? Is there any common trend as far as why we're seeing that strength?
You're right. EA has been the source of upside in every quarter so far this year, and Q3 was no exception. Whereas Atlas, obviously, the trends have been mixed, and we talked a little bit about that. When we think about EA's strength, at the end of the day, it's a lot of the same drivers that we talked about when it comes to the whole business, and Michael sort of ran through this. First of all, it's a large market, and we have low share even in existing customers. We believe we're the best technology, and we are, you know, have strong go-to-market execution to go identify new workloads in our EA customers to continue growing.
You know, so far, at least, despite the macro environment getting more challenging, where you would think it would hurt EA more, right? Because there you have to sign a contract, pay up front more often than not. We've really just been, fortunate because of the size of the market and our ability to execute to not see a dramatic or any really macro impact on the EA side so far.
Great.
I would just call out, for those who missed it. That was a friendly modeling tip that, next year we'll have tough compares for EA-
Yeah.
Throughout all the quarters.
All right. I know I still have a set of questions here. I'm gonna go through maybe one or two more, and then turn it over to the audience if you guys have questions as well. On the, on the profitability, if I rewind, I guess it was two quarters ago, I know management sounded a tone that you guys were definitively trying to invest because you find your win rates go up when you have a seat at the table, which makes sense, right? Fast-forward to 3Q, one quarter ago, there was a meaningful lift in the operating margins, and some serious demonstration of leverage. Can you help us think about what drove that Q3 upside? I think there was revenue outperformance. I think OpEx even declined sequentially.
How should we be thinking about management's willingness to trade off growth versus profitability in the current environment?
Yeah. I'll run through a few things. First, specifically for Q3, to your point, we did have, you know, significant revenue outperformance, and that flowed through the bottom line that obviously demonstrates, you know, the operating leverage that exists. That hasn't always been the case in the sense that we've had revenue outperformance, but it hasn't always flowed through the bottom line. It's not just exclusively revenue outperformance. I think we're conscious of two, I won't quite say competing trends, but they're at least, you know, things that are in our thought process. One is we are trying to run the business for the long term. We've crossed over 1% market share, closing in on 2% market share, have a tremendous product, have unbelievably strong unit economics, all these other things.
It makes sense to keep investing in the business for the long term and for the benefit of long-term shareholders. That said, we're highly conscious of the current environment, and so I would describe it as, like, our investment philosophy, our investment framework hasn't really changed, but we've updated the inputs. It would be irresponsible not to reflect the inputs. What that means is effectively, there's a higher cost of capital. That means if you have a set of projects, even if they're all very high return projects, fewer of them clear the bar if you raise the bar, right? That's really been the dynamic and the thought process internally. Specifically to the sequential decline, it's probably worth calling out that Q2 is always our highest quarter in terms of marketing and sales spend. We have our big annual user conference.
We have, you know, some of our Excellence Clubs and other sort of rewards events in Q2. We were always gonna see a sequential decline Q3 relative to Q2. You'll note, though, that that sequential decline was not just in sales and marketing, but you also would've seen that in R&D. Part of that also, though, is that people from our R&D team do also travel to that, you know, global annual user conference. I do think it's worth saying, you know, there is incremental scrutiny on expenses, you know, both of sort of discretionary and measure T&E and things like that, but also just of on the returns, right?
You know, and looking at and saying, you know, if the cost of capital's gone up, our return threshold needs to be higher, different things. You know, not everything clears the bar. Not the things that used to clear the bar don't clear the bar anymore. That's been a very active conversation and process internally. The last thing that I'll say, which is maybe helpful in terms of adding a little bit of context or color, is we're always trying new things, right? I mean, part of the way that we've driven the success and the progress that we've had on the go-to-market side, is by tweaking that go-to-market. It's not stagnant. It's not the same playbook. It's not the same motion that we've had, that we've just been sort of cranking out at ever-increasing scale.
On balance, those experiments, those initiatives, those pilots have had a very positive effect, but not every single initiative, you know, is successful. Another way that the current environment plays out on that is if you had an initiative, and, you know, you're a couple quarters into the data and the data isn't playing out in the way that you're expecting, you're not kinda clearing the bar, so to speak, I think in a lower cost of capital environment, you'd say, "Our intuition tells us this should work. Let's give it another couple quarters," right? Whereas in the current environment, at a higher cost of capital, you sit here and say, "You know what? Our intuition told us this should work. We now have some data. The data shows it doesn't work. Maybe we need to stop doing this thing," right?
I think that's a little bit about how we're thinking about things. I think at a more macro level, if you sort of take a step back, we, you know, continue to run the business for the long term. We do have this very large market that we're going after. We have exceptionally strong demonstrated product market fit. We're delivering high rates of return. The cost of capital's certainly gone up, fewer things clear that bar, but we'll keep taking that long-term view. I think in our life as a public company, we've got something like over 35 percentage points of, you know, margin improvement. This last year was another 100 basis points, you know, of that. We obviously haven't given fiscal 2024 guidance, but we've been pleased with that progress, you know, so far.
If I think about this year with that expansion in operating margins to call it 100 basis points of improvement this year, right? I think at the start of this year, management had guided to an incremental $45 million-$55 million in post-COVID normalization expenses for like...
Correct.
Let's say MongoDB World, right? Are we still charting the course for that $45 million-$55 million? Is that still expected this year?
Yep. For fiscal 2023.
Yes.
We're roughly on track with that.
Okay.
That forecast turned out to be accurate.
Okay. Okay. Five minutes left. I still have questions. Wanna open it up. Does anyone have any questions? Yep.
I had a question about the competitive landscape. You talk a lot about your competition against the incumbent, but curious whether you're seeing any meaningful head-to-head competition from other document database companies like Couchbase or DocumentDB? Kind of as a second point, when you look at the overall TAM of NoSQL databases generally, how do you think of the growth of applications that leverage document databases versus other types of NoSQL databases like key-value, like Cassandra and Apache Cassandra?
Yeah. A few thoughts. One, I don't think we've seen any fundamental changes in the competitive landscape over the last couple of years. Our win rates are exceptionally high against all flavors. Our big challenge is because the market's so large and our footprint coverage is so thin, just not being in conversations. Whether it's versus relational, non-relational, MongoDB imitators, whatever it is, we have exceptionally high win rates really across the board. I think to the second point of the question, I sort of alluded to this a little bit earlier at the beginning.
I don't really think from a competitive standpoint or from sort of a product standpoint, it's super helpful to think about the universe in terms of relational versus non-relational, relational versus NoSQL, at least as it relates to MongoDB, just because we can handle the whole universe of situations. The beauty of the document model is the document model really is a superset. You can do key value, you can do graph, you can do, you know, whatever you need to do within that, and that's part of the reason why time series, you can do whatever you wanna do. That's why we've been so successful, is because of the general purpose nature of what we do. We don't.
You know, yes, you can find very niche, specialized, use cases that would benefit from a highly specialized, you know, database. But on balance, for the vast majority of workloads, you know, we've got the breadth and variety to cover sort of all those situations. I was reminded earlier this morning at one of the investor meetings, you know, when I first joined the company 7.5 years ago, there was a whole slew of players, you know, Couchbase, DataStax, MarkLogic, all these other people, and we were all roughly the same size. We were anywhere between kinda $20 million-$40 million.
We've obviously broken out and kinda separated ourselves from the pack, and it's because everyone saw the big market opportunity, but we had a better technology that delivered against this multipurpose, you know, positioning that drove the developer affinity that we have, right? That sort of developer mindshare, that developer fondness that we have, and then we married all that with good execution, and so as a result, we're sort of meaningfully bigger and kinda growing faster than all those other players.
Additional questions? I thought I saw one over here.
Yes. Just from your customer's perspective, what is the cost savings of moving their workload over to you guys over, you know, short-term, long-term?
Yeah. The cost savings tends to be, you know, valuable and significant. Obviously, in today's market environment is particularly top of mind, but cost savings doesn't tend to be the primary reason why people pick MongoDB. They tend to pick it so that you can innovate more quickly or, you know, drive scale, and innovation at scale. That tends to be sort of a secondary or tertiary consideration. That said, there is significant TCO. The beauty is back to the developer fondness is, we see such increases in developer productivity, as well as just general efficiency in terms of you know, running and operating in a MongoDB that, you know, most of the savings comes from other sources, so we don't even need to be deflationary at the license level.
Obviously, we've got the opportunity to be, but that doesn't tend to need to be an area that we need to go to because there's so many other sources of cost savings. That said, you know, I think if your sole goal were cost savings, there are cheaper alternatives. again, it goes back to the first point, which is we tend to be brought in when you've got a really big problem, you're running into scaling or other challenges with Oracle or with your other existing legacy player. you need that scalability, the nimbleness, the agility, and the ability to innovate more quickly. That tends to be the primary driver 'cause there'll be cheaper solutions if you're, if you're solely cost-focused.
Great. With that, we'll have to leave it there. Please help me in thanking the management team.
Thanks for having us.
Thanks a lot.