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.