Ever since the hashtag #healthydebate was launched, I've not been able to sleep because of over-excitement. There are so many options in development today, so many pros and cons of everything, that I saw in this hashtag to finally let out my frustrations and learn something in the process.
Disclaimer: I'm going to take the anti-MongoDB side just to keep the debate dramatic. I'm open to being abused (called a 'complete idiot', for example), as long as you're able to back it up with something sound. So, ladies and gentlemen, without further ado, let the games begin!
Every few years, the tech world gets afflicted by a new disease. I was not even in my teens in the early 90s, but I hear that at one time Object-based databases were supposed to "solve" everything in all sorts of development. Later on, I saw everybody going "Big Data! Big Data!", and now, no one knows to which lands it's retreated to.
Some time ago (5-6 years?), the disease known as MongoDB spread from continent to continent, until the blood cells of 60% of the web developers out there were found to contain micro-strings of the form of "web-scale". In this post, I wish to denounce and refute MongoDB so truly and completely that it will be relegated to an artefact in history. Future generations, I'm sure, will look amusingly at the dumps of MongoDB preserved in silicon ember, and shake their heads at how foolish their ancestors were.
So, one by one, here are the scenarios which MongoDB is extolled for by its acolytes. Each of these points is followed by the bitter pill known as "real-world experience", and will serve to contain, and hopefully cure, the disease.
You know who works without schema? Devs that are looking for shortcuts at the cost of integrity (data's and their own). And monkeys. Oh, I'm being repetitive there! The whole sham about moving fast is just that, a sham, because when the app has been in production for a year, the only thing keeping the system from falling apart will be your prayers. If you don't even know what your schema is going to look like, you're not making an app; you're making soup.
A wise man once said that the only kind of data suitable for MongoDB is data that the business deems useless. Use MongoDB, and you will be shaking at the knees on that day when you're asked to generate a report that concerns fields that are embedded 43 levels deep across multiple objects!
Honestly, whoever came up with the term "webscale" needs to be tied to a tree and whipped until he changes it to "business-scale". Nothing is web-scale, folks, nothing. Oh, I guess you could say Google is, and also Facebook, but hey, surprise, surprise, they don't run on MongoDB.
Yes, but having to manage and re-balance shards in an exercise in frustration. You want scalable RDBMS? Well, just go to AWS and sign up for their database service! Google also has a similar offering, and if nothing else works for you, try CockroachDB. With that, scaling is taken care of, and you never have to think again about backing up the database or wrangling with clusters.
So does the MyISAM engine in MySQL (and something in Postgres, I believe). But seriously, fast writes what? A web app is undone not because it runs on a "slow" language like Python or Ruby, but because network connections are still fragile and response times of 400-600 ms are a reality. No matter how fast your writes are, then, the users are not going to notice.
No, it isn't. RDBMS can do loggin just as well, and there are plenty of CMS running on RDBMS to prove that there's nothing special that MongoDB brings to the table.
To conclude, I think such recurring epidemics are due to the creative nature of us developers; we're obsessed with the desire to improve. However, our interests, and the interests of our employers/clients, will be best served if we focus on improving in existing, proven tech stacks, and not try to juggling everything new and hot and look like a circus clown in the process.
P.S.: I hope nobody was offended and that it was fun to read! 😛 😛 😛