MongoDB Reviews

MongoDB is an excellent tool to start development fast on a smaller POC, or, to serve as a backend for storing raw json-based data as well. It can be used for emulating a relational database but its core strength is storing the redundant, non-BCNF data, and querying it. So if we have any of those, MongoDB can serve as the DB with a really fast initialization in the development process - but just as well as in production.

Scenarios where MongoDB is well suited:
- When working with small/medium-sized dataset where speed and flexibility are priorities.
- When working with schema-less or polymorphic models that would be much harder to represent in a traditional RDBMS.
- More generally MongoDB makes sense as a place you'd store your business logic/frequently accessed data, not as storage for infrequently accessed long-term storage.

Scenarios where MongoDB is less appropriate:
- I wouldn't recommend using MongoDB as a caching service. It's more expensive than many databases that could be used where performance isn't a critical issue or long-term persistence is desired (e.g., compared with Datastore/Firestore/Dynamo/etc.), while it falls short of Redis when performance is critical or data need not be stored for long.

Modern web and mobile applications developed entirely in Javascript ( Node.js, Angular, or Vuejs or Emberjs.) are particularly interested in using MongoDB as a database. It is very easy to develop an API to manage the database accesses in an optimal, fast and secure way.
Loopback.js is a good starting point to get an idea of the potential of this environment.

I believe any startup or any business with a rapidly changing data schema would benefit from using a no-SQL database in general. Analytical and traditional reporting can be difficult to do out of MongoDB or any no-SQL database because the SQL capacity is pretty limited.

The tool is very easy to set up and start developing right away. I found it extremely simple to start utilizing in a short period of time. Mongo is more suited for people not concerned with back end logic as there is no joining like in a typical relational database scenario. However that could cause disruption to the people used to seeing relational databases.

MongoDB is very flexible, and high performing. I have evaluated a number of NoSQL databases and have found MongoDB to be the best overall. Aggregation pipelines took a little bit of practice to learn but once I got the hang of it, I realized how they could be used to solve problems easily.

So if you need a highly available database, which you can rely on since it has inbuilt replication and JSON format message, then MongoDB is the best way to go for it. It follows BASE if the databases are inconsistent if you are scaling over a large system. What it means is that it is not suitable for storing passwords. For that, make sure that you use ACID databases which are relational.

Depends on the use case, MongoDB may or may not be the best solution. It is not the silver bullet that is going to solve all the database problems. If the use case does require transactions (e.g., financial) or is highly relational, then you would be better off going with the traditional SQL databases such as PostgreSQL. However, if you do not need those, and your requirements lean more towards storing unstructured data, or if your data fits its document-based approach, then MongoDB is a great solution.

While we don't and wouldn't use it for transactional data, it's an excellent tool for collecting big unstructured data.

This is a good tool in its category for reading real-time unstructured data. As my team works on understanding the sentiments of users over some products, initially we used SAS Text Miner but we were not getting those desired results as it was unable to process the real-time data.

The only major problem is that it is incapable of performing statistical analysis.

MongoDB using JSON like documents in a database system. Also, it's an open source software. Its very flexible compared with other database related software. It helps to store a very large amount of data perfectly. It provides high performance, availability, and scalability. It's a NoSql database.

But the main disadvantage of this product is we can't use it for transaction functionalities.

MongoDB supports JSON Schema data with the most complete NoSQL query framework among all NoSQL databases. The shard cluster is well designed for large applications with multiple concurrent users. It is best suited for applications that store data mostly for reading and reporting. But it will be improved towards applications with more write operations as well in future when transaction are supported on shard cluster (expected in version 4.2).

Mongo DB is better placed in large projects, with great scalability. It also allows you to work quite comfortably with projects based on programming languages such as javascript angular typescript C #. I believe that its performance is much better with the type of technologies that handle very logical, similar terms of programming. If we use languages like java php, for example, it is better to work with relational databases like postgres or mySql. Since this type of technology allows you to work better with database management frameworks much more agile for these environments, such as JPA, HIBERNATE, Oracle, I think they are much better with this type of architecture and programming languages.

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.

MongoDB is very much well suited if you are storing raw data. Also, it can be easily integrated into the Hadoop big data ecosystem, so it is useful if you have a large amount of data. Scalability is another amazing feature of this database system. But MongoDB will not perform well if you have a use case where you have to update your data very frequently. In case of frequent updates, Cassandra will be a better option.

If you need a database that can store and handle unstructured data very easily and that is performant, MongoDB is a great solution. It is very easy to set up and has a large community of users. Mongo can integrate with all of the major languages (ie: Java, Python, etc.). If you need to store very complex, structured data that needs to be related, a traditional relational DB might be a better option.

It is very easy to get started using MongoDB, and getting a data schema created via Mongoose if using Node.JS is pretty simple as well. For small beginner projects, something like Firebase may be easier to get running and simpler to deal with for reads/writes, but for more advanced control and a more structured approach, MongoDB is a great solution.

MongoDB is an excellent option for small / medium projects where relationships are not very important. When you have a lot of table relations, it is better to use a relational database.

This really comes down to need. I would have to look at the specific use case and decide if Mongo would be a good recommendation. Mongo does a lot of things really well, is easy to work with, and has fantastic documentation. However if transactions for example were a requirement within you application I wouldn't be able to recommend Mongo.

This product is well suited if your need is to use a fast distributed DB with semi structured data and your semantics are not well predefined. It's also useful for building apps requiring real-time responses and fast deployment with ease of maintenance.
I wouldn't recommend you use it for any scenarios where it's beneficial to normalize the data.

I think that MongoDB is the easiest and fastest database solution when starting any new project. Unless the project has a clear need for a relational setup from the beginning, it just feels a lot easier and faster to work with MongoDB. Scenarios where it's less appropriate would mostly be those that need the features of a relational (ex: SQL) database. Even then, we like to use MongoDB as a primary database and use SQL only for the aspects of the application that are better suited to it.

If you have a large amount of unstructured data, (like NoSQL), to be read or written in a short amount of time, MongoDB is a great choice for this. Its structure well secures the data from being lost. It has good scalability to handle an increasing amount of data. It has a well-supported team to help you set up and maintain the cluster. Overall, it is a good choice to use for a NoSQL database.

In case if you have less budget, go for this tool as it's free. Also, if you want to work with JSON Schema or file system, I will recommend this tool. In case budget is not concern, I will recommend SQL server or OracleDB.

Amongst situations where the data being modeled is not well structured, using a NoSQL database — and using MongoDB in particular — may be a great choice. While Mongo *does* let you get away with less structure, you must be aware that less structure is not always the correct development avenue to take. Not having to manage a database schema does not necessarily make your development speed any faster.

MongoDB is a well developed, commercialized product. There are other products which can be good choices, but MongoDB is a safe choice since it was already validated in the market by many customers. Which means, for any general purpose, it will fit in to some extent. In our project, the problem was extensibility to larger scaled genomics information that may require big data management functions. MongoDB is excellent when it is for a small project, but it is also well supported as the project and size of data to be managed grow.