NoSQL Zone is brought to you in partnership with:

Alec is a Content Curator at DZone and lives in Raleigh, North Carolina. He is interested in Java and Android programming, and databases of all types. When he's not writing for the NoSQL and IoT Zones, you might find him playing bass guitar, writing short stories where nothing happens, or making stuff in Java. Alec is a DZone Zone Leader and has posted 572 posts at DZone. You can read more from them at their website. View Full User Profile

You Definitely Shouldn't Use MongoDB

  • submit to reddit

You may be curious: "Why not, exactly?" Answering that question is the central idea of Sarah Mei's recent blog post titled "Why You Should Never Use MongoDB."

Her use of the word "never" seems like a bit of an exaggeration, but she makes a compelling argument against the open-source document database - or at least the one-size-fits-all attitude some take with it - through the in-depth story of Diaspora, a social network to which she contributed a few years ago.

The central issue for Diaspora, according to Mei, was inflexibility brought on by the document structure of MongoDB. Reorganizing data after the fact - for instance, keeping track of user data as it relates to other user's pages, and posts, and anywhere else it might appear throughout the site - became cumbersome as references duplicated themselves, detached from each other and as different types, on various pages throughout the database. 

According to Mei, MongoDB is for data that can be organized into documents, and those documents should be discrete units. If the links between documents are central to the structure you are creating, Mei says, you shouldn't be using MongoDB.

So, while Mei says that you should never use MongoDB, I think she means that you should not assume MongoDB is what you need, and you should not start with MongoDB by default. Instead, you should adequately plan for your needs, and more importantly, plan for the possibility that your needs may change. 

Also, don't build social networks on MongoDB. I think she really means "never" there.


Shahal Tharique replied on Thu, 2013/11/14 - 6:31am

That blog doesn't have valid reasons to prove their point. Its just a mediocre developer blaming MongoDB for their teams fault. 

I've written a response article for this here .

Gregory Pierce replied on Tue, 2013/11/19 - 2:31pm

Agreed. Seems to be more about a case study in designing a document repository poorly than specifically with MongoDB. If you're looking for the ultimate in flexibility, the approach taken was not the appropriate one for that project.

Rodrigo Asensio replied on Wed, 2013/11/20 - 6:02am

She is blaming MongoDB because her team planned the document structure poorly. Maybe she could be using another more appropriated storage, but instead assuming the mistake, she blames. 

Felipe Lorenzo 6 replied on Wed, 2013/11/20 - 7:13pm

I had a similar challenge with MongoDB only to realize that we design document structure with SQL in mind.  "Thinking in MongoDB" after coming from SQL takes time.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.