Why Did So Many Startups Choose MongoDB?
NoSQL databases were the future. MongoDB was the database for "modern" web engineers and used by countless startups. What happened?
This is part one. You can read the rest of the three part series here.
A few years ago, the world neared peak MongoDB, with some heralding the coming demise of relational databases in “modern software development”.
MongoDB user groups/conferences proliferated around the globe with many thousands attending events. 10gen, MongoDB’s creator, highlighted a number of companies switching over:
The startup community read widely disseminated case studies like Foursquare, The Guardian, Business Insider, and Etsy1:
Hi! Dan McKinley and Wil Stuckey from the Etsy Curation team here. We’ll be your hosts for a three-part series about the use of MongoDB here at Etsy… Our tests found MongoDB to be a sweet spot between reliability, speed, and maturity.
MongoDB was increasingly recognized in industry. In 2012, one analyst sometimes cited by 10gen would call MongoDB "the [San Francisco] architect’s default database choice." It was listed as an increasingly important skill in job posts:
In 2012, Business Insider (itself cofounded by a MongoDB cofounder) would write that knowing MongoDB was "a slam dunk to get you a job."
A 10gen employee coined the MEAN stack (Mongo, Express, Angular, Node), which was pitched as the “modern” web stack — and adopted by many startups:
Seeing the demand, coding bootcamps extolled the importance of the MEAN stack for getting a startup job — and highlighted their cutting edge curriculums:
Authored by a 10gen engineer, the top Google benchmark result for a time showed MongoDB as one of the fastest databases in history — though it failed to account for write time2:
The growth of MongoDB even led to a comedic, but critical video that received hundreds of thousands of views:
Challenges with MongoDB
MongoDB was particularly popular among startups. It was fashionable as the main data store when I was in Y Combinator in the summer of 2012. Unfortunately, I would see MongoDB regularly cause fits for many growing startups.
MongoDB was often used exactly as a relational database, even in financial settings that were tailor made for transactional databases. NoSQL had much to add, but was not a replacement for most existing database technology — despite 10gen's insistence. And even though it was easy to get started with, MongoDB’s imperfect defaults and still developing norms made it challenging in production in 2012. (for a number of other technical critiques see some gotchas and a summary of critiques; see also Kyle Kingsbury's work with with Jepsen and MongoDB)
A well known “unicorn” chose MongoDB. It then found itself chastened after a disastrous MongoDB migration, vowing only to use "boring" tech from then on in private sessions with other VC-backed startups. One prominent VC would privately grouse that he needed to hire a full time team to migrate his portfolio companies off of MongoDB, given the issues they were facing.3
Though MongoDB was easy to use, it was a poor choice in 2012 for many growing startups who didn't question the NoSQL hype, overweighted the importance of usability in a database, and didn't critically assess 10gen's carefully crafted marketing messages. We'll dig into each of these factors over this three-part series.
This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License. Feel free to remix or share it.
By learning the story of MongoDB's success in the early 2010s, it can inoculate us from making similar technology mistakes in the future. While I touch on technical details, my story is primarily about humans — namely engineers and marketers.
Critiques about widely used products like MongoDB can be fraught. My point is not that MongoDB is a poor choice today — in fact, I believe the opposite for the right use cases. Instead, it is to understand why in 2012 a number of growing startups used it when it was not ideal for their use case.
Let's start with the hype around NoSQL and prognostications about "modern" web development.
NoSQL and the "modern" web app
NoSQL was pioneered at web scale companies like Google and Amazon and soon the promised power of NoSQL was widely discussed in the industry. Engineers dealing with much simpler scale would then debate what NoSQL meant for them.
This latent interest would congeal into a broader narrative that NoSQL was the future, soon to replace the vast majority of SQL implementations. Echoing others, Business Insider would broadly argue that "[NoSQL] is better [than relational databases] for Web apps and the cloud." Countless great engineers I knew — on the other hand — felt this hype wildly oversold the benefits of NoSQL, even if it was an easy way to fill conferences, get page views, and pique developer interest.
All this hype came just as many new developers were entering the field, lured by the exceptional growth of the smartphone era. Computer science enrollment was growing dramatically, new coding bootcamps were being founded, and online tech learning was taking off. Node was expanding, allowing front-end engineers to quickly build full stack products — and increasing the number of database decision makers.
Conference/meetup organizers, blog writers, training organizations, and technology consultants realized this latent demand and created the content to cater to it — making it even more pervasive. Smart developer tool marketers also knew this, with 10gen's VP of Corporate Strategy heralding the "post-transactional database future".
This led to a perfect storm.
Hype benefits companies and their stakeholders because it makes it easier to sell a product. It gets you free earned media, capital, users, and open source contributors.
On the other side, engineers constantly seek to learn in an industry where staying up to date is important. When there's something to sell, it’s therefore effective to play into an engineer’s fear of being left behind — or their desire to get a job. This would incentivize some to argue that "you need to stay relevant" — and "get ahead" by learning NoSQL technologies. At its worst, this leads to blindly chasing new technology — rather than solving problems.4
Every web/mobile engineer has to make a determination multiple times each year: misplaced hype or structural shift. Some thought that NoSQL was a structural shift that would replace relational databases for a vast number of use cases.
The first few times an engineer sees this kind of hype, they often think it's a structural shift. For engineers later in our career, we’ll often dismiss structural shifts as misplaced hype after getting burned too many times.5
Both approaches have their flaws, though the latter is often a better approach: misplaced hype outweighs structural shifts, especially the ones that matter for startup technical success.
It's critical to get better at assessing hype cycles.
Sadly, there's no simple empirical test that can help you divine say a Rails in the late 2000s or a Node/Express in the early 2010s (actual changes) vs. a NoSQL in the early 2010s or Hadoop in the late 2000s (primarily hype, especially for small companies).6 But calling bullshit is easier than you think.I'll suggest a simple three part process (PAT) when assessing hyped technologies:
- Problem: Understand your problem deeply
- Assess: Critically assess claims in potential solutions
- Tradeoffs: Weigh tradeoffs in the short and long term, rather than thinking about good vs bad
It all starts with understanding your needs. In the case of NoSQL, if your data will likely never exceed a single, large node (which applies to a surprising number of companies), it's probably a bad idea to give up the consistency in the CAP theorem (which many early NoSQL databases did). This matters all the more if you're working on a financial application where transactions truly matter (or perhaps could in the future) — no matter what some claim about "the future" or "modern web development".
If you're junior, finding a thoughtful mentor who's been through a few hype cycles will save you much grief. And remember that hype often reflects the huge financial returns at stake for vendors, industry analysts, consultants, conferences, and training programs. Even the many technical blog posts about any new technology (say microservices or blockchains or GraphQL today) can reflect the engineer recruiting and SEO goals for companies, not the appropriateness of a tool. Just because a technology seems to be discussed everywhere says little about whether it's a real shift — or the right choice for you.
Engineering managers and CTOs have a large role to play. Their choices dictate the decisions that many engineers make — and by mistakenly favoring hyped tools, they can cause issues in their own stack and distort incentives for other engineers. They also may recruit engineers who will continuously chase new technology, rather than solving the problems the company faces. This also applies to engineers on the job market, who should weigh whether their prospective engineering teams chase new technologies for the wrong reasons — or if these teams will really build your technical chops.
Hype enabled the early growth of MongoDB, as it was one of the top NoSQL choices — but it wasn't enough on its own. In the next posts, I'll dig into the startup engineering mistakes and the marketing strategy that underlay MongoDB's success, but caused issues for countless startups.
This is part one. You can read the rest of the three part series here. To dig in more, you can see select commentary excerpts and my other thoughts.
This essay is based on several years of informal discussions, interviews with key stakeholders, parsing countless blog posts/presentations, and reading ~3000 HN comments. All opinions are solely my own. I welcome feedback (email mongodb at this domain).
Thanks to Mathieu Jouhet for countless hours spent on design and to Shay Maunz for edits. I especially have to thank the many software engineers who shared their experiences and provided feedback.