Why you should never use MongoDB

An excellent real-life story of actual experience with MongoDB: http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/

I recommend that anyone considering a “document-based” database read this and thoroughly understand what Sarah is talking about…

…because the world IS relational.

This rebuttal was brought to my attention:  http://ayende.com/blog/164483/re-why-you-should-never-use-mongodb

Personally, I find this statement: “And yes, this is a somewhat relational model.” amusing.  Well, since it’s relational, doesn’t a relational database seem like the right tool?  And what does “somewhat relational” mean?  It either is or it isn’t, in my opinion.  There’s no “somewhat” here.


2 thoughts on “Why you should never use MongoDB

  1. The most interesting thing about the referenced article is the fact that the initial Diaspora analyses did not catch that users, likers, commenters, etc. were all instances of the same kind of data. This kind of overlooking at design time would be unthinkable for any relationally-oriented designer. It surprises me that it would not be obvious regardless.

  2. Though dated, I read that same blog post with great interest. I believe the increasing maturity of tooling around MongoDB (i.e. ORMs such as Mongoose) weaken the primary rationale which was basically: document DBs don’t “do” relations well and thus ultimately result in poorly normalized data. In fact, I completely disagree with this last point which is why I came to a different conclusion.

    There ARE reasons to avoid MongoDB. E.g. The blog makes great points in regard to maturity of the tooling and dev community. I don’t think it touched on my biggest complaint which is no native support of datasets that are larger than memory. But it’s been awhile since I read it.

    But I don’t believe the biggest premise of the blog should apply. I don’t believe that normalized data should be avoided simply because it’s a document db. And while I can see value to natively supporting joins; this is something that any good ORM will facilitate for you. I won’t go into the pros and cons of an ORM. But if you loathe them, I agree that Mongodb should probably be avoided.

    All that said, there are two situations where I think a document DB approach excels over traditional SQL.
    – True composition
    – OO Inheritance

    I have at least a couple of real world situations of composition that can only be solved (easily) in relational DBs without breaking the rules of normalization. But I’d argue that this is rare enough as to hardly warrant consideration.

    The far more common situation is supporting object oriented models. IMHO, relational DB simply don’t handle subclassing (“Category” in ERD) very well at all – especially past one level of inheritance. And forget about trying to build decent validation into it.

    A document DB handles these things quite easily and naturally. And given that most programming languages do too; this allows you to essentially remove a layer of abstraction between the DB and the ORM entity supporting it.

    I would argue that a good OO design encourages data normalization. OO tooling and development is extremely mature and does not lead to any of the concerns raised by the original blog. To that end, a database that supports the same approach more naturally can’t be a bad thing.

    I’d like to see more maturity in MongoDB (e.g. native joins, transaction support). I’d like to see better performance with datasets that are larger than available memory. But then again, I’m hardly an expert in this field; and wouldn’t be surprised if there weren’t NoSQL implementations out there that already address these weaknesses.

    My point is, these weaknesses are not inherent to the document DB paradigm itself. E.g. there’s really no reason why one couldn’t have better support for joins. My belief is that these will improve as it naturally addresses it’s biggest weakness over time (i.e. maturity).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s