MongoDB Reviews

We use MongoDB for the applications. You can save two or three applications but there's a lot of people using those applications. 

MongoDB is cool. There is a difference between relational databases and newer databases like MongoDB. MongoDB is scalable and fast.

It could be much more flexible like SequoiaDB. I would like to see more flexibility in the next release, especially when working with Microsoft Windows. A lot of people struggle with MongoDB because of their Windows versions. But Linux is faultless and mostly runs nicely.

I have been using MongoDB for about five years.

MongoDB is a stable solution.

MongoDB is a scalable solution.

Customer service depends on your subscription. Suppose it's open-source, then hard luck because you won't get any support. But if you are paying for it, you can get some tech support. However, MongoDB's open-source community is also quite helpful. I'm satisfied with it.

The initial setup is straightforward. 

We implemented this solution by ourselves. One engineer is enough to deploy and maintain this solution.

You only have to pay for the paid version, not the open-source version.

I'll recommend MongoDB to potential users any day.

On a scale from one to ten, I would give MongoDB a nine.

I use MongoDB mainly on the back end. We use it in my company for the database, and I also use it on my side projects.

MongoDB is a NoSQL tool that gives us much freedom to manipulate how the data works.

MongoDB should support TypeScript.

I have been using MongoDB for about two years.

I haven't had any issues with the solution's stability. However, our company faced an issue where the tool was down for two hours.

I rate the solution’s stability an eight out of ten.

MongoDB is a very scalable solution. About 10,000 users are using the solution in our organization.

I would recommend the solution to other users because it's scalable and easy to learn. The solution's documentation can be rigid and hard to understand initially. Users should use an ORM or ODM. They should use Prisma or Mongoose as the starting point for using MongoDB. MongoDB is easier to manipulate. The easier the onboarding, the harder the maintenance.

Overall, I rate the solution an eight out of ten.

We use this solution for database verification purposes. Typically, we integrate other analytics tools with the solution, like databases and other tools.

The Dynamic Application is a valuable feature.

The analytics needs improvement.

I have been using MongoDB for a couple of years. 

Hundreds of users use the solution at present. 

The initial setup is straightforward.

Overall, I would rate the solution an eight out of ten. 

I primarily use MongoDB for personal projects or minor stuff that I have developed for people who are starting. I'm currently doing testing on MongoDB for new features we're developing at my company.

It's super easy to develop a couple of solutions for clients with MongoDB, like a quick web page with no clear data structure that they need to spin up quickly to validate some sort of MDTP.

The MongoDB documentation can be a little complicated sometimes.

I have used MongoDB for three or four years. 

MongoDB is solidly stable. 

I rate MongoDB nine out of 10 for scalability.

I rate MongoDB support nine out of 10. It's pretty good.

Positive

Setting up MongoDB is super easy.

I rate MongoDB nine out of 10. I recommend reading up on NoSQL in general to learn the best practices. 

We use it as a data warehouse, and we also use it for software development when we are not sure how much and what kind of data we would get from the customers. For a short span of time, we also use it for the data lake to dump the data of a temporary instance so that the developers on the next node can leverage this data.

I like the schemaless architecture that it follows. I also like the sharding that it provides.

Its security features can be better. Sometimes, my higher authority says that we are not going to use MongoDB because it doesn't provide that much security for the RDBMS or relational data that we use for transactions. Instead of MongoDB, we will use Oracle Database because for a transactional service, you have to rely on RDBMS ACID properties.

I would love to work on MongoDB by using my mobile phone. When I am working remotely or traveling and have some instances deployed on my server, I should be able to check through my mobile whether all the data is being pulled. GitHub has a similar feature, where it lets you read from the laptop, and you can also pull and push with your mobile phone. I would request MongoDB to provide such a feature. Basically, I want a mobile version for both iOS and Android versions.

I have been using this solution for two years.

It is stable.

Currently, we have about 1,000 to 5,000 employees all over India. Most of us are using MongoDB for internal projects. 

