Back in June I dropped this article: https://obscureproblemsandgotchas.com/development/things-to-know-before-using-mongodb/ and it got excellent reception. I was pleased to hear from colleagues of mine that they read my article and agreed with my views. That’s the best outcome I could get because it means I didn’t miss anything (that I know of).
There were some further developments that happened since then. The project I had been working on, which that article is based on, has reached a critical point. For numerous reasons the data in our MongoDB database has been somewhat ruined and since Mongo does not lend itself to simple data repair via an Database IDE; things have been tense. Finally, it came to a boiling point that we should consider just ditching MongoDB all together and move back to SQL Server.
I was genuinely shocked to hear this was an option and frankly at this point I would like nothing more than to go back to something familiar and easy to work with. Everything I learned about MongoDB was a great learning experience, but impractical as far as I am concerned. It’s an unreliable mess. Like I said in the linked article above – it is great for small projects, caching and read only replicas – but it really sucks at being a DBMS which is ironic.
Epiphany
I had an epiphany that hit me like a pile of bricks after a few discussions about moving out of MongoDB and back to SQL Server. I put up quite the stubborn fight to not use MongoDB’s proprietary identifier ObjectId. I had other engineers in my organization ask me, “Why aren’t you using the ObjectId?” and my reasoning was very simple:
- Paranoia – I have been burned in the past with seemingly wonderful safe things like this.
- Distrust – I don’t trust proprietary things like this because that means I am married to it.
- It’s not a well known identifier – because it’s not a well known identifier I do not want to spread it around our system and then regret my decision later. That’s why I opted for a GUID because everyone knows what a GUID is.
I caught a lot of shit for my decision, but I am stubborn and I am glad I am because had I listened to those biased folks then we would have issued out 24 character strings (Ex: 507f1f77bcf86cd799439011) in multiple tables across our system. I purposely chose the string representation of a GUID so that it was human readable and compatible with the other SQL Server tables that were going to be storing this information. I also didn’t trust their BSON V3 serialized GUIDs. Dodged two bullets.
Escaping from MongoDB
- Now that I am going to be escaping from MongoDB, it hit me how glad I was that I was insistent on being distrustful and paranoid of MongoDB. Because I chose a GUID, I can just stop using MongoDB all together with no consequences and make a clean break after migration.
- Had I listened to the bias, how were we going to continue to issue out MongoDB ObjectIds from SQL Server?
- The only way would to be to always generate the ObjectId from the backend. This would maintain that high coupling to code I didn’t like.
- We would have to keep using the MongoDB DLLs even though we got rid of MongoDB. It would be a constant reminder of the failure that occurred.
Yep… one more reason to not use MongoDB. At the very least do not issue the ID to external systems!
Thumbnail image
- Generated base image with CoPilot
- Modified by including: https://commons.wikimedia.org/wiki/File:Mongo-db-logo.png
