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 see Hacker News comments on part one or read the rest of the three part series.

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:

10gen Presentation on Migration to MongoDB

Source: 10Gen, Migrating from Relational Databases to MongoDB.

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:

Hacker News “Who is Hiring” Trends

Source: Hacker News Hiring Trends, see also Google Trends

Indeed.com Job Trends 2012
Indeed.com Job Trends 2012

Source: MongoDB website.2

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:

MEAN Presentation
MEAN Presentation

Source: Slideshare

Seeing the demand, coding bootcamps extolled the importance of the MEAN stack for getting a startup job — and highlighted their cutting edge curriculums:

Free Code Camp Blog
Free Code Camp Blog

Source: Free Code Camp Blog post, 2014. Lynda.com’s video on MEAN also has ~160k views.

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 time 3:

Mongo vs. CouchDB: Time in Seconds vs Inserts
Mongo vs. CouchDB: Time in Seconds vs Inserts

Source: CouchDB vs. MongoDB Benchmark, Blog of Kristina Chodorow (Mid-late 2009).

The growth of MongoDB even led to a comedic, but critical video that received hundreds of thousands of views:

Mongo DB is Web Scale

Source: Gar1t on youtube.

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.4

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 image 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 10gen 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.5

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.6

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.

Handling Hype

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).7 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.

Next Time

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 and see Hacker News comments on this piece here. Follow me on Twitter.

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.

  1. A year and half later, Dan McKinley wrote about how MongoDB didn’t work at Etsy.
  2. Note: This source was cited by many as a sign of MongoDB’s dominance, but note the small scale size and the unclear methodology for “Top Job Trends”.
  3. Waiting for writes was off by default:
    > This “unchecked” type of write is just supposed to be for stuff like analytics or sensor data, when you’re getting a zillion a second and don’t really care [if] some get lost [or] if the server crashes.
    This was rarely the typical use case in most startups—even though the defaults were based on it for a long time.
    It’s unclear to me how long this was the top Google result, and it was earlier in Mongo’s life (2009). This may be one of the benchmarks that led to anger at competing NoSQL vendors – and seems to me like a mistake rather than a malevolent effort.
  4. Many sources asked that I keep them anonymous.
  5. Jeff Atwood calls this magpie development syndrome.
  6. On the other hand, the mistake for more seasoned developers is that we’ll dismiss new tools due to frustration with the hype, rather than dispassionately assessing a new technology on its own merits. You can’t throw the baby (a new technology) out with the bath water (overwrought hype) – and you have to reassess your views regularly when the speed of improvement is fast
  7. Ozan Onay proposes using the Lindy Effect, which observes that the longer a technology has been around – the longer it will continue to be around.
%d bloggers like this: