MongoDB delivered a banner quarterly report in early December, beating expectations on all fronts. The highlight was their continued revenue growth acceleration over the past four quarters. As investors will recall, MongoDB was impacted by a COVID-driven slowdown in IT spend that pushed revenue growth into the high 30% range in 2020. In calendar year 2021, though, MongoDB has reversed that trend and logged increasing growth rates each quarter. Yet, the stock is down almost 30% from its peak in November, with much of that occurring in 2022. This aligns with the same sell-off we have seen for all high multiple software stocks.
In my last update on MongoDB, I discussed MongoDB’s exciting new product positioning. At their annual user conference in July, the leadership team highlighted their product rebranding as the first “Application Data Platform”. Their vision is to address all data storage workloads that developers typically need to build a modern, scalable software application. This scope goes far beyond a document-oriented database, to span caches, search indices, mobile app interfaces and even basic analytics for data visualizations. The premise is that developers prefer to focus on building features, versus worrying about data storage infrastructure. Additionally, engineering teams can reduce cognitive overhead with fewer database solutions to learn. MongoDB’s goal is to increase developer productivity by eliminating the “tax on innovation”.
The combination of strong execution and product expansion is driving a favorable set-up for MongoDB stock as we transition into 2022. Compared to other high growth peers, MDB’s valuation appears to be reasonable. Given the momentum in large customer expansion, the uptake of Atlas, use case consolidation and the tailwinds of digital transformation, I think their revenue growth rate of 50% is sustainable in 2022. With a $850M revenue target for the current fiscal year, MongoDB has plenty of headroom to expand into the nearly $100B TAM for database spend. Accordingly, I have re-entered MDB in my personal portfolio and currently have a 8% allocation. As MongoDB keeps posting solid results, I will likely increase this further.
Quarterly Results
MongoDB announced their Q3 FY2022 (period from August – October 2021) earnings on December 6th. The results were impressive on many levels. The highlight was continued annual revenue growth acceleration, increasing almost 700 basis points quarter over quarter and over 1100 since Q1. MongoDB’s cloud offering, Atlas, is driving much of this growth and now makes up the majority of MongoDB’s overall revenue. Profitability metrics are improving as well, delivering a significant beat on Non-GAAP EPS.
The market loved the results – pushing the stock price up by 16.4% the next day. This did follow a drop of nearly 27% from its all time high price on November 16th of $590. MDB recently closed at $420, meaning it is about 29% below that prior ATH price and up about 17% since the beginning of 2021. At a 34 P/S ratio, MDB’s valuation is inline with peers, for a 50% compounder approaching profitability. The stock hasn’t gotten too far ahead of itself, allowing for more growth this year if the sales momentum continues.
Top-line Growth
For Q3, MongoDB delivered 50.5% annual revenue growth, which was up 14.2% sequentially from Q2. Q2’s annual growth rate was 43.7%, underscoring the acceleration kicking in for Q3. The size of the beat was also significant, as analysts had modeled just 36.1% growth for Q3. MongoDB beat their own guidance by over 10%.
Atlas revenue increased 84% y/y, accelerating slightly from 83% in Q2. It now makes up 58% of revenue. A year ago Atlas contributed 47% of revenue and was 56% in Q2. The fact that Atlas is still growing above 80% y/y and contributes more than 50% of total revenue at this point is important. Other software peers with a rapidly growing cloud offering have a much smaller contribution from cloud. For MongoDB, the growth of Atlas now has the largest influence on total revenue growth. With annual growth over 80%, it could continue to pull up overall revenue growth.
Looking forward to Q4, this high growth should continue. Management projects revenue of $239M – $242M, which would represent 40.6% annual growth at the midpoint and 6.0% sequentially. If we apply the same $24M beat from Q3 to Q4 estimates, it implies annual growth of nearly 55% and 16.6% sequentially. As we get into the second half of 2022, the comparisons will become more difficult, but these are not stretched. MongoDB isn’t susceptible to the large pull forward of spend that some Covid beneficiary SaaS peers experienced during 2020.
The outperformance in Q3 translated into another boost to the full year estimate. MongoDB raised their full year revenue outlook from $805M – $811M (up 40.3% annually) to $846.3M – $849.3M (up 47.2% at the midpoint). Midpoint to midpoint, this represented a raise of about $40M or almost 7% of annual growth. With a similar beat to the Q4 estimate, revenue growth will approach 51% for the year. The initial estimate for full year revenue growth issued in the Q4 FY2021 report projected 31.1% annual revenue growth for FY2022 (Feb 2021 to Jan 2022). This represents a huge improvement. It is also something to keep in mind when we receive the preliminary FY2023 estimate in March 2022.
On the earnings call, management also highlighted the significant sequential increase in deferred revenue. This was driven by a number of large Atlas customers renewing their contracts early, to capitalize on favorable terms. As Atlas revenue is recognized on consumption, these renewals didn’t translate into revenue in Q3. However, these contracts are billed annually in advance, which impacts deferred revenue. Short term deferred revenue jumped $49M sequentially. This should deliver higher actual revenue as those Atlas customers consume their contracts in future quarters.
The increase in deferred revenue generated a lot of discussion on the earnings call, with the implication being that this early contract renewal is more tied to the increased reliance on Atlas by these larger customers. They are renewing early to realize better terms for their higher usage. Atlas customers benefit from volume discounts at higher usage levels. So, if a customer is pushing the top-end of their current contract, it makes sense to renew with a higher usage threshold at a lower cost. While not a direct indicator of future revenue, it is a bullish signal for the strategic nature of MongoDB with these large customers and the expansion of use cases for MongoDB’s data platform. While the CFO cautioned analysts from assuming this surge in deferred revenue would repeat going forward, management also didn’t provide any reasons why the increased demand wouldn’t continue.
Looking to this calendar year, I think 50% annual revenue growth is repeatable. Customer additions are pacing in the high 30% range and net expansion is consistently reported above 120%. The net expansion rate is likely far above 120%. While sequential growth of customer additions each quarter is diminishing as the numbers get larger, MongoDB has been consistently adding 2,000 or more customers each quarter. With only 1,201 of 31,000 total customers (about 4%) spending more than $100k ARR at this point, there is plenty of room for expansion.
If MongoDB beats their Q4 estimate by the same margin as Q3, then FY2022 (Jan 2022 year end) will be about $870M. If MongoDB delivers another 50% growth in FY2023 (2022 calendar year), that implies full year revenue of $1.305B.
MongoDB’s market cap is about $28.0B with a trailing P/S ratio of about 34. Applying my target for FY2023 would generate a forward P/S ratio of 21. Putting aside the current wholesale reset in valuation multiples for high growth stocks, that ratio would be low for a company growing at 50% with improving profitability. Investors can play with the model, but maintaining the current valuation multiple through this year would deliver stock growth of 58% over the next 12 months.
I have discussed the impact of TAM expansion in a prior post. The example company was Cloudflare in this case, but the general thesis applies. MongoDB’s recent product rebranding significantly expanded the use cases in their addressable market. While they still reference the same $72B database market size, the addition of multiple transactional workloads significantly increases the serviceable component of that TAM. Previously, MongoDB was relegated to a subset of transactional database use cases, primarily revolving around document-oriented data sets.
With the launch of their Application Data Platform, MongoDB has positioned the product to address several more data storage models, including relational, search, time series, graph and even analytics use cases. These have been extended to not just web applications, but also support the nuanced state management for mobile devices. MongoDB’s argument is that an engineering team could replace several point solutions with the Application Data Platform.
We believe a key driver of our success has been the early, but growing, trend of customers choosing MongoDB as an enterprise standard for their future application development. Our success across industries and a wide variety of use cases puts us in a great position to build even deeper relationships with our customers over time.
Q3 FY2022 EArnings RElease, December 6, 2021
This posture may be reflected in the early contract renewals of the several large Atlas customers mentioned above. If these customers are adding new workloads to MongoDB, then they would want a new contract with more favorable usage rates at higher volumes. That would imply that their net expansion rates will tick up as revenue is recognized from this higher usage. Combined with continued addition of new customers, this higher NER will provide further support for elevated revenue growth over the next year.
Even the hyperscalers support this view of elevated revenue growth. As investors are aware, the hyperscalers maintained their high growth at immense scale in their recent quarterly reports. Azure grew 48% y/y (in constant currency) in their prior quarter at a $35B-$40B run rate. For the most recent quarter, they reported 46% growth. AWS grew 40% y/y at a $71B run rate. Not to be outdone, GCP logged 45% y/y growth, albeit at a smaller $22B run rate. Given that MongoDB’s annual revenue will be below $1B this calendar year, the durability of hyperscaler growth provides evidence that MongoDB could sustain a high rate of growth for a while.
Profitability Measures
Besides revenue growth, MongoDB is making improvements on the profitability side. Lack of operating leverage as they grew had been an investor complaint a few years ago. While MongoDB’s revenue growth was well above 50%, operating margin and FCF margin were stuck in the same negative range on every quarterly report. This situation has changed recently, following software peers like Datadog, Snowflake, and even Cloudflare, with incrementally improving margins on each reporting cycle. Granted, some of this is the benefit of Covid-19 travel restrictions, but much has been attributed to outsized revenue growth.
For Q3, MongoDB reported Non-GAAP gross profit of $163.9 million, representing a 72% non-GAAP gross margin. This compares to a 72% Non-GAAP gross margin in the year ago period and was steady from the prior quarter. As the revenue mix from MongoDB’s cloud offerings (Atlas) increases, maintaining a consistent gross margin year/year implies that the company is generating cost efficiencies as they shift more revenue to the cloud. Typically, the gross margin for a cloud-based software offering is lower than a pure licensing sale.
Operating loss was $3.5M on a Non-GAAP basis, versus $16.0M a year ago. This translates into a -1.5% operating margin in Q3, versus -10.6% a year ago. That represents over 900 basis points of improvement in one year. Given that Covid-19 restrictions were in place in late 2020, this improvement wouldn’t be explained by reduced T&E costs. As part of the Q2 earnings report, leadership had projected an operating loss of -$25M to -$23M. At the midpoint, the actual Non-GAAP operating loss of -$3.5M represents a beat of $20.5M.
Cash flow reflected a similar improvement. Net cash used in operations for Q3 was -$5.8M, versus -$8.1M a year ago. Factoring in capital expenditures and lease repayments, free cash flow was -$9.2M versus -$14.9M a year ago. This translates into FCF margin of -4.1% for Q3, versus -9.9% a year ago. This represents almost 600 basis points of improvement. This also puts MongoDB above the Rule of 40 threshold, measured by operating margin and FCF margin, which hasn’t been the case for a while.
Comparing to peer software infrastructure companies, MongoDB’s operating leverage improvement year/year compares favorably. While Cloudflare was celebrated for delivering their first quarter of positive operating margin, their year/year improvement was 530 basis points. While solidly positive, Datadog’s improvement to operating margin from Q3 2021 to the prior year was 740 basis points, again lower than MongoDB’s jump.
These improvements carried to the bottom line. Net loss was -$7.2M on a Non-GAAP basis, versus -$18.2M a year ago. On a per share basis, EPS was ($0.11) versus ($0.31) in Q3 FY2021. This Q3’s EPS beat the analyst estimate for ($0.38) by a significant $0.27. This was the largest EPS beat in at least the last four quarters.
Looking forward, MongoDB leadership expects a Q4 operating loss of -$13.0M to -$11.0M. Given that they beat their prior estimate for Q3 by over $20M, the implication is that MongoDB will flip to a positive operating margin next quarter on a Non-GAAP basis. I think this will be met with very favorable market sentiment, just as we have seen with other SaaS companies that make this symbolic transition.
The magnitude of the improvement in expected operating loss is reflected in the full year results as well. In the Q2 report, management projected a full year operating loss in the range of -$67M to -$62M. In the Q3 earnings report, they reduced this expected loss to -$36.4M to -$36.4M. At the beginning of the fiscal year, this estimate was for -$84.0M to -$74.0M. Considering that the final read for full year operating loss may land in the -$20M range, this is the type of improvement in operating leverage that we like to see.
This improvement in operating leverage was also reflected in the allocation of revenue to each of the three operating functions. We see the percent of revenue spent on R&D, S&M and G&A decreasing year/year on a Non-GAAP basis. I like to see the leverage in S&M. For the R&D allocation, I like to see that stabilize in the low 20% range, as I think continued investment in R&D is critical to maintaining a robust product development pipeline.
- R&D = 21.7% of revenue (versus 24.9% in Q3 FY2021)
- S&M = 41.8% of revenue (versus 45.0% in Q3 FY2021)
- G&A = 10.3% of revenue (versus 12.8% in Q3 FY2021)
While these relative percentage allocations are continuing to decrease over time, MongoDB is able to increase their spend in the critical areas to drive revenue growth. Specifically, on a GAAP basis (which includes SBC), MongoDB increased spend on S&M by 45% year/year and R&D by 51%. These are roughly inline with the increase in revenue. I like to see continued investment in these two areas at a rate near overall revenue growth as a company approaches break-even operating margin. This helps ensure that a high rate of revenue growth is sustainable going forward.
MongoDB is hiring rapidly. According to their latest 10-Q, they had 3,223 employees as of October 31, 2021. This is up 38.1% from a year ago and 9.8% sequentially. They added 289 employees in Q3, versus 889 for the prior 12 months. They appear to be accelerating their hiring. I like to see high growth software companies adding headcount at a high rate, but less than revenue growth.
Customer Activity
At a high level, MongoDB’s customer activity signals continued growth. They have consistently added 2,000 or more new customers for the past four quarters. At the end of Q3, MongoDB reported 31,000 total customers, which was up 37.2% from 22,600 a year prior. The majority of these additions were in the Atlas product, signaling the continued shift to MongoDB’s cloud offerings.
Customers that aren’t Atlas subscribers license the Enterprise Advanced product. The distinction is that these customers are self-hosted. While MongoDB is gradually migrating the majority of its customer base to the cloud solution, the licensed product is still an important component of their revenue. Some companies, like those in sensitive or government sectors, may remain in a self-hosted posture for the duration. In Q3, growth in the Enterprise Advanced segment also beat expectations, which helped with the overall revenue beat.
MongoDB leadership also tracks and reports the number of Direct Sales customers. The distinction here is that these customers are assigned a sales rep who interacts with the customer directly. These tend to represent larger customers were MongoDB perceives a real opportunity to expand the customer’s spend through additional application workloads and use cases. Customers that aren’t categorized as Direct Sales are self-service. They are fully enabled to utilize the MongoDB product and pay for consumption, without needing to interact with a sales rep. As you would expect, these are primarily utilizing the Atlas cloud offering. As a customer’s spend grows, they are commonly switched to a Direct Sales relationship.
Like other software infrastructure peers, MongoDB reports the number of large customers. The threshold for being considered a large customer is spend of $100k or more in ARR. The calculation varies for the Atlas product versus Enterprise Advanced, but the data provides a useful indicator of growth in large customers. At the end of Q3, MongoDB reported 1,201 large customers, which was up 33.7% annually. They have transitioned about 75 customers to this spend category each quarter for the past four quarters as well.
This growth in large customer spend has been the main contributor to MongoDB’s revenue acceleration. To measure growth of existing customer spend, they report a net expansion rate on an ARR basis. They only reveal that it is above 120%, which as been the case for many quarters. For Q3, it was clear this rate was far above 120%.
The big opportunity for MongoDB is to continue to drive a high rate of expansion with existing customers. The ratio of large customers to total customers is only about 4%, indicating that there is plenty of opportunity to move more customers into the larger spend threshold. Another factor that underscores the expansion opportunity is the penetration of MongoDB into the total application workloads for Global 2000 customers. MongoDB leadership mentioned on the earnings call and subsequent analyst meetings that MongoDB is generally only powering a few percentage of total application workload capacity at their major customers.
The rest of that penetration would be occupied by other database providers. With MongoDB’s new product capabilities and positioning as a complete application data platform, it is reasonable to assume that they can be considered for a larger percentage of workloads. This wasn’t the case even a year ago. MongoDB was relegated to application workloads that utilized a document model (generalized as NoSQL). However, with their 5.0 release in July 2021, the MongoDB product team rounded out the use cases that MongoDB could address. This now spans not just document-oriented data stores, but also includes relational, time series, search, graph, key-value and mobile application workloads.
This pivot is important to note and was strongly reinforced at MongoDB’s Live conference last summer. Since then, it has been carried forward in promotional positioning. The implication is that MongoDB can be the database solution for all types of applications within the enterprise, not just the smaller percent that are suitable for a document model. If MongoDB can pull off this product extension, then they transition from capturing a few percent of workloads in a large customer to the majority of workloads over time. That could be a 10x increase in spend with existing large customers over the next several years – an opportunity that didn’t exist before 2021. This will likely be the growth driver going forward, beyond simply adding new customers.
However, all isn’t rosy with customer metrics. As you can see, the sequential rate of total customer and Atlas customer additions has been slowing down over the past four quarters. The sequential rate peaked at about 12% a year ago and has dropped to 7% in Q3. This type of deceleration can be a warning flag for a software company and is certainly something to watch. At the same time, this does appear to be a case of large numbers. As mentioned, the absolute count of customer additions over the past year has been consistent, at about 2,000 a quarter. As the denominator gets larger, the effect has been a reduction in the growth percentage.
With 31,000 total customers, I think this rate deceleration is okay for now. As mentioned previously, the metric to watch will be the growth of large customers (those spending over $100k annually). Given that large customers only make up 4% of total customers, there is plenty of expansion opportunity for MongoDB to drive more spend from existing large customers to counteract any slowdown in total customer additions. Arguably, a rate of new customer additions over 30% a year is still strong.
We can see that the sequential growth trend for large customer growth actually plateaued in the last two quarters and the rate ticked up slightly from Q2 to Q3. If this stabilizes and even starts to accelerate further, it would be a bullish signal. This would indicate that MongoDB is successfully expanding usage within large enterprises to a broader set of workloads, justifying more spend, as engineering teams consolidate their database footprint onto fewer providers. This would signal realization of the product vision for the Application Data Platform introduced last year.
We can get some insight into customer growth trends by comparing to software infrastructure peers. Datadog provides a useful example. Both companies enjoy usage driven by application workloads, are expanding reach into adjacent categories and have similar customer profiles. Looking at Datadog’s customer data from the prior four quarters, we see a similar deceleration in the sequential growth of total customers. Like MongoDB, Datadog has been adding roughly the same number of absolute customers each quarter for the past year, at around 1,100. And the effect on sequential growth has been the same, with a slow deceleration over the last four quarters to nearly 7% in Q3 (same as MongoDB).
Like MongoDB, Datadog segments out large customers, which they also define as those spending more than $100k a year. Datadog’s growth rates for large customers are higher than those for MongoDB. While decelerating sequentially, the absolute number has been increasing, particularly when taking into account Datadog’s one time Covid reset in Q2-Q3 2020. Datadog has been adding more than twice as many large customers a quarter as MongoDB has been over the last year.
This creates a higher ratio of large customers to total customers for Datadog, which was over 10% versus about 4% for MongoDB. If we look at Datadog’s first quarter reporting these customer metrics in Q1 2019, the ratio was about 6%, closer to MongoDB’s ratio. Over the last three years, Datadog has been accelerating the number of monetized product offerings available for customers. This has translated into strong growth metrics for product subscriptions by customer, with over 30% of Datadog customers paying for 4 or more products in Q3 2021.
With the launch of the Application Data Platform, I think that a similar opportunity exists for MongoDB. While MongoDB customers only pay for overall usage, the implication is that use of MongoDB can be applied to many more application database workloads. The graphic below was presented at the annual MongoDB user conference in July 2021. It represents all the different types of database solutions that a typical enterprise might utilize for application workloads. Prior to the Application Data Platform, MongoDB was relegated to a single use case for document storage (a subset of NoSQL). Going forward, MongoDB could be applied to all workloads depicted, in theory replacing all of the vendors represented.
This provides insight into the opportunity for MongoDB going forward, which is similar to Datadog’s rapid expansion of observability use cases starting in 2018. Just counting the icons in the diagram above, MongoDB has expanded their product reach by maybe 10x. That is similar to Datadog’s expansion from 3 monetized products at the end of 2018 to 14 currently.
While MongoDB has to execute on this product vision, the opportunity is similar. If MongoDB can begin addressing more application data workloads within enterprise environments, they can significantly expand spend with large customers. This will manifest in acceleration of growth in large customer counts and the emergence of references to $1M customers. For the largest customers, this amount of spend for a core transactional database platform would be reasonable. As large customer spend continues to expand, it will provide a strong tailwind to revenue growth, even if growth of total customers plateaus going forward.
Product Development
In a prior post, I provided extensive background on changes in the data storage market and MongoDB’s product positioning. I will summarize a few of those points and then highlight the areas where I think MongoDB is building competitive advantage over other solutions. At a high level, I think MongoDB is entering a phase where they will benefit from the confluence of several tailwinds in industry trends, evolving developer preferences and scaling Internet architectures. In many ways, MongoDB has been preparing for this moment for several years. Their recent acceleration in growth may be reflective of this new demand environment.
Application Explosion
We can start with secular tailwinds, as we normally do with software company analysis. It should be no surprise that digital transformation is occurring. Specifically, this means that enterprises are moving more and more of their daily operations to digital channels. This isn’t just a “lift and shift” from self-hosted applications to the cloud. Rather, it involves the creation of whole new software channels to reach customers, process orders, provide support, coordinate with suppliers, automate operations and a myriad of other tasks.
Many of these applications are powered by off-the-shelf packaged software or SaaS solutions. However, enterprises are increasingly realizing that to differentiate themselves from competitors, they need to create custom solutions. These applications are typically those facing customers. This work is allocated to the internal development team. Those developers have a lot of influence over their tech stack.
Back in October 2019, IDC published their FutureScape report, which projected information technology trends for 2020 and beyond. As the headline, they predicted that over half of all global GDP would be processed through digital channels by 2023. This will represent a tipping point in digital interactions, whereby software applications become the primary mechanism for driving business globally.
Over the past five years, IDC has been documenting the rise of the digital economy and the digital transformation that organizations must undergo to compete and survive in this burgeoning economy. As the current decade comes to an end, the digital economy is approaching a critical tipping point. By 2023, IDC predicts that the global economy will finally reach “digital supremacy” with more than half of all GDP worldwide driven by products and services from digitally transformed enterprises.
By 2023, over 500 million digital apps and services will be developed and deployed using cloud-native approaches – the same number of apps developed in the last 40 years. Most of these will be targeted at industry-specific digital transformation use cases. This explosion of new digital apps and services will define the new minimum competitive requirements in every industry.
IDC Futurescape REport, October 2019
This trend will force enterprises of all types to transform their operations to digital channels. They will do so at an accelerating rate, by investing in key technologies and new operating models to become “hyperspeed, hyperscaled, and hyperconnected organizations.” Included in this was a prediction that over 500M digital applications and services will be developed and deployed on the cloud by 2023, matching the same number built in the 40 years before late 2019.
As another change driver, customer expectations have increased over the same period. Applications are expected to be continuously available and responsive. A slow web site or mobile app is considered to be down. Consumers will just move on to a competitor’s offering. Similarly, as multiple businesses offer a similar service, the one with the most convenient channels for interaction will grow their share. Restaurants with online ordering win business over those that only take orders over the phone. Convenience and real-time status updates are now table stakes across many industries – not just food ordering, but all types of consumer goods, travel, health care, housing, finances, and on.
Additionally, whole new commercial segments are being created that only exist in a digital context. One of MongoDB’s largest customers is Coinbase, which didn’t even exist 10 years ago. A number of previous customer highlights have involved online gaming companies. New sharing economy applications (Airbnb, Uber, Lyft, Task Rabbit, etc.) can be added to the list of digital only companies. The emergence of these brand new online businesses drive software growth separate from the digital transformation of legacy enterprises.
Finally, the experiences referenced above are all driven by human-to-human interactions. As smart, network-connected devices proliferate (IoT), even more data will be created that needs to be collected, processed, shipped and ultimately stored. Machine-to-machine communications will significantly eclipse the amount of data created by humans over the next decade. In their April 2021 Investor Presentation, Applied Materials (a semiconductor equipment manufacturer) projected the growth in data generation going forward. You can see that they too believe use cases like industrial IoT, home automation and eventually autonomous vehicles will generate the lion’s share of new data in 5 years. This growth is separate from global Internet adoption or digital transformation.
Durability of growth and the size of the market is reinforced by the performance of the hyperscalers. As I mentioned above, AWS, Azure and GCP are growing at 40%+ annually with run rates at 25-80x MongoDB’s projected revenue for this year. Microsoft even reported 100% year/year growth in the utilization of their database product Cosmos DB. These all provide evidence that MongoDB should be able to sustain their growth rates with just the use cases they have traditionally addressed. As I will discuss, they have an opportunity to expand their reach into a whole new set of workloads.
Data Storage Architecture
Over the last 25 years, the database storage architecture for large-scale software applications has gone through a significant shift. Before the emergence of the Internet, software applications that required massive scale (millions of concurrent users) didn’t exist. The largest applications served single corporations. Or, if they were connected to users over private networks with a well understood usage pattern and regular scaling. A stock exchange or airline reservation system are good examples of large, but fixed, applications. Data for these applications was stored in a single, relational database. Vendors like Oracle and IBM dominated by providing vertically scalable databases that could handle all the data requirements of the application.
As the Internet gained traction, these single large databases eventually reached the extent of their scalability. To increase capacity and throughput, new database solutions emerged that could scale horizontally, using techniques like clustering and replication chains. Even though the database was sub-divided, the relational model was preserved. This was primarily a historical artifact, mainly driven by what was familiar.
Additionally, all code for a web application was kept in a single “monolithic” application. Code changes had to be coordinated across all developers and deployed at once. As engineering teams grew, this coordination became a real hindrance to development agility. Release cycles had to be extended to work through all the dependencies. Additional testing preceded every release to ensure that all the code changes worked together effectively.
To solve for this coordination problem, micro-services emerged. These represented stand-alone applications purpose-built for one part of a digital experience. Micro-service code was isolated from that of other micro-services. It ran in a dedicated environment, allowing for its own test and release cycle. Small teams of engineers could be assigned to maintain each micro-service. Examples within an e-commerce application might be the product catalog, search, a shopping cart, payments and user profile.
Because each micro-service had an isolated code base and runtime environment, it could also have a separate database. Initially, these databases were relational. Because each micro-service performed a different function, new types of databases emerged that catered to the type of data being stored by that micro-service. A shopping cart might use a key-value store. A search service might use a reverse index or a graph database. A user profile would be suitable for a document-oriented database. Soon, there were many new types of databases that fell outside the standard relational model. The industry bucketed all of these under the label “NoSQL”.
This evolution was fantastic for developers. They could select a data store that best reflected the data model and workload their micro-service needed. This reduced the overhead of translating everything into a relational model. Mobile apps often source their data through APIs. APIs marshal the request/response in a JSON format. JSON data is easy to drop into a document-oriented database, versus mapping to a relational model.
As developer resources increasingly became the constraint for application development, things that reduced developer overhead and time became very valuable. As the squeaky wheel, the developer’s voice became very loud. Their insistence on using a NoSQL variant to save time quickly beat out the objections of old school relational DBAs who insisted on a single data model. As cloud-hosted, serverless database solutions emerged, the DBAs disappeared from the organization anyway.
So, the end state became one of hundreds of micro-services, each with their own bespoke data storage solution. The developers were highly productive and didn’t trample on each other’s code. Everyone was happy. However, new problems emerged that began to create new impedance for the engineering organization. First, developers had to start learning about a lot of different database solutions, as each was provided by a different vendor. They might have to learn Redis for their key-value store, Elastic for search, InfluxDB for time series, Neo4j for a graph database and Firebase for their mobile apps. Additionally, the DevOps organization had to understand how to run all those data storage systems, or at least troubleshoot serverless deployments when issues arose.
It has become clear that the industry swung too far in the direction of having a separate data storage tool for every workload. There are too many vendors, each with their own interface language, pricing models, software instances and cloud services. Additionally, each vendor’s data is silo’ed from the others, requiring extensive ETL jobs for any kind of data sharing or combining. Analytics workloads even had to separated from transactional for the same data type. The developer and DevOps experience has become increasingly fragmented.
As with cycles and pendulums, the industry is ready to swing the other way. Having a custom data model for each workload type definitely needs to remain – lest we slow down developer cycles as they map each micro-service into one data type (whether relational or other). However, there is an opportunity for database vendors to expand the number of workloads and data models that their solution can address. If one vendor could serve all types of workloads, whether key-value, search, relational, document, graph, etc., with one data storage backplane, it would represent the ideal case. Engineering teams could leverage a single interface language, runtime operations, deployment topology and pricing model.
A single database that can service all types of workloads has several advantages. Developer productivity increases because context switching is reduced. DevOps is easier as code integration and deployment pipelines only interact with one set of APIs. Security and privacy standards can be applied to one solution. The engineering leadership team can manage a single vendor bill and optimize cost against one pricing model.
These advantages were highlighted in an October 2021 article from Redmonk (a well regarded developer-focused industry analyst firm) called “A Return to the General Purpose Database”. It traverses the history of data architectures, from a single relational database to a myriad of purpose-built data storage solutions. They reinforce the challenges of interfacing with too many separate providers and speculate about the shift back to a single (or shorter list) of database vendors, which offer solutions that span multiple data models and application workloads.
Enterprises are pushing for these functional expansions out of a desire to not have to context switch between different data stores, because they want the ability to perform things like analytics on a given in place dataset without having to migrate it, because they want to consolidate the sheer volume of vendors they deal with, or some combination of all of the above.
Redmonk Article, October 2021
Additionally, a consolidated database vendor will have the bandwidth to traverse multiple public cloud providers, reducing the risk of hyperscaler lock-in and easing data sharing costs through multiple ETL jobs across the open Internet. Redundancy is much easier to maintain, as fail-overs and load balancing can be orchestrated across a single data backplane.
Assuming it continues, this shift back to a general purpose database allows one vendor to mop up many database workloads. The argument to a development team is compelling. In theory, they can migrate all their key-value, search, relational, document, graph, time series and mobile workloads to one database vendor’s platform. Whichever database provider can achieve that vision has the opportunity to significantly expand their market share.
MongoDB Competitive Advantages
Given this set up, we can now explore why I think MongoDB is well positioned to capitalize on these trends. Their approach offers a number of advantages and I will highlight those that I think are most important.
Application Data Platform
As I discussed above, developers now have a myriad of data storage options to back their applications. They can choose from multiple databases, purpose-built for each data access pattern and application workload, including relational, graph, object, geospatial, time series, key value and more. Similarly, developers have other solutions to service search queries, mobile app data synch and analytics. For all of these data stores, developers have to consider security standards, cloud hosting and data residency requirements.
With the proliferation of micro-services and application workload segmentation, I think that data storage solutions have swung too far towards specialization. I make this statement in the context of too many vendor platforms. I think the use of the right data model for the application completely makes sense. Developer cycles are precious and any efficiencies for their time spent should be pursued rigorously. At the same time, having to choose a different vendor, integration method and storage location for each data type creates unnecessary overhead. the ideal case is one “data platform” that could serve all application data models and workloads.
At their annual developer event in July of 2021, called MongoDB.live, MongoDB proposed just that. They essentially recast the MongoDB product suite as the Application Data Platform. This is made up of many components, most of which MongoDB has released over the last two years. They have been busy filling feature gaps and rounding out the core infrastructure. MongoDB leadership made an argument that the Application Data Platform provides all the tooling needed by developers to address the data requirements for building an end-to-end modern software application.
As part of the investor session at MongoDB.live, both the CPO and CTO discussed the data storage engines that a typical enterprise will support in order to deliver a modern software application. In order to deal with limitations of relational databases and address unique workloads, special purpose non-relational databases are set up, like document-oriented, graph, geospatial, object and key-value stores. These extend the breadth of use cases that can be addressed by the application, but also create compounding overhead in system administration and maintenance. As data stores are disconnected from the primary database, most of these solutions require their own ETL process to keep in synch.
Micro-services didn’t necessarily lessen this burden, and arguably contributed to it. This is because a service will typically run in its own environment, with a separate codebase and data store. Micro-services are useful because they allow large development teams to sub-divide organizationally around each micro-service. The independence of services enables the selection of special-purpose data storage solutions that cater to the query demands of each micro-service. Teams then incur the overhead of learning each data storage engine and managing the system maintenance of each.
If an application needs to support text-based search, development teams will often stand-up a search server that wraps Lucene (like Elastic). This too requires a process to update the search index from the primary database and involves separate architectural planning for master and slave nodes. If the organization offers mobile apps to their customers, they will have to contend with data synchronization from the origin database to all the local data stores on each mobile device. This is generally handled with separate mobile specific data infrastructure and push services. If the application includes data visualizations, they may stand up another database to serve a basic analytics workload. This might be separate from the data warehouse, as the application would query it directly.
In the diagram above, the MongoDB team modeled out a typical system architecture for a large scale, user-facing application. They represented all the types of data stores discussed and inserted a popular solution for each one. This provides a reasonable representation of what would be found at many large-scale digital enterprises. It also reflects the data footprint that the MongoDB solutions engineering team encountered at a Fortune 500 insurance company that is a customer.
The MongoDB leadership team contends that the Application Data Platform can replace all of this. MongoDB itself can be used for all the special-purpose workloads, including graph, time series, key-value, object/JSON and even handles relational constructs. It can address both text-based and faceted search through Atlas Search. For real-time analytics with workload isolation and native data visualization, developers can leverage Charts pulling from the core data store. They can run federated queries across the operational data stores and cloud object storage (like S3) using Atlas Data Lake. Data requirements for mobile apps (both iOS and Android) can be serviced through Realm and Sync.
On the infrastructure side, developers get the capabilities required to meet security, scalability and portability requirements. MongoDB supports multi-document transactions that are ACID compliant. It includes industry leading data privacy controls with client-side field level encryption. The data store can be scaled fluidly through live sharding, which can be kicked off behind the scenes without disrupting real-time data delivery. To further reduce maintenance, the runtime can be deployed in a serverless mode on MongoDB Atlas.
I think the strategy and market positioning of the Application Data Platform is forward-thinking and timely by the MongoDB team. Assuming they can pull it off, it would provide a fairly compelling value proposition for any large engineering team. Developers and DevSecOps teams would gain substantial productivity improvements by interacting with one data storage solution for all application related use cases. MongoDB provides a unified developer experience, a consistent operational and security model, automated data movement behind the scenes and reduced data duplication.
With this positioning, MongoDB is expanding the scope of their addressable market significantly. Previously, the argument for market share revolved around how much processing their document-oriented database could take from traditional relational databases. Now, the scope encompasses all front-facing application data stores.
Even at the granular level, MongoDB claims that the Document model is a superset of all other data models. Because a document model “thinks” in objects, it removes cognitive load for developers. These data objects can be simplified and morphed into other data types, whether key-value pairs, graph traversals, geo spatial relationships, etc. Search indices are made up of pre-calculated relationships between search terms and objects.
The other historical consideration is that improvements in compute, storage and horizontal scalability have mitigated any performance arguments. While a finely tuned relational datastore with indexes on frequently used columns will be highly responsive, other data models can be tuned and scaled to deliver sufficient performance and capacity. The compactness of relational models were necessary decades ago when storage space was costly. With nearly unlimited cloud storage, this is no longer a requirement. Large amounts of verbosity and duplication is fine.
During the Investor Session at MongoDB.live, MongoDB’s CTO, Mark Porter, talked about the MongoDB data platform and new features that have been launched. He went on to offer some controversial perspective of his own on the direction of the application data market. He said that “single model databases, like relational, are becoming niche”. In fact, he claims that new computer science graduates don’t want to work on relational databases, and that relational skills are becoming the new COBOL (an outdated programming language).
Single model databases, including relational, are becoming more and more niche in most of the customers I talk to personally. With general purpose, flexible databases, like MongoDB, becoming the de facto standard for modern enterprises.
MARK PORTER, CTO, MONGODB
While I would normally chalk this up to pumping his own company, Mark spent most of his career leading relational database development and usage at some of the most influential database providers and consumers in the space. He has been on both sides of the market, as a vendor and customer. If anyone understands the underpinnings of the relational model and the inherent advantages/disadvantages relative to others, it would be him. With that background, he could have taken any technology leadership job and chose MongoDB.
Mark’s perspective is that a true data platform going forward needs to offer multiple methods of accessing data, including relational, but also key-value, time series, object, graph and geospatial. The MongoDB Application Data Platform is the first solution, in his opinion, that can address all of the use cases needed by developers. It also models data in object format, which most closely aligns with how data is represented within applications. This removes the translation layer (ORM) that has been traditionally maintained between an application using OOP design principals and the relational database.
With an addressable market approaching $100B over the next few years, the opportunity for MongoDB is huge. With the Application Data Platform, MongoDB has expanded the share that they can conceivably capture, extending that from a single use case to most application data workloads. As new applications are being built by modern engineering organizations MongoDB is often being selected to power them. If the addressable market is growing by 10-20% a year, this creates at least $10B of new spend each year.
At the other end of the spectrum, enterprises are slowly upgrading their legacy applications. This is often a more extended cycle, perhaps lasting as long as 10 years. However, each of these legacy application re-architecture exercises generates new spend for MongoDB. These projects usually involve moving an application off of a legacy database like Oracle or IBM onto a newer architecture with micro-services and an updated data model. For these application rebuilds, MongoDB also generates new business, in addition to brand new applications built on the MongoDB platform. In this way, the company is benefiting from a large addressable market along two dimensions – new applications and architecture refreshes.
Ease of Use
Beyond expansion into multiple data model and application workloads, MongoDB is providing additional capabilities that make the cloud offering very appealing to a global Internet property with a large software infrastructure footprint. As an enterprise expands its reach across multiple countries and hosting spans several cloud providers, capabilities for data privacy controls, security, data portability and serverless become critical. These are the capabilities that the largest customers will expect. Large customer expansion represents a significant revenue growth driver for MongoDB going forward. These capabilities are also likely driving the much higher revenue growth for the Atlas product.
The first capability worth calling out is the multi-cloud data distribution available with MongoDB Atlas. This allows the same data store to be addressed from applications running on multiple cloud vendors, reaching 81 global regions across GCP, AWS and Azure. MongoDB is one of few database vendors that supports this capability. It allows an enterprise engineering team to make use of the best technology from each hyperscaler, like hosting the primary application on AWS, but running AI/ML analysis on GCP. MongoDB Atlas multi-cloud prevents lock-in on one hyperscaler and provides a consistent data access API across all hosting providers. Development teams don’t need to learn the interface for the proprietary data storage solutions on AWS, Azure and GCP separately.
Additionally, the data distribution administration configuration allows for granular control over the placement of data by user groups. Enterprise data architects can pin proximity of data to the country of origin. This helps manage data privacy and residency requirements, like GDPR, which prohibit shipping consumer data outside of a region. Additionally, locating data near an end user’s physical location will improve the application’s responsiveness.
Second, all of these capabilities are layered on top of industry leading security controls. Administrators can configure role-based access rules to control which users can read, write and delete data across MongoDB instances. All network traffic is encrypted using Transport Layer Security (TLS). When at rest, data storage volumes are automatically encrypted. MongoDB also supports field level encryption to add another layer of protection to sensitive consumer data. For compliance exercises, MongoDB provides detailed audits and activity trails.
Third, in July of last year, MongoDB introduced a serverless option for MongoDB Atlas. This allows developers to make use of MongoDB without needing to deal with projecting application demand and provisioning servers. Serverless instances are billed monthly, and metered based usage of reads, writes, and storage. With serverless, the latest MongoDB version is continuously updated without needing action by the user. This eliminates upgrade planning and patch installation, which can create overhead for the DevOps team. It also brings built in security, continuous uptime, backups and operational metrics without requiring configuration. Developers are free to focus on their application, rather than their databases. Lower-level infrastructure decisions are handled by underlying automation.
The serverless option is currently in a limited preview, with new capabilities, regions and capacity being added frequently. I think we can expect it to be fully available by the summer. Developers can still choose between a serverless instance or full clustered deployments. The clustered version provides more control over the configuration for workloads that benefit from finer tuning, extremely high scaling or custom security requirements. Having a serverless option expands the appeal of MongoDB to a broader set of developers.
Developer Familiarity
One of the strongest advantages that MongoDB has over other commercial database offerings is its popularity among developers. While there are purely open source offerings, like MySQL and PostgreSQL, with more adoption, MongoDB is the most broadly downloaded, taught and desired data storage solution for a paid, cloud-hosted offering. The open source, community version of MongoDB has been downloaded over 210M times.
Developers have increasing influence over technology selections within their engineering organization. This hasn’t always been the case. In the past, technology selection was delegated to architects who made tool choices, but didn’t necessarily have to work with them every day. A new CTO or VP Eng would often bring their favored stack into an organization, along with an army of vendors and consultants to support it.
Cloud based hosting has significantly lowered the barrier to provisioning new technologies. It is very easy for a developer to open a cloud account, provision a simple set up and produce a proof of concept. In the past, a simple test would require working with the Ops team to set up the new database infrastructure on the organization’s private data center. With cloud hosting, developers no longer need to navigate this bureaucracy. This accelerated evidence gathering for new technology selection, because for most problems, working code wins. Technology selection couldn’t be obfuscated behind vendor Powerpoint presentations and committees of architects.
Additionally, as enterprises scramble to increase their software release velocity, developer productivity has been pushed to the forefront. While this created more pressure on development teams, it also empowered them. Agile retrospectives encouraged developers to point out process or tooling changes that would make them more productive for the next sprint. Scrum masters and product leads would greenlight technology explorations as tech debt that might drive future developer productivity. As the squeaky wheel, developers could get a lot of grease. This focus applied to the software tooling and infrastructure used by the team, including database choices.
With that background, we can learn a lot about the potential for database market share simply by understanding developer preferences. The popular developer site Stack Overflow conducts an annual survey in which they ask 80,000 developers about their preferences across a number of technology types. Included is input on programming languages, frameworks, tools and platforms. Transactional data storage solutions are covered in the Databases category.
The most recent survey was conducted in May 2021, with the previous survey published February 2020. From the latest survey, we can glean a couple of useful insights. A comparison to the prior year is also helpful to a degree, but some of the measurement criteria and formatting changed slightly. The two main survey results I like to examine are the most popular databases and the most wanted database. These give some sense for the broad marketshare for MongoDB and future adoption.
The question posed is “Which database environments have you done extensive development work in over the past year, and which do you want to work in over the next year?” The first part of the question provides insight into proliferation of environments currently. The second gives an indication of future growth.
For the most used database solutions, we see MongoDB ranked fourth across all respondents. There is a professional developers filter. I like viewing all responses, because it captures the full view of a database solution with those using it professionally, combined with those presumably preparing for a career in software development. MongoDB ranks highest amongst database solutions with a commercial offering. Additionally, it is far above some alternatives like Redis, MariaDB, DynamoDB, Cassandra and Couchbase (BASE). Not surprisingly, Oracle is pretty far down the list.
The other part of the question captures which database technologies developers would like to work on over the next year. Stack Overflow calls this the “Wanted” category. I think this question provides a proxy for future market share growth. If developers would like to adopt a particular solution within their organization, there is a good chance it will get introduced. This would presumably translate into new customer relationships for the commercial database offerings.
In this category, MongoDB ranked a close second to PostgreSQL, which is an open source, largely non-commercial offering. Over the prior four years, MongoDB has been ranked the highest on this survey. It is far above competitive offerings with a commercial component.
MongoDB’s developer evangelism effort is behind much of this traction. Over time, they have been very successful inserting MongoDB into popular development frameworks. This is best evidenced by examining the alphabet soup of framework acronyms. For a long time, one of the most popular developer frameworks was LAMP, which stands for Linux, Apache, MySQL and PHP. For many years, this was the go-to stack for start-ups that wanted to quickly build a software product without the overhead of some of the heavier, enterprise frameworks (like Java and Microsoft .NET).
With the emergence of JavaScript support on the server-side (through Node.js), software stacks evolved to allow JavaScript to be run on both the client and server-side. This provided development teams with the efficiency of a single language. Given that JSON-modeled data structures are part of JavaScript programming, it was natural that a JSON-friendly, document-oriented database would be utilized as the data storage engine. MongoDB was a perfect fit, given its open source distribution and popularity.
New software stacks began to adopt MongoDB as the data store and named their acronym label with an “M” for MongoDB. The first was MEAN – MongoDB, Express, Angular and Node.js. Alternatives emerged for client-side development, creating other derivatives including MERN (React), MEEN (Ember) and MEVN (Vue). These frameworks were popularized amongst the developer community and further memorialized in many “how to” web development books. A search on Amazon for “MEAN stack web development” yields many results, several of which were recently published.
In addition to having MongoDB evangelized through framework acronyms and books, it has become a popular database taught as part of coding bootcamp curriculums. Coding bootcamps were started in 2011 with Code Academy. By 2017, there were 95 full-time coding bootcamps in the U.S., and more overseas. Bootcamp sessions typically last between 8 to 36 weeks, where the student attends classes each day all week, much like a job. The curriculum is restricted to just coding and producing project work. The idea behind a coding bootcamp is to provide the student with a condensed and accelerated learning program to prepare them for a professional career as a software engineer. This contrasts with a traditional computer science degree from a four-year university, in which time is spent taking liberal arts classes and participating in other activities. I won’t argue the merits of each. Suffice it to say that coding bootcamps and other compressed certificate programs have become a major source of new developers entering the workforce.
By examining the curriculums of these coding bootcamps, we can get insight into the database technologies being taught. Iron Hack is a popular option, with a fully online program or in-person training at locations across 8 countries. Out of a 9 week training program, a third (weeks 4-6) of the course covers the back-end. In this case, the technologies learned consist of NodeJS, Express and MongoDB. The next 3 weeks (weeks 7-9) then introduce React and focus on building an application from scratch using the MERN (MongoDB, Express, React and NodeJS) framework. Other popular bootcamps show a similar preference for teaching MongoDB. It is also becoming more prominent in university computer science programs.
Hyperscalers, Partnerships and China
Several years ago, the hyperscalers were viewed as direct competitors to MongoDB. These concerns were justified, as the hyperscalers were scrambling to roll their own database-as-a-service offerings. These included several relational flavors, but also non-relational variants, like document-oriented stores. In fact, an offering from AWS is called Amazon DocumentDB and promotes “MongoDB compatibility”. This compatibility is pinned to an older version of MongoDB and doesn’t represent a complete implementation.
MongoDB’s licensing change to SSPL in October 2018 created this limitation for the cloud vendors. This license change explicitly prevents other parties, like the cloud vendors, from providing a hosted version of MongoDB without a commercial license. In reaction, the hyperscalers either took the Amazon approach of pinning to an older pre-SSPL version of MongoDB or developing their own proprietary document store. In Microsoft’s case, they offer Cosmos DB, which includes compatible APIs for both MongoDB and Cassandra.
While we always have to monitor the offerings from hyperscalers, if we look at DB-Engines and Stack Overflow, these hyperscaler solutions don’t appear to be gaining much traction with developers. They are certainly used, but haven’t achieved the broad market appeal of MongoDB. For example, on the latest rankings from DB-Engines, MongoDB sits at position 5 with a score of 489, while the highest ranked hyperscaler offerings are Azure SQL Database and Amazon DynamoDB at positions 14 and 17 with scores around 85 for Azure SQL Database and 80 for DynamoDB.
I think there are a couple of advantages for a neutral, independent provider that explain why MongoDB appears to be pulling away from the hyperscaler alternatives. I discussed these advantages in a prior post on independent software providers and the cloud vendors. I think those advantages are manifesting broadly in the performance of independents across several categories of infrastructure services, including observability (Datadog), security (Crowdstrike), identity (Okta), edge compute (Cloudflare, Fastly), etc.
On product development, MongoDB’s focus on a single service category inevitably results in a more complete solution. While the hyperscalers have much larger technology budgets, these are sub-divided many times to support each product. AWS, for example, has 15 separate offerings in their database product category. This plethora of offerings is repeated across 26 product categories. While I don’t doubt that AWS can compete with independents in many product offerings, that is still a lot of landscape. In many areas where independents have chosen to specialize, the independent offering often surpasses that of the cloud vendor in capabilities and features.
Multi-cloud ambitions for enterprise customers also limits the growth potential for any proprietary hyperscaler solution. A custom-built data interface and storage engine creates a unique set of interactions and patterns for a developer to learn. Multiplied across several cloud vendors, that represents a lot of mental overhead. Any large enterprise has to plan for multi-cloud, even if they primarily occupy one cloud vendor. This is due to the need to avoid the perception of lock-in, in order to maintain a strong negotiating position. Also, in some industries (like e-commerce, health care, financial services, gaming), the cloud vendor can emerge as a competitor, creating an awkward situation for the CTO when all their infrastructure is hosted by the cloud division of that new competitor.
Given these advantages, the disposition of the cloud vendors towards the independent providers has shifted radically over the last couple of years. They have pivoted from competitors to enablers. At the very least, we see a form of coopetition (cooperative competition). This shift coincided with the emergence of cloud versions of independent software vendor offerings, like MongoDB Atlas or Elastic Cloud. These cloud offerings generate revenue for the hyperscalers, because the independent software provider services run on top of the cloud vendor’s core compute, storage and network. Most cloud vendors have even incorporated the offerings from the independents into their own marketplace of third-party solutions (which they presumably earn a revenue share from).
This is all to say that MongoDB has a productive relationship with all three U.S. hyperscalers at this point. Atlas runs on AWS, Azure and Google Cloud. As part of the Q1 FY 2022 earnings release, management pointed out that they “closed our strongest quarter to date with AWS, Google Cloud and Alibaba.” These co-sell arrangements are resulting in significant usage growth for MongoDB.
During MongoDB.live in July, leadership included a partner awards section. AWS was named the Cloud (Co-Sell) Partner of the Year. Google was named the Cloud (Marketplace) Partner of the Year. MongoDB has a strong partnership with Microsoft as well. Given the progress of these relationships, it’s fair to say that hyperscalers no longer represent an existential risk to MongoDB. MongoDB is now thriving as a result of these partnerships with the cloud vendors. Today’s situation would have been hard to imagine back in 2018.
I think the change in the relationship with the hyperscalers can be traced to two significant developments – one is a carrot and one is a stick. The licensing change back in 2019 was the stick. It prohibited outside parties from hosting the open source version of MongoDB for a fee. This pinned the AWS Document DB product to an older version of MongoDB. In parallel, the MongoDB product team kept building out new features and capabilities under the new licensing model.
The carrot was the move to the cloud. MongoDB Atlas is hosted on AWS, Azure and GCP. When developers pay MongoDB for use of Atlas, it generates revenue for the hyperscalers, as a consequence of the incremental use of storage and compute resources. Granted, the hyperscalers would prefer that developers pay for their data products, but those carry internal costs to build and maintain. It is likely that this shared benefit is the driver for the recent cooperation in sales efforts with MongoDB. And MongoDB isn’t unique in this regard. Snowflake (SNOW) benefits from similar synergies.
This question was raised about AWS on the Q3 earnings call. MongoDB’s CEO spoke to the shared incentives in his response.
What I would say is that the cloud partners have kind of realized that when the workload and Atlas workloads move on to the cloud, they’re the beneficiary of multiples of the revenue that spent with us on their platform between the consumption of the underlying storage and compute, as well as all the other ancillary services that customer may use.
And so, it’s truly — it sounds like a cliche, but it’s truly a win-win relationship. So, we’ve seen our partners. And obviously, last week, we had some great relationships with senior-level people at AWS because the relationship is really working, and we’re seeing a lot of — we’re doing a lot of business together, and we’re becoming a very, very meaningful partner for them. And so — and I think it’s — we’ve obviously been working with them closely now ever since the launch of Atlas over the last five years, and we’ve learned a lot of lessons, it’s important not only to have product integration.
It was also important to have the sales organization aligned to work well with each other. And that took a little bit of time to work through because naturally, there’s some competitive offerings and salespeople are not the most trusting types when they have to work with someone who have a competitive offering. But when you incentivize them to work well together and it becomes clear that we have a far superior solution, the cloud rep from the particular cloud providers is more than happy to work with us because they’re going to get so much of the business that comes to them. And that’s essentially what’s happening.
We’re doing now deeper integrations. And then as we talked about, we announced the pay-as-you-go announcement for the AWS Marketplace. So, we’re just making it easier for our customers to do business with us and the cloud provider together, which is good news for everyone.
MOngoDB CEO, Q3 FY2022 EArnings Call
Alibaba
As a final note on partnerships with cloud vendors, MongoDB has a unique relationship with Alibaba. The MongoDB open source project is very popular with developers in China. Due to regulatory limitations, MongoDB could not offer Atlas on top of the cloud infrastructure provided by Chinese hyperscalers. Presumably, this is due to concerns over data exfiltration. To account for this, MongoDB licenses their software to Alibaba and Tencent, who then resell it to Chinese customers. This approach has allowed MongoDB to offer its product to the Chinese market. They are starting to see material revenue benefit from these partnerships.
The Alibaba partnership will be one to watch, as that could eventually drive significant revenue by itself. This would be in addition to the growth of the Atlas offering outside of China. They have been discussing this partnership for over a year, and it now appears to be gaining real traction. During MongoDB.live, Alibaba was named as the Emerging Cloud Partner of the Year. The VP for Data Platforms from the Alibaba Cloud team also presented at MongoDB.live. He highlighted that MongoDB is one of the most popular open source databases in China.
Cloudflare
While not a full-fledged hyperscaler, Cloudflare is an aspiring one. During their Full Stack Week in November, Cloudflare introduced a new data storage integration with MongoDB. By importing MongoDB’s Realm SDK into the code running on a Worker, developers can connect to and query data stored on an MongoDB Atlas cluster. Realm is commonly used for facilitating data connections for mobile apps. By replacing the mobile app with worker instances running on the closest Cloudflare PoP, Cloudflare can help developers deliver a faster experience for a web site that has a MongoDB back-end.
The fact that Cloudflare chose MongoDB for this relationship is telling. They have a similar relationship with two other distributed data providers, Fauna and Macrometa, but neither is a direct competitor to MongoDB and both are private companies. This leaves MongoDB as the only publicly traded company with this relationship. We would expect the Cloudflare team to have been very thoughtful about the vendor invited into an integration like that. It was likely driven by demand from Cloudflare’s own developer customers. Given that Cloudflare is viewed as being a technically forward-thinking organization, this relationship provides a signal about future demand for MongoDB from developers building the next generation of distributed applications.
Talent Influx
The flow of human talent is often a reliable indicator of companies that are innovating and building momentum. With that litmus test, MongoDB is situated very well. First, Mark Porter joined MongoDB as CTO in July 2020. Mark had been a member of the MongoDB Board of Directors. Mark was eager to assume an operational role at MongoDB. As head of technology, he felt he could cap off a long career building and using databases. The MongoDB solution for him is the natural evolution of data storage, beyond the strictly relational model that dominated for the past half century.
With his background, Mark could have worked anywhere. Yet, he chose MongoDB. This included prior stints at AWS and Oracle. The fact that he views MongoDB as some sort of culmination aligns well with the evolution of database models that I had discussed earlier. He views MongoDB as representing the logical progression in database technology.
In September 2021, MongoDB hired Peder Ulander as Chief Marketing Officer. Ulander will oversee the marketing organization including marketing operations, corporate communications, demand generation and field marketing, growth marketing and content marketing. He reports to the CEO.
Ulander was most recently at AWS, where he was the Head of Enterprise and Developer Marketing. Prior to that, he held leadership roles at Cisco and Cloud.com. He excels at working with developer organizations to educate and facilitate the adoption of new technologies and ways of working. This is an ideal match for the evangelism motion needed to support MongoDB’s expansion as the Application Data Platform.
MongoDB is reinventing how developers work with data to build modern applications and helping companies innovate more quickly. Adding Peder to this equation will dramatically accelerate our efforts to become the world’s pre-eminent application data platform.
MongoDB CEO, Press Release, September 2021
Finally, the new head of developer relations, Rick Houlihan, was previously at AWS for 7 years. At AWS, he was the self-described inventor of DynamoDB. He led much of AWS’ NoSQL database development, including the serverless offering, in roles such as Principal Solutions Architect and Senior Practice Manager. He had worked for MongoDB briefly in 2013-2014 before going to AWS.
Houlihan is active on Twitter and pulls no punches about his opinions on the primacy of MongoDB’s solution relative to others, including offerings from AWS. He appears to me to have a deep understanding of database mechanics and developer preferences. After years of doubts about MongoDB’s relevance and position in the database market, Houlihan is just the voice needed for developer advocacy.
Competitive Landscape
I won’t spend a lot of time here, as I have provided fairly detailed competitive analysis in prior coverage. Fortunately, we have a good third party scoreboard to represent traction of different database offering across the industry. Besides Stack Overflow, another indicator of data storage engine usage across all categories is provided by DB-Engines. They maintain a ranking of popularity of solutions on their web site, with an overall score and an indication of change in magnitude compared to the prior month and 12 months before. This is constructed from a combination of inputs pulled from various public forums, discussion boards, web sites and job postings, which are all heavily developer influenced. Like the Stack Overflow survey, this provides a reasonable indicator of overall database adoption and changes over time.
Looking at the database solutions that I consider within the competitive sphere of MongoDB, we have the following:
- Microsoft SQL Server. Has been in the market for many years. Largely considered a legacy relational database at this point. Its popularity score has been diminishing gradually.
- Redis. The next largest share behind MongoDB. It moved up one level over the last year, passing IBM Db2, which is a legacy solution. It is still about 36% the size of MongoDB, but growing quickly in popularity. Redis is maintained by private company Redis Labs. They will likely IPO at some point.
- Elasticsearch. Maintained its position with reasonable annual growth. Primarily a search index, but overlaps with MongoDB’s growing search offering. This is maintained by publicly traded Elastic (ESTC).
- Cassandra. Moving down in the rankings. A few years ago, this was a popular wide column store. Cassandra is maintained by DataStax. They added data streaming capabilities recently, but haven’t expanded their core offering much beyond that. Privately held currently, with talk of an IPO a few years ago.
- Amazon DynamoDB. The highest ranked hyperscaler database product, besides Microsoft’s legacy SQL Server offering. It is at about 1/5 the score of MongoDB and maintaining the same relative position in the rankings.
- Neo4j. Popular graph database. Moving down in the rankings.
- Microsoft Azure Cosmos DB. Moved down in the rankings over the last year and 1/10 the score of MongoDB. While Microsoft highlighted usage growth in their latest earnings call, their relative share appears to be steady.
- Couchbase. Moved down two levels from a year ago. This is the most directly competitive offering to MongoDB and is a recent IPO with ticker BASE.
- InfluxDB. Moving down in the rankings. Has been a leading time series database. It’s possible that the addition of time series storage capabilities by other vendors (including MongoDB) is taking share.
- CockroachDB. (Score of 7.5 with ranking of 58, down from 56 a year ago) This distributed relational database was generating a lot of buzz 1-2 years ago. Over the course of 2020-2021, they moved from position 68 into the high 50’s, but have stalled recently.
While financial performance may vary from changes in these rankings and scores, I think they are directionally useful. Also of note is Snowflake’s (SNOW) rapid ascendancy. They shot up from position 35 a year ago to 15 currently. That represents the biggest relative change of any company in the rankings. Given their rapid revenue growth and customer expansion, this change in the DB-Engine rankings is understandable. Something to consider for SNOW investors (which I am).
Risks
MongoDB has significant tailwinds from the external trends I have discussed and their own internal product positioning. I think these will provide the support needed for MongoDB to continue its revenue growth acceleration and then sustain high growth going forward. There are some risks to the story, though, which bear mentioning.
Open Source Alternatives. Of all software infrastructure segments, transactional databases probably have the most existing solutions that are open source. As we see in the survey results from Stack Overflow and DB-Engines, MySQL and PostgreSQL still command a large share of the market. These provide an ongoing undercurrent of “free” alternatives, which always represent a perceived cost comparison to commercial products like MongoDB.
Fortunately, I think the shift to cloud hosting has mitigated the impact of this. Offering a cloud-based data storage solution, like Atlas, provides a cost savings argument on the infrastructure operations side. Engineering organizations evaluating open source alternatives have to consider the cost of running their own infrastructure (or paying someone else to run an open source project). This “bundling” of the database solution and the hosting infrastructure allows the commercial offerings to justify their cost. I think this drives the inflection we have seen in growth from the many commercial infrastructure offerings that have an open source project at the core. Confluent, Elastic and MongoDB all provide examples.
New Entrants. Like MongoDB, smaller competitors in the transactional database market are expanding their offerings into other workloads. They see a similar opportunity to address a larger market segment. Examples include Couchbase and Redis. Currently, these companies are operating at a smaller level than MongoDB and growing more slowly than Atlas.
However, we have to be mindful of possible encroachment from leaders in other data storage markets. As one example, Snowflake markets itself as a cloud data platform, not a data warehouse. This labeling is intentional, so as to not limit themselves to a smaller set of use cases. The tagline is “A single, global platform for your data and your essential workloads, with seamless data collaboration.” This leaves the door open for extensions into new data processing areas beyond analytics and machine learning. While leadership has downplayed any intentions to address transactional workloads, they do include Data Applications as a target market segment. As they tune response times and concurrency, Snowflake may move further up the application stack. Having all of an enterprise’s data in their Data Cloud would certainly represent a desirable end state.
Investment Take-aways
All in all, I think MongoDB is emerging as a significant player in the transactional database space. I covered their expanded platform offering in a July post. At their annual user conference in mid-July, MongoDB positioned themselves as the first “Application Data Platform”. This represented a significant departure from previous messaging as the leading document-oriented (or NoSQL) database. Their vision is to address all data storage workloads that developers typically need to build a modern, scalable software application. The scope of that goes far beyond their previous niche, and spans relational workloads, caches, search indices, mobile app interfaces and even basic analytics for data visualizations. And it is all available on the major cloud platforms, with support for data sharing across cloud vendors.
I like companies that are exhibiting product and market expansion, coupled with strong execution. MongoDB is doing both. Particularly on the product side, MongoDB has emerged as the leading independent modern database provider and is even demonstrating a favorable competitive position with look-alike hyperscaler offerings. They are still the most popular commercial solution with developers and are employing a familiar “all in one” platform strategy to soak up spend for point solutions in data storage. Their argument is that development teams would prefer to maintain one data storage interface for all relational, document, graph, key-value and time series workloads. That positioning makes sense to me.
Given these developments, I think MongoDB is entering a phase where they will benefit from a confluence of external and internal factors. I think these place the company in a sweet spot in their history. Some refer to this disruptive momentum as an upturn in their “S curve“. I think there are several factors that provide tailwinds:
- An exploding need to collect, process and move data around, driven by digital transformation and smart devices. This has created a large and growing addressable market.
- Shifts in developer preferences and the need to consolidate database solution sprawl.
- MongoDB’s product expansion to address the majority of common application data workloads. This has made MongoDB’s portion of the total addressable market much larger in the last year.
- High familiarity with developers and the breadth of existing installations. Significant interaction with the open source community version, but sufficient proprietary and cloud add-ons to justify an upsell.
- A favorable competitive position and a reversal in relationships with the hyperscalers.
These factors are providing a favorable set-up for MDB in 2022. Their valuation metric is reasonable for a 50% grower, with a trailing P/S of 34. The market has historically assigned MongoDB with a valuation premium (over say ESTC) based on the perception of their large TAM. I think MDB’s stock price could increase proportionally to revenue in 2022, if their 50% annual growth can be maintained. Given the momentum in customer additions, the uptake of Atlas, further platform expansion and the tailwinds of digital transformation, I think that growth rate is achievable. With a $850M revenue target for the current fiscal year, MongoDB has plenty of headroom to expand into the nearly $100B TAM for database spend over the next couple of years. If anything, the hyperscalers provide a reasonable proxy for growth rates at large scale, recently delivering annual revenue increases in the 40% range.
Given these factors, I have increased the allocation to MDB in my personal portfolio. It is currently at 8% and I may continue to increase it slowly. I would like to see another quarter of outperformance before another large step up in my allocation. There are some risks to their strategy, but I really like their product positioning and execution as we work through 2022.
I initiated covered of MongoDB in November 2019 when it was trading at $141. Back then, I set a 5 year price target of $490, achievable by 2024. MDB passed that mark in November of 2021, reaching a peak of $590. Currently, it has settled around $420 with the recent sell-off in high multiple stocks. I think MDB can revisit this ATH price within the next 12 months with continued strong execution. As 2022 progresses, I will update this price target to reflect where I think the stock can go over the next couple of years.
NOTE: This article does not represent investment advice and is solely the author’s opinion for managing his own investment portfolio. Readers are expected to perform their own due diligence before making investment decisions. Please see the Disclaimer for more detail.
Hi Peter
With your focus on data – MDB and SNOW – I am curious on your opinion on CFLT ? Data in motion is turning out to be a new and important category for companies and CFLT is leading the charge – following you for a while now, i would assume that this is something you would be considering – any thoughts, future articles etc ?
Yes – Confluent is on my radar as they provide an important role in the data landscape. Since they are a relatively new IPO, I have been staying on the sidelines. I would like to see how durable the revenue growth is from here, before considering a position. At small scale, I think it has been easy to post elevated growth numbers. I also would like to see the TAM validated by their ability to maintain large customer growth.
Well written on MDB. I have owned it for few years, just because that time one of my IT friends talked great things about it. Here I want to ask something may not be directly related to MDB. It is CFLT. Do you think CFLT compete with any of existing Database vendors and have you paid any attention to CFLT ?
Thanks!
Hi – that is a good reason to own MDB. I have looked at Confluent. It wouldn’t compete with any of the data storage companies that I have discussed. It is neither a transactional database (MongoDB) nor is it a data warehouse (Snowflake). Confluent facilitates the movement of data between systems and data stores. Since it is relatively new IPO, I have been staying out the stock for a few quarters. Also, I want to see how durable their growth is. Right now, their scale is still small, which makes the elevated revenue and cloud growth relatively easy to achieve. I would like to see if this growth stabilizes or decelerates significantly over the next couple of quarters.
1) Thanks Peter, for another great article.
2) I’ve read a little about federated databases, including Starburst and Ahana (both derived from Facebook’s Presto). If I’ve got it right, the big advantage is there’s no need to do extract-load-transform before doing queries. But, the queries take longer, and it’s hard to make sure all the data is both available and secure. Does MongoDB’s federated querying have similar advantages and disadvantages, or is it not very similar because it needs a data lake? Are Starburst and Ahana likely to be serious competition for MongoDB, or does MongoDB have a better way to bring all the data together? (As usual, I’m not a techie and I hope this makes some sort of sense.)
Hi Michael – thanks for the feedback. The tools you reference, Starburst and Ahana, are both for data analytics. The vast majority of MongoDB’s workloads sit in the application database layer, which is in front of the analytics store. It provides the transactional data store for the web and mobile apps, which Starburst and Ahana would not do.
On the analytics side, MongoDB supports the ability to extend data queries to a data lake (like files in AWS S3) and run them in parallel to queries against the main transactional store. However, this isn’t meant to be a replacement for a full-fledged data analytics solutions.
So, really apples and oranges.
Thanks!
Hi Peter,
I was delighted to see your post on Saul’s Investing Board — what a great addition your voice is for them!
But I was curious about something. In various ways, in your analysis of MongoDB on Software Stack Investing, you made it clear that, in your opinion, MongoDB has “expanded their product reach by maybe 10x.” Your point is compelling and persuasive. Yet, in your post on Saul’s, you did not make this point as forcefully as I expected, writing, “This expands MongoDB’s portion of the addressable transactional database market significantly.” Upon further reflection, do you feel that the “10x” number is over-optimistic or unattainable or encumbered with obstacles, such as competition? To be clear, in your SSI entry, I understood the 10x number in the spirt of TAM — not a prediction of stock performance.
Thanks for any additional thoughts!
Erik
P.S. I believe that an earlier comment I made on this site might be in the “moderation” phase — Could you please not post it? Your authoritative post to Saul’s made it extremely unnecessary. Thanks!
Hi Erik – Apologies for the delay. I base the 10x estimate on the number of data storage use cases that are addressable now by MongoDB with the Application Data Platform, versus their prior focus on just document-oriented databases. If we look at the content shared at MongodB.live last year, they have added support for key-value, wide column, graph, time series, search, analytics, relational and a couple variants of mobile data caches. The 10x factor may be a little optimistic, but the point is that there are many more workloads that MongoDB can address than before. I think this does expand the serviceable portion of their addressable market significantly.
Hi Peter,
How do we know that usage is increasing for the key-value, wide column, graph, time series, search, analytics, relational ..adds to the Application Data Platform (beyond the original document-oriented use case) ?
Has management ever mentioned this?
Is it through the 80% Atlas growth that we are deducing this?
Hi – fair question. MongoDB hasn’t published objective metrics on the uptake of each use case. We have some anecdotal evidence from earning calls and customer testimonials. On the Q3 earnings call, they highlighted a few examples – Coinbase using analytics and QHealth using search and mobile sync. In the Solutions section of their web site, they include a few examples. As one, the IoT section references Bosch and their storage of time series data.
However, the impact of the new positioning remains to be seen. I like the idea of it, but agree that we want to see evidence.
Thanks a lot!.
Is there a comparison of say Atlas search vs Elastic in terms of how far they are from the leaders in the use case they are supporting in Application Data Platform. E.g Or Atlas vs Cassandra for wide-column? Their doesn’t have to be a immediate parity but as long as their are differences are closing it’s a good sign.
MDB Earning looks great and stock is up AH. Congratulation!
Thanks – I really liked the results. Demonstrates that their product strategy seems to be working. Here were the highlights that I thought were noteworthy:
– Revenue acceleration by 5% to 56% y/y growth. Strong initial read for FY2023 – normal beat/raise implies another 50% growth year.
– Profitability Improvements: Positive FCF (6% margin), nearly break-even on Non-GAAP op margin and 2% improvement in gross margin
– Atlas growth accelerated slightly and is now 58% of total revenue.
– Uptick in large customer metrics: Direct Sales customers jumped 12.8% sequentially and make up 86% of revenue now. Added record number of $100k ARR customers. Announced 164 $1M customers, up 70% y/y.
– Highlighted partnerships with hyperscalers, resulting in 80%+ growth in deals sourced with cloud vendors in Q4.
Peter,
Thanks. Do you mind updating us what’s your current holding stocks ? Can’t easily find it on your site. The one I saw was for end of 2021.
Thank you.
Peter,
Sorry, please ignore my last question. I think I have found your latest portfolio update.
Thanks!
No problem, Martin. I update my personal holdings weekly under the Coverage tab.
Peter, your portfolio has lot exposure to cyber security stocks. Wondering if you have looked at the Identity and Access leader OKTA ?
Hi, Martin,
This page is a chrestomathy of Peter’s past commentaries (on SSI) about Okta/OKTA…
https://softwarestackinvesting.com/tag/okta/
Peter, I see MDB net operating income loss isn’t improving. How do you assess this problem ?
Well, it is improving on a Non-GAAP basis, but on a GAAP basis has been roughly even year/year. Of course, GAAP includes SBC. I won’t get into the relative merits of relying on GAAP versus Non-GAAP. I tend to prefer to watch trends in Non-GAAP, as SBC can introduce noise based on share price and other factors. On a free cash flow basis, we do see marked improvement year/year. FCF can provide another useful proxy for gauging improvements in profitability.