Things to know before using MongoDB

## What is MongoDB not so good at If you need a relational database, MongoDB is NOT for you. In other words, if you need to actually relate rows together by performing joins, you DO NOT want to use MongoDB. Use the right tool for the job. Again, it’s good for FLAT structures. Meaning the collection is self contained and does not have dependencies on other collections. Your documents themselves can have nested structures that doesn’t matter. I am going to explain each pain point as its own section of what MongoDB is not great at. … IDEs aside, coming from a strong SQL background myself (mySQL & SQL Server) I can say that querying MongoDB is joyless and frustrating. Learning new syntax isn’t the problem, it’s the inconveniences that come with MongoDB that annoy me such as: - Not being able to save a query to a file and give it to a colleague. - Not being able to save an aggregation to a file and give it to a colleague. - In general just not being able to work out a query in a regular editor window. … *too* bad even on tables with one-hundred million rows I am able to usually perform some kind of analysis without sweating the performance. I cannot say this about MongoDB at all. On a collection of fifty million documents, performing a search without an index is about a two minute plus wait. That’s just horrific performance. This is a fact. This makes performing analysis a very irritating exercise because YOU ARE NOT GOING TO INDEX EVERY QUERY PERMUTATION; nor should you. You don’t even do that in SQL Server because it’s bad for performance and it can potentially double the storage size of your table. … #### Mass deletes MongoDB’s biggest weakness is CUD! It really is terrible at performing CUD operations. Taking the fifty million document collection, if you attempted to deleted all of those documents you would be waiting many hours for it to happen. You are better off dropping the collection and starting over. Dropping the collection takes seconds. - There is no equivalent of `TRUNCATE TABLE`in MongoDB. - You also CANNOT rename collections! You can only drop them and recreate them. Poor design. … With Mongo you will be in for a rude awakening for the following reasons: - You cannot perform mass updates. If you did attempt to perform a mass update, your update probably won’t finish for days assuming we are still talking about a large collection. - You will more than likely have to update your repository layer to now support your new object’s shape and now use … #### Slow rolling migrations are irritating To perform a slow rolling migration, you now have to purposely put tech debt into your code so that you can support two schemas. The idea here is that your code will detect what version of a document you are dealing with. When it finds the old version it has to upgrade it to the latest version. This is as irritating as it sounds. … ## Conclusion Over all, not impressed with Mongo. I feel like it produces more problems than it solves. However, it is fast. I do like using it for smaller projects, nice to not have to worry about data shape. For larger databases, I don’t know that it really makes business sense to use unless it is being used only for reads. As per usual – use the right tool for the job. It’s not bad, but not great either.