Breakup with MongoDB. Now!
EDIT: I am so glad, there's no down-vote button on Hashnode anymore. I am sure I would have got a lot of down votes for this post. :P Keep the flak coming though, I am always happy to be proven wrong. :)
How many times have you been asked to ship a feature that seemed relatively simple, but it took a lot more than you expected to get it done?
From my personal experience, it happens for two reasons:
- When you jump into code too early for a seemingly harmless feature. No matter how small a feature is, one should never jump into code too early. One needs to sit down, design it on a piece of paper, try to break it and only then get to code.
- It happens when you decide to hack around stuff. When you hack around stuff, you're just fixing the symptom and not the problem. For me, fixing the symptom has been usually making MongoDB work the way I want it to work.
Having spent close to three years in this industry, one thing I've learnt about MongoDB is that, it encourages bad design (in your head, when you're designing the schema, you probably assume you have some done some ninja work and go to bed a happy man) by letting you do whatever you want to do.
In reality, you did something, that's going to come and bite you in the back side, a few months down the line. It provides a lot of power to the designer, and as they say, with great power, comes great responsibility. Except, we usually make a mess of it.
A classical MongoDB problem which is really acquired taste and there's no correct answer:
- Do you just store another document's _id or do you embed the whole document? If you go the former route, your api calls increase by the number of id's from other collections that you refer to. If you go the later route, your data duplication increases.
I have decided to stay from MongoDB for all my future projects. Yes, I am breaking up with MongoDB.
SQL offers you a lot of discipline and structure. Who wouldn't love the foreign key constraints it offers.
At my previous job, a lot of developer time was spent on refactoring microservices. No matter how much we refactored, it was to hard to make new changes. That's when I knew, we are fixing the symptom and not the problem.
The problem was going with MongoDB as the DB of our choice . We decided to take three months out to move to SQL (And mind you, I am talking about 15 engineers all focussing only on data migration from Mongo to Postgres). The bug counts came down and it was a lot more easier to make changes and we innovated faster.
I also firmly believe that anything that's possible with MongoDB is possible with a SQL based DB.
If anyone ever asks you to pick MongoDB because it offers faster reads, hunt them down with a baseball bat.