MongoDB: easy to use, easy to shot yourself in the foothttps://www.trustradius.com/nosql-databasesMongoDBUnspecified8.22901012019-03-14T14:27:38.664Z
March 14, 2019
MongoDB: easy to use, easy to shot yourself in the foot
Score 6 out of 101
Overall Satisfaction with MongoDB
MongoDB was our main data store used primarily by a web application managing classical relational entities as well as some big data and analytics collection data. Even though no one on the team had much DB experience MongoDB was easy to use and integrate. However, we faced many pitfalls along the way and the end result was far from optimal.
- Easy to set up locally and on different SAAS providers (Compose.io and then MongoDB atlas).
- Being schema-less helped with having a rapid pace of development as there where many schema changes.
- Full stack developers on a NodeJS server could get started very fast as the API was familiar and relatively simple.
- Very hard to tell how to best structure your data and then effectively query it. Most of the time this led to just splitting everything into different collections and joining them on the application server or the client which was slow and hard to maintain.
- Documentation is not friendly and confusing.
- No real joins and complex querying is unclear.
- There where many errors the clients suffered from due to bad migrations and data structuring.
- Development, changes, and migrations where fast.
- Migrations where hard to perform in a reliable manner.
- The company was able to move forward without a DBA.
Your default choice should not be MongoDB in my opinion. Most user-facing systems are relational by nature so a well known and reliable SQL database would be easier to maintain and simpler to develop long term. If you highly value speed of development go with Firebase. If you have a big data type of scenario, Casandra or Elastic-search are probably a better suite. You should not use MongoDB if you don't have someone proficient at it, as you are far more likely to shoot yourself in the foot compared to other solutions.
I would only reconsider if I were to hear more success stories and prominent figures that endorse the product and more good resources to explain best practices and use cases of the product. Just still seems a bit too messy at the moment.
MongoDB would be ok if you're starting from scratch with a very small team and want to gradually build your product (specification is in flux) along with continually learning, optimizing and monitoring your database (something one should probably be doing anyway). It also might be good if your system has little need for consistency and you can afford nesting documents and data duplication. For any other use case, like a big team with defined complex specifications or a high need for consistency, you will probably end up with a mess.