Why MongoDB ?
MongoDB is a NOSQL database. That being said "NOSQL" isn't really descriptive, as well as saying that MongoDB is not an "RDBMS". In fact a lot of "NOSQL" databases have ways to use SQL to query them, MongoDB included. For the Relational Database Management System acronym, though the well-known SQL databases are so-called because of relational algebra, it doesn't mean that relationships only exist in those databases. Most of NOSQL databases store and use relationships, MongoDB does. I've witnessed a lot of confusion because of this too broad naming, and it shouldn't be stopping you from using MongoDB.
Use cases in short:
- Web / Mobile applications
- Early stage products, MVP, hackaton
- Work involving creative people
- Time series
- AWS / Azure / GCP
A document store
JSON document databases perform well with applications where it simply serve to persist the JSON objects used. It allows for the same format to be shared through front-end, back-end, database. Typically, for an SPA using a JSON store in the front-end with a data sync when available MongoDB will shine. This choice of JSON from the ground-up makes MongoDB better by design than any non document database provided support for JSON.
Schema free documents improve a team ability to change its data model at any point. It gives you an edge to find product market fit or get a better MVP faster. It doesn't mean that MongoDB can't have schema validation. Most of the time data validation exists at the application level (ex: form validation) independently of the database. You have then the flexibility to dismiss database level validation to get a performance increase on write operations. This strategy is valid for a lot of products where users interact with data exclusively through an app containing all the validation logic. If you have to secure direct access to the database for data creation / update MongoDB provides JSON schema validation.
Each field doesn't have to be in every document of a collection. By configuring data access objects getters and setters (or whatever object / function used to access / set / edit your data) to enable them to handle the presence / absence of each field you can keep your schema continuously evolving while your app stays stable. If you develop your front to handle the available data you can then keep multiple versions of the data model working concurrently. Free schema sets you up to get more value from feedback loops or a front first workflow adoption.
In the specific context of working with creative people or experimental products strict schema constraints can quickly become an obstacle. You will always find yourself having to integrate new ideas / features into your project. The cadence of new feature development is harder to sustain when you're constantly making schema migrations. Picking a document database like MongoDB reduces your time to market.
Optimal JSON document schema design often requires to embed data instead of linking it through the equivalent of a foreign key. Join like query are to be avoided. This pattern makes for faster reads and is viable because the amount of related data rarely grows without limit. Most of the time relationships number is capped either naturally or to respect business constraints. Still, MongoDB represents unlimited relationships with references and all relationships can be stored. However, if you find yourself expecting many relationships to grow indefinitely MongoDB is not your best pick. Embedding implies data duplication sometimes. Consequently, document data tends to grow faster on storage than SQL databases and updates may require you to write in multiple locations.
Embedding leads to a variety of schema designs. Depending on your domain you should look for the schema design patterns that JSON documents offer you. As an example you can perfectly create a performant MongoDB schema for time series. Instead of adding complexity with another specialized database you gain the advantage of sticking with a general purpose one.
Atlas is the dbaas of the MongoDB company. It has auto-scaling if needed. It’s the way of using MongoDB as a service intended by the company behind MongoDB. MongoDB license is not an open source one anymore so that MongoDB can’t be provided as a service by any cloud provider. Atlas locks you on big tech clouds but you can choose between all of them: Amazon, Azure, GCP. You can move your data from one to another. If it’s a project requirement that’s a way to implement it. Both Amazon and Azure provides a document database with a MongoDB compatible api, respectively DocumentDB and Cosmos DB. GCP has Firebase as a JSON document database. All three provides the same advantages that MongoDB brings to your project and also have specific functionalities. If you’re planning to run on one of the tech giants cloud you should compare between MongoDB and your cloud of choice alternative to see which one is the best for your project.
MongoDB has all the strength of a modern database in the sense that the team behind is aware of current application workflows, hardware and frameworks and is providing a strong dbaas offer. MongoDB direction is more and more to become a Firebase alternative with the addition of the backend as a service Stitch and the mobile app database Realm.