MongoDB Stole My Lunch Money and Ruined My Startup

It didn’t.  The title is a lie, but it probably got your attention.

I wrote this because I’m seeing a lot of blog posts out there that follow the same sequence of events.

  1. Forward thinking architect decided to branch out and use a NoSQL database.
  2. The aforementioned architect experiences difficulties querying data, and (out of nowhere) starts to experience performance or stability problems.
  3. Formerly forward thinking architect excoriates selected NoSQL database for not being a Perfect Utopia of data storage
  4. Formerly forward thinking architect then chooses one of two paths:
    1. Publicly renounce the selected NoSQL database and declare allegiance to another product.
    2. Begrudgingly accept the shortcomings of selected NoSQL database whilst whining about its shortcomings.

Almost never do you read a blog post like this that ends with the words.  “I’m like an over-excited puppy following every technology trend blindly.   I take full responsibility for not using technology responsibly.”

It is almost a rite of passage for today’s startup crowd, and the Mean Time Before Anti-Mongo Blog (MTBAB) seems to be about 12 months post adoption.   I’ve come to consider these as not so much “anti-Mongo” post as they are “Relational expatriate” posts – longing for the comforts of the Old World.

You should have thought of that before you got on the Boat….

new-sql“Relational Expatriate” what does that mean?  Think of this movement toward NoSQL databases as a mass exodus.   Back in 2008, you had an initial emigration of people motivated out of sheer invention or wanderlust.  People with little to lose (one person startups) or people who are under intense pressure to find a new approach (people working at Massive scale).  Over time, this population starts to setup infrastructure (vendors, documentation, companies like 10gen), and you start to attract more conservative architects to this movement from SQL to NoSQL.   These new adopters (you can call them the late majority), they have an entirely different set of motivations and tolerance to risk.

Inevitably you are going to have some backlash.    You are going to see these posts where someone laments the absence of something they took for granted in the Old World.  Example, a post by an architect who laments that MongoDB offers no Joins and no SQL.  There’s no acknowledgement of the initial problems that motivated the jump to NoSQL in the first place, just this overall angst that something has been lost in the transition.   Some of these people need to just get on the first boat back to “Relationalistan”.

Who jumps to MongoDB right now and then laments the lack of JOINs?   Who are these people running production databases that are freaked out about memory consumption?  When I read this I immediately wonder…

What drives this constant barrage of anti-mongo rants?

When you see these posts, you have to ask yourself “why?”   Why am I reading posts specifically about MongoDB.  I see a few possibilities:

  • Option A: MongoDB is so awful it deserves universal blog scorn.
  • Option B: MongoDB is a bit over-hyped and users are getting trapped by a technology that over promises.
  • Option C: The author of the blog post is a bumbling idiot always stumbling for the next shiny bauble, never satisfied, and stuck on an interminable hamster wheel of NoSQL databases.
  • Option D: MongoDB has captured the market.  The only reason you are seeing an anti-rant about MongoDB every 5 seconds is because they just have that many users.
  • Option E: 10gen competitors are spending money trying to get people to write blog posts about how lame MongoDB is.
  • Option F: Programmers are just a bunch of whining yap dogs going on and on about how difficult everything is.

My sense is that it is a mixture of Option D and Option E.    MongoDB has captured a large market, and because of this, you’ll see a remarkable uptick in the number of negative posts.  Right or wrong, I do believe that there are a lot of players interested in seeing MongoDB face-plant.  There’s gold in them hills, and everyone’s convinced that 10gen has found a profitable vein in the ground

Yes, the MongoDB community engaged in some extreme overhyping years ago, but if you missed the first episode of MongoDB performance problems (what back in 2010?)  Then you are not paying close attention to the technology you are adopting.   It is my understanding that they identified some glaring gaps in the product and that they pivoted to address them as quickly as a database company can.   Meanwhile I’m still running a fairly old version of MongoDB in production (with only occasional issues mostly related to limited disk space and the fact that few programmers or operations people understand what the thing even does).