When I was getting trained in the data engineering field, there was a saying that if we run after the technical support, we won't be able to see a bug in our own code. Since then, our superiors or colleagues don't suggest going for technical support. If anything goes wrong, we just troubleshoot it on our own, and we have done that successfully.

When we provide solutions for a customer, we look at the domain in which we are working, and accordingly, we recommend or select a database. It is up to the customers which database they want to use and how they are going to use it and leverage the subscription of that database. Do they want Oracle, MySQL, or SQL Server? Based on their preferences, we select the database.

For people or businesses that are currently trying to put their feet in the industry, it is a good thing to start their career with MongoDB. Sometimes, you don't have the knowledge of SQL and how to put a query to get a result. In MongoDB, there are certain things that make it different from other solutions. It is schemaless, and you don't have to have the knowledge of schemas. It is a good way to go ahead.

I would rate MongoDB a nine out of ten.

I have done a variety of things with MongoDB that started with the adoption of this solution at one company. I was involved in setting up the cluster and then the monitoring, alerting, and backup process. Once all of the set up was complete, I was involved in writing some of the components that were responsible for fetching data from MongoDB.

We are now responsible for running the platform, so whoever wants to run MongoDB comes to us and we explain how we can deploy the cluster for their applications. At this point, we build a cluster in the servers under a UNIX account. The number of nodes in the cluster depends on the requirements of the application side.

Some of the use cases we have configured MongoDB for are desk-tooling and a payment card profiling project. We are currently working on a data exchange platform. We also have a couple of use cases in the pipeline for potential MongoDB clients who also need the MongoDB Ops Manager.

The most valuable feature is that we don't need a schema to store the data.

The security is very good. Cybersecurity, authentication, authorization, and server certifications are all valuable features. We can define security rules at the database level or the cluster level to grant or deny access to particular users.

This is a highly available architecture. If you are using a three-node cluster and one of these goes down then either of the secondary nodes will become a priority to eliminate downtime from the application's perspective.

The documentation for MongoDB is not very good and should be improved. Some of the documents are referring to legacy versions. MongoDB 4.2 has been released, but there are training documents and other documentation that still refers to versions 3.6 and 3.4, which is not good. They should definitely update the documentation as new software is released.

Data encryption is possible using third-party tools but they should have their own encryption capability built-in to this solution.

Information about upcoming and recently released features should be made available so that we are aware of the latest features, and how we can manage the issues that will accompany them.

I have been working with MongoDB for the last three years.

We have not had any issues with stability.

We have a support portal where we can log tickets and fix issues. We contact them directly and we can set up a call whenever we need help from them.

For some issues, I would rate technical support a nine out of ten, or a ten out of ten. However, at other times, I would rate them a seven out of ten. It depends on who is dealing with the ticket. There are times where they respond to tickets very quickly and things get resolved in a timely manner. At other times, it takes ages to resolve the problem.

We did not use a different NoSQL solution prior to MongoDB.

We continue to use Microsoft SQL Server for other types of database implementations that require SQL, which I also have expertise in.

The initial setup is not very complex. We used the MongoDB resources to understand how to set it up on a Linux server, and after that, we prepared our own document that explains how to install it. Now it is quite straightforward, although if you are going with a more granular level of configuration, such as enabling other parameters on the cluster, then it would be different. I would say that set up would be a little more difficult, but not much. It's very simple using the MongoDB Ops Manager.

We offer three types of services on the MongoDB platform. First is the ODS service, second is the MongoDB SQL, and third is MongoDB standalone. For standalone, we are providing services on the tenant. With respect to shared services, we have the infrastructure but we have to set up their database on the shared servers. This will be useful for some use cases. The standalone configuration takes approximately 15 to 20 days to set up. It is sometimes less but it takes the time to create and configure the UNIX account because we have a third-party dependency for that.

The ODS solution will be better for enterprise data such as those involving payments, accounts, and customers. 

