MongoDB Reviews

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.

It depends on what your project is. If you're doing some crazy data analytics where it might be useful to have a giant pool of relatively unstructured data that needs to be piplined into some kind of visualization, then MongoDB might be a good idea. If you want to create a database with structure and a well-defined schema, well, then you need to look elsewhere.

We can store a large volume of data that have no structures. We can develop and release quickly.

If you are a small development company or don't have access to experienced DBA folks, MongoDB can be a good choice for the developer to take the data by the horns.
MongoDB is easy to handle when it comes to migrations because of its schemaless nature.
It can help you get to market faster because you're not spending a ton of time with dev ops and organizing data structures. You can iterate pretty easily. I would say it's a good choice for most web apps, but you might run into restrictions on certain data queries that MongoDB just can't do as efficiently as a relational database.
It can also be hard for some folks coming from a relational data model background. The idea of denormalized or redundant data can feel dirty to some. But the speed and performance in development and execution appear to make up for those faults.

If we want to avoid complex schema this tool is best as we do not need to create databases schemas. This tool also reduces the overall reads performance ad it works with replica sets.

For most every basic web app that I have developed, MongoDB is well suited. I find it hard to imagine scenarios where it would not be...For apps where we have dynamic, user-controlled attributes, MongoDB makes this really easy. I would imagine MongoDB might be least appropriate for teams not interested in trying to learn a NoSQL approach. Try a skunkworks project then...

For databases that involve storage by document folders, MongoDB is ideal. Now, if a very large database is required, MongoDB can have problems because it is more complicated to call the data to avoid having to spend hours looking for them.

From my point of view when it uses joins then it can be used anywhere by anyone. We know it's built for clustering which means data is spread over multiple independent servers. If you need to load high amounts of data with a low business value then MongoDB is fine.

If you just need a key-value pair you can use Redis. But, in my opinion, MongoDB can do it all today and will blow your mind in the future.

If you have a dataset that is not always consistent, consider storing it in MongoDB. If your data is normalized, it may not be the best solution.

Not everything is suited to a NoSQL database - but where it is, I would 100% recommend MongoDB where it is suited to the use case.

• unstructured / schemaless data
• large datasets that benefit from partitioning right 'out of the box'
• devops culture
• high availability environments that benefit from HA and DR right 'out of the box'

And recommend an RDBMS in other cases.

• highly structured data
• able to be normalized
• strong relationships exist between entities
• static, slow growth, small datasets