MongoDB: Product, Business Model, Competitors

In this post, I will go through the story behind MongoDB, its product, business model, competitive landscape and more.

1. Founding history

MongoDB was born out of our frustration using tabular databases in large, complex production deployments. We set out to build a database that we would want to use, so that whenever developers wanted to build an application, they could focus on the application, not on working around the database.

- Eliot Horowitz, Co-Founder

To understand why MongoDB (initially named 10Gen) came into existence, we first have to travel back in time to the 2000s when developers struggled mightily with the rigidity of database systems at the time.

Databases have been traditionally structured in a “tabular” form, meaning you have to pre-define each row and column prior to deploying any database. In the simplest form, you can think of an Excel table where data is structured into rows, and each row contains information about something:

Tables as such are easy to manage if the data properties are stable. You may also build a “relational” database on top of these tables, where each table is linked via relationships defined by the person who initially built the database.

Tables, columns and rows are great for what they’re designed for – accounting, bookkeeping, and anything you would use Excel for. And for these use cases, they work incredibly well. As such, relational databases have been the traditional (and still the main) method of storing data. And Oracle, for instance, built a huge business selling such systems.

However, relational databases do not make sense for software developers, whose development languages are oriented towards objects and structures, as opposed to rows and columns. Relational databases are also prone to become messy and complex, as you introduce more data properties and relationships to the database. As a result, building and maintaining databases has become a huge challenge for software developers.

During the decade prior to founding MongoDB, the founders had built 12 custom solutions as workarounds for relational databases, including Oracle, BerkeleyDB or MySQL, but none worked for what they needed. As Eliot Horowitz, a co-founder of MongoDB, explained in an interview:

This has a number of problems. One, it’s complicated: mapping a complex structure in a programming language back to a relational data model is complicated; it’s fraught with problems and inconsistencies; and it’s not very human. If you go look at a deconstructed model inside of Oracle, it is very complicated. For a typical enterprise application, a user profile takes around 75 tables.

When Dwight Merriman, Kevin Ryan and Eliot Horowitz founded MongoDB in 2007, they wanted to build a database that developers would love, and one that would break the limitations in a relational database that have persisted for decades.

2. Product

Value Proposition

At its core, MongoDB is a general-purpose database that provides support for document-oriented storage systems. Its flexible data model enables users to store data of any structure, without any need to pre-define any data property. MongoDB is the pioneer of what has come to be called “NoSQL” databases (to be contrasted with Structured Query Language “SQL”, which is a computer language for storing, manipulating and retrieving data stored in a relational database)

To illustrate by way of an example. Let’s say you are a pizza restaurant and you have a list of customers. For the first customer, you have his first name, cellphone number and home address. Now you want to add a second customer, who gave you his first and last names, home and office numbers, and home address. And you want to add a third customer with his first, middle and last names, and office address. If you use a traditional relational database you’d need to amend the parameters everytime you want to grow or shrink the property of the database to accommodate new information, and the task becomes increasingly complex as you expand the database and introduce new relationships and properties.

Unlike a relational database, MongoDB does not require a fixed data structure. That is, you do not need to know in advance what different types of data are going to be stored. This is because MongoDB works on the idea of collections. These collections are like tables but without any fixed number of columns. So each document in a collection can have a different structure, and may or may not have the same number of fields.

It is important to understand the need for a flexible database in the context of modern application development. With the rapid adoption of mobile devices, there is a whole new class of developers with a whole new category of mobile applications, where people want to move faster on the product side and shorten the production timetable. If you want to ship out a new iOS app in 6 months, you’d need a database that can be as agile and as flexible as your product team, while not knowing in advance how the data is going to look like or evolve – either the type, the property or the size. Pre-defining the database schema in circumstances will be almost impossible. This is a practical challenge under the framework of relational databases and is where MongoDB tends to be useful.

This carries two important, practical implications. First, the scale of problems that you can solve (and store) with MongoDB is much larger. Going back to the pizza ordering example, if everyone on the planet is suddenly ordering a pizza on the New Year’s Eve, (a) you can collect every customer’s information without worrying about the type and extent of information you will collect from each, and (b) the built-in scaling-out mechanism of MongoDB allows you to dynamically add server resources across geographic regions to accommodate this jump in data load, and you can scale-out effectively to infinity.

Second, MongoDB gives you a much better alignment between modern application development and database design. Modern applications start and evolve over the course of multiple years and sometimes over a decade. It is not a case where you can pre-determine your database schema and its eventual evolution. You want to be able to reshape data on your own, when you need to. The market need for a flexible database that can adapt to ever-evolving circumstances is what gives MongoDB an unique product-market-fit.

Product lineup and go-to-market motion