MongoDB is a solution that I can recommend because we have realized good benefits from it. We are in the process of setting up the ODS project, which should help the organization from a cost perspective. Then we will be moving the mainframe data to ODS, and we can use the MongoDB API to fetch data from there and provide real-time solutions to the customer.

At this time, I cannot judge the benefit of MongoDB in isolation, but as time goes on, perhaps by the end of the year, I will have a better idea.

I would rate this solution an eight out of ten.

Sharding is an excellent feature of MongoDB. Atlas is an awesome feature of MongoDB that makes life easy.

People coming from RDBMS should have the flexibility to write queries in SQL that can be converted into JSON queries. This feature is working, but we can still achieve some integration and make it more flexible. It is not as easy as writing direct queries on Atlas. This feature will definitely increase a lot of users. RDBMS users think this is a different query language, MQL, which is uncomfortable for them.

I have been using MongoDB version 6.0 for more than 12 years as a customer.

MongoDB is a very stable solution. The solution is a leader, according to the Gartner report.

In our company, around 2000 to 3000 people are using the solution.

MongoDB’s technical support is awesome.

Positive

We previously used the RDBMS solution, MySQL.

MongoDB has five to ten times better performance than MySQL. MongoDB has a lot of advantages. With MongoDB, you can store any kind of data, including structured, unstructured, and semi-structured data. MongoDB has a lot of benefits over RDBMS.

It is very easy to deploy MongoDB. If it is deployed on-premises, it takes an hour. It does not need any additional prerequisites or configuration details.

We have seen a lot of ROI with MongoDB because it gives five to ten times better performance.

MongoDB's pricing is not reasonable, but it is not as expensive as the others.

The solution's pricing depends on the deal, which includes how long you will use it and the number of deployments. They do not have a fixed cost. However, the maintenance and support cost is included.

I am satisfied with the product.

Our organization has a DBA team of 50 people. However, the work for the DBAs is minimal because MongoDB intends to have zero DBA. They want to develop a product where the need for DBAs is minimized.

Users should approach MongoDB with an open mind, without thinking that it's a different technology altogether and has a different language. Users don't need to develop the application based on a schema. They can develop the application, and the schema will follow.

Overall, I rate MongoDB an eight out of ten.

If we don't have relational data we use MongoDB. It is in JSON format, and we can use JSON. Therefore, without relational data, without type coupling with columns, we can use MongoDB. We use it for queries.

The most important aspect is the clustering part. If you have read/write databases, then MongoDB will be easy to use. You can split those databases. We can save the data into JSON without relational data. 

It is very fast - faster than an SQL or MySQL Server.

Therefore, if you have unstructured data, you should go with MongoDB.

I work with Kafka. Kafka is sending a lot of data - millions of records in seconds. It is not easy to just pass it into the SQL Server. Instead, we are sending those drivers to the MongoDB Server, the MongoDB database. it is very fast

You can manage very fast queries with MongoDB in JSON format. 

The clustering is great. You can have multiple clusters in MongoDB.

It is scalable. Technical support is helpful. 

We'd like to have access to foreign keys.

Sometimes we need to be able to delete unintended data from the end user, and we'd like to have that capability.

The solution is a bit expensive.

There can be stability issues. 

I've been using the solution for three years. 

Sometimes you have multiple requests at the same time and there are thousands of millions of data points. There may be performance issues in that case. Sometimes it is stable and sometimes it is not. 

The solution can handle multiple clusters, so the scaling is fine. Sometimes scaling is not required if you have multiple read databases.

I also use AKS and you can use AKS functionality to scale MongoDB services. 

Technical support is okay.

Neutral

We have it deployed on the cloud with a container. 

It is not a complex setup. It is easy to use. You just compose a file and deploy it from there. 

We have one DevOps team that can handle deployment tasks there are three to five people on it.

We have not witnessed an ROI.

The pricing is okay. It's a bit expensive. I'd rate it eight out of ten in terms of affordability. 

We're using something around version three. 

Overall, I'd rate the solution nine out of ten.