MongoDB, like any other database, has a few realities for performance that are unavoidable.    If you do your research you’ll understand these limitations up front; if you don’t, well… MongoDB isn’t really new anymore, so writing a 10 pager about how it uses too much memory and how you can’t JOIN data.  That’s less a blog post about MongoDB and more a blog post about you as consumer of technology.   I’d understand if the thing was 12 months old and people wrote a 10 pager about how they were surprised, but if MongoDB surprises you today – that’s entertainment.

Also, I’m a bumbling idiot

I use MongoDB on a particularly large project.  (No, I won’t tell you which one.)  Am I 100% happy with it?  Nope.  It’s a pain to query sometimes, but it does the one thing I need it to do well (and it isn’t  really a database, sorry).  I’m about as happy with it as I am with every other piece of software in my stack from Maven to Java to MySQL to bash.  All of these things at some point during the development lifecycle are a Pain in The Ass (PITA).   I call this the Universal Law of Software Development which can be summarized as: “There is always something wrong with your software development ‘stack’.”

I’ve written at least one of these posts, and I can tell you that it was motivated by Option C “The author of the blog post is a bumbling idiot”.  I’m like an over-excited puppy following every technology trend blindly.   I take full responsibility for not using technology responsibly.

There’s nothing wrong with MongoDB. Maybe we should all stop complaining so much and get back to work?

  • Tim

    Option E., really? Come on. Option C. & D. make way more sense, especially Option C.

  • http://twitter.com/Obdurodon Jeff Darcy (@Obdurodon)

    Options C and F certainly exist, but they don’t explain why MongoDB gets so much more scorn than other databases that have even less to offer. Mostly I think it’s option D with a twist: not only have they attracted many users but they have specifically attracted a fairly unsophisticated kind of user who is likely to get themselves in trouble by not understanding the technology’s fundamental characteristics. On the flip side, some of the alternatives have communities distinctly marked by a higher than average level of arrogance/condescension and a surfeit of devs/users who like to jump on Twitter to bash(o) everything that doesn’t meet their irrelevant standards. That’s not quite your option E – I’m sure nobody’s actually *paying* for these hatchet jobs – but it’s pretty close. People who rely heavily on a certain technology don’t want to see the company behind it fold, so they’ll work for that company’s interests even without any money changing hands.

  • http://tmo9d.wordpress.com Tim O’Brien

    Jeff, that’s an interesting take on the situation. MongoDB has successfully attracted a unsophisticated user. A user who while unhappy with something MySQL, probably has no idea what a query optimizer is and is therefore surprised when they start using a “database” that doesn’t have one. I know I didn’t know just how intelligent query optimizers were until I ventured off the relational database territory.

    If you are right about this success at attracting unsophisticated users it almost makes the case that you don’t want to make a technology “too easy” to adopt. When I work with software companies, I point to 10gen as a great example of a company that has made it easy to start using a technology, but this is the downside. It’s so easy to use MongoDB, you don’t even have to have a brain! Ok, that was hyperbole, but the point is made.

    I still think there’s a little bit of people paying for anti-Mongo rants. This could just be because I tend to read almost every anti-anything post as a skeptic. This is especially true if I see one author writing several anti-mongo posts in quick succession (which I’ve seen recently).

  • http://tmo9d.wordpress.com Tim O’Brien

    I know. In addition to sometimes being this idiot, I’ve worked in the industry long enough to know that there is an excessive number of idiots running around these IT departments. If the question is “Why do developers continuously run into brick walls at full speed and blog about it?” The correct answer is probably, “Because there are a lot of dumb developers.”

  • http://twitter.com/Obdurodon Jeff Darcy (@Obdurodon)

    Tim, we’ve actually run into this “made it too easy” problem on my project (GlusterFS). Now it’s possible for people to set up a distributed filesystem with just a few commands, and many do so without understanding that this stuff is still really hard or knowing what kinds of problems they’re likely to run into. It’s a bit like putting a Kiddie Coaster sign on a ride with 400-foot drops and high-g turns. IMO we would have been better off simplifying from back to front, so that by the time we made the entry easier everything else would run smoothly and autonomously. Simplifying from front to back definitely has it hazards.