Call me maybe, mongodb made me boo boo

There has been lots of discussion going around backed up by a certain “call me maybe” article suggesting how unreliable mongodb is.

So the solution is to run off to a SQL database (some also have expressed affection with rethinkdb, elasticsearh and other alternatives).

Well, apart from enterprise big buck alternatives, which have their own serious problems apart from the big bucks, the most obvious ones are postgres maybe and mysql maybe. right?

The point almost anyone fails to read in such articles is the author tryying to convey how hard it is to create a consistent scalability model and how databases known for their scalability actually fail that promise. In fact, there is yet to be one that actually delivers on it.

And it is not just about scalability, it is also about high availability that you should want even though you are working on a tiny dataset if you don’t want your users to experience service disruptions.

And for those who are not familiar, that article about mysql is actually about a scalability and high availability solution from personadb who is known to extend and harden mysql’s capabilities to exceed even the most extreme enterprise demands. They do have a well-earned name for themselves. Yet, call them maybe!

Yet, all those articles also have small hints about why you should not care about those data losses, but instead design your apps for durability. Two phrases come up very often. Idempotent and two phase commit. They are concepts of mutable data storage designs and have been around long before SQL databases and ACID criteria.

So my point is, instead of jumping on every bashing train, we should be aware of the capabilities of our toolsets to design the best experience that can be delivered. That experience might endure data loss, perhaps not even care about it, or require strict data reliability, for which we have engineering best practices regardles of underlying data storage mechanisms.

As developers, we are oblidged to educate both ourselves and our clients about what software engineering is, what tools are ok, good, best or not so good for a task and that the ok, good, best and not so good are not only about technical capabilities because the overall client and end user experience relies on much more than that, like total cost of ownership, incuding operating and maintenance costs, time to delivery, options for disaster recovery, ability to grow the team, learning curves and so much more.

Overall, I believe Meteor has delivered us a very balanced (oh please triple underline that word) stack for versions 0 through 1.x and now they are beginning to introduce diversity to that, and at a rather nice pace.

PS: Joins and aggregations is just another very debatable topic that deserves its own thread, so I’m not willing to go there now. Hint, it is not cool bashing mongodb over that, either.

PPS: You can check out other call me maybe’s such as elasticsearch maybe, cassandra perhaps, redis oh well and many others over at the jepsen section of the aphyr blog.


Well said @serkandurusoy. Now if only all of my clients were as balanced in their thought process as you are, I’d be all set. Some clients get it - I’ve had a blast working with them, Mongo and all sorts of other fun stuff plugged into Meteor. Some clients though just instantly stop listening to any arguments that try to persuade them against the use of their SQL based database of choice (even when it makes complete sense). “But we’ve used Oracle forever and love it!”, “This is our data we’re talking about - nothing is more important, so we have to use DB2.”, “Mongo is what? Oh right, my MS SQL rep told me about that - sounds cute, but come on let’s be serious.” Unfortunately these are more in-line with the comments I hear back. Educating these people is definitely a challenge, but I think we’re slowly getting there.

You nailed it - I couldn’t agree more!

1 Like