MongoDB adopts a freemium approach. At the basic level, they offer Community Server and a free tier of MongoDB Atlas. Community Server is a free-to-download version of their database that includes the core functionality that developers need to get started with MongoDB, and the free tier of MongoDB Atlas provides access to their hosted database solution with limited processing power and storage.

Users who are ready for production can upgrade to their paid services:

• MongoDB Atlas, their hosted “Database-as-a-Service” offering, which is run in the public cloud (AWS, Google Cloud Platform, or Microsoft Azure). Customers pay a monthly fee for this product and it’s essentially the Community Server along with infrastructure and management, removing the complexity and overheads of operating the databases’ underlying infrastructure.
• MongoDB Enterprise Advanced, their enterprise offering that can be run in the cloud, on-premise or in hybrid environments, and includes their proprietary database server, enterprise management capabilities, advanced security features, GUI, analytics integrations, authentication, and technical support.

MongoDB Enterprise Advanced was initially the main revenue contributor when MongoDB went IPO in 2017, and in recent years MongoDB Atlas has overtaken MongoDB Enterprise Advanced as the leading contributor to the company’s revenue.

MongoDB is a cloud-agnostic platform, meaning you can deploy MongoDB on any of the major cloud platforms – AWS, Azure, Google, Alibaba. You can choose to deploy on Azure today, and switch to AWS tomorrow. You may even have a global cluster that covers all of these clouds. From a customer’s perspective, this avoids vendor lock-in, but more importantly, you also get to benefit from all of the appropriate services that you care about. Let's say your data scientists have some need for the data in your data storage, and data scientists love using the TensorFlow. The thing with TensorFlow is that it's only available in Google Cloud. You can have your cluster to be replicated in such a way that it's also available in MongoDB that's running on Google Cloud. And that way the usage of TensorFlow will be a more conducive to your data scientists because data lives in the same cloud where the service is from.

MongoDB relies on a land-and-expand strategy and their go-to-market motion is heavily oriented towards developers. They focus a lot on top-of-funnel marketing to create a breadth of user base. The idea here is to get developers to build a habit using the database, and it will be much easier to convert with such a warm lead within your product team. To date, the MongoDB database platform has been downloaded over 240 million times, with 33,000 paying customers in more than 100 countries. They consistently ranked among the most wanted database solutions in StackOverFlow annual survey, taking the top place between 2017-2020 and finishing 2nd in 2021.

Financials

MongoDB is growing very fast but also losing a lot of money. For FY2022, they did $874 million in revenue, 48% growth YoY. Net loss was $307 million during the same period, a (35)% net loss margin. The implied average customer spend is $26,000 a year (total revenue divided by total number of customers), and they managed to stay above 70% gross margins for the last couple of years.

They are close to neutral free cash flow, but once you exclude stock-based compensation from free cash flow, you will notice a downward spiral. This begs the question of whether they can turn their top-line revenue into meaningful operating earnings, once you take into account the true cost of employee expenses (another way to think about it is, the investors are effectively subsidizing the management and the employees).

The breakdown of their spend as a percentage of revenue is as follows:

3. Competitive Landscape

One useful way to think about the database market is to view it as one between the Old World (on-premise, relational, dominated by Oracle), and the New World (cloud, both relational and non-relational).

In the short term, the Old World will remain as the main way for existing businesses to store data, and you will always need relational databases for your bookkeeping, accounting, financial models and so on. However, we are increasingly seeing people pushing data into the cloud database and it keeps chipping away at the Old World. So automatically, any player in the New World is positioned to benefit from the growth of data and the upward trajectory.

Among the New World, the field is fairly crowded. The Big 3 of Google Cloud, AWS and Microsoft Azure all have their own database with a similar interface as MongoDB, so there is going to be some competition on that front. That said, MongoDB has recently signed partnership agreements with Google Cloud and AWS, and is also available on Microsoft Azure Marketplace so that should address some of the competitive risk. You also have niche players such Redis (focusing on key-value cash) and CouchDB (NoSQL database, focusing on RESTful HTTP API), MarkLogic (NoSQL database focusing on enterprise market) coming to the market at a different angle. Generally, MongoDB is considered the leader among NoSQL database solutions.

4. What’s next?

In 2021, MongoDB re-positioned itself as a “Application Data Platform”. Their vision is to address all the data workloads that developers typically have to deal with: acquisition, storage preparation, delivery, governance, as well as security and even analytics. The scope goes far beyond a NoSQL database solution. It appears that the management is doubling down on the premise that developers prefer focusing on building application features instead of dealing with data workloads. It remains to be seen how the bet will play out.

Thanks for making this far! If you like this article, please consider subscribing to my newsletter to get this straight to your inbox.