MongoDB Enterprise Advanced Reviews

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. 

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.

We use MongoDB for monthly billing of the mobile software we provide to our client, Talent Post. It includes the services they use on their mobile devices.

One of the biggest benefits is the speed and flexibility of the documents, especially when it comes to modifications. It has definitely helped us to function more efficiently.

The best advantage of MongoDB is the flexibility and scalability of the database.

There is a need for improvement in MongoDB's customer support, better support would be great. 

Another feature that I haven't discovered yet but would be useful is a backup and restore process that can handle large database sizes. Right now, I have over three terabytes of data, including logs, which takes a lot of time for snapshot backups.

I started using MongoDB a couple of months ago.

The overall performance is faster than a relational database like SQL. But, the equation function in MongoDB is not as clever as the stored procedure in SQL. It's more complex to write the functionality like a stored procedure in MongoDB.

I would rate the performance of MongoDB a five out of ten.

I would rate the scalability an eight out of ten. I have around 2500 branches of users that use MongoDB simultaneously. We plan on increasing the usage.

I would rate the initial setup a six, where one is for easy and ten is for complex. It is a little complex. It's more complex when we think about deploying MongoDB with the shopping feature. But setting up MongoDB without consideration of shopping would be easy.

The deployment would take a day, but that includes testing. We didn't use any third parties. We deployed the solution ourselves.

I would rate pricing a seven out of ten. It is a bit costly.

I would definitely recommend using the solution.

Overall, I would give it a seven out of ten. The reason is the flexibility it offers, especially for deploying solutions for mobile services. Additionally, it's still considered a new technology in our country, so it's quite trendy.

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. 

Migrating to MongoDB upgrades the IT environment and puts users in the NoSQL environment, which is faster.

There are some problems with bugs appearing in sharding when the data is too high. MongoDB also needs to update and be more flexible to match up to more mature products like Oracle or SQL.

I've been using MongoDB for three years.

MongoDB is stable and reliable.

MongoDB is scalable.

MongoDB's technical support is quite good.

Previously, I used AWS DocumentDB and DynamoDB.

The initial setup was straightforward, and deployment took around two hours.

We did the implementation ourselves.

MongoDB is a bit expensive compared to its competitors.

I would advise anyone thinking of implementing MongoDB to test the sharding and duplication concepts in your environment with a huge number of data to see how it will work with multiple scenarios or test cases. I would give MongoDB a rating of ten out of ten.

Our primary use case has been for maintaining video content and varying it. We are an enterprise-level organization with around 500,000 employees internationally. The company has over 10,000 users of this solution. I'm an integration solution architect. 

The solution is user-friendly with a good object retrieval feature. There are no joins, queries are fast and the product provides helpful drivers. I like the abstraction layers. 

I'd like to see improved scalability and elasticity. Also, the software should have certified container images so it can readily be used in production.

I've been using this solution for two years. 

The solution is stable. 

More could be done to improve the scalability.

Customer support is at a reasonable level. 

The initial setup was pretty simple. It's a good product for academics since it's an open-source solution so it's readily accessible with fast onboarding. Deployment was carried out in-house. There is no maintenance required.

I rate this solution seven out of 10. 

We do payroll for government workers. One service we provide is called e-Payslip. You go into the portal, create an account, and download your payslip for the month. If you have to do something that requires you to submit a payslip, you can go to the portal and get your payslip electronically. 

We also have what we call the ESPV. This allows unit managers to validate workers before they are paid for the month. It's an attempt to remove ghost names from the government payroll, so there's a cycle. At some point, somebody who is actually working must be validated in the system, and then the unit head confirms. This is checked by HR before salaries are paid, so you have to be a validated worker before your salary is paid. 

I think that MongoDB isn't too structured, and that's good for our technical team because they are able to search through the database better than if they are using SQL Server.

I feel that most people don't know a lot about MongoDB, so maybe they could add some more documentation and tutorials. In general, I think they should do more to publicize the solution because when I'm in a meeting and I start talking about migrating to MongoDB, people don't know what I'm talking about.

I've worked with MongoDB for maybe two years. In fact, we recently upgraded and moved everything from SQL Server to Postgres and MongoDB. We went live just about a month ago. This was supposed to be the solution to all our problems, and we are in the process of testing to confirm that we are fine. 

MongoDB is stable. 

We mostly used Microsoft databases in the past. We started with Access and Microsoft SQL Server. I've also used Innovation together with SQL Server.

I'll give MongoDB a 10 out of 10. We are getting positive feedback, so far.

Our primary use case of MongoDB was development. We used it from a developer point of view, writing the platforms and storing some data. It was deployed on the AWS cloud. 

One of the first things I noticed when I had my first experience with MongoDB was how easy it was to use. I was expecting more difficulties or at least some challenges, but it was very, very easy to use. It's great technology, performs well, and is very convenient. 

MongoDB is a very useful and convenient choice, but sometimes for more complex projects, there are certain niche requirements that appear, so using a different tool could be beneficial. It raises the complexity of the architecture, but it could be beneficial to the world, the features, the ease of the features which are being implemented. 

My experience with MongoDB is pretty recent, maybe for three years. 

This solution is stable enough. There isn't much maintenance involved—we're just installing some software and then using it—especially since I'm using it from a development point of view. 

I've heard that MongoDB is pretty scalable, but we never did any big deployment. I've read a lot about how it scales and can handle huge data. 

I have never contacted MongoDB's technical support. 

The installation is quite straightforward. I have it installed on my personal laptop and it's very easy to do. It took just a few minutes. 

There are two or three DevOps guys who are involved with and responsible for all the deployments and setups for the whole project. 

I implemented this solution myself. 

We also considered Cosmos DB. 

I rate MongoDB a nine out of ten. If I put it this way: "Can I trust this technology to perform well in a complex project?," I can certainly trust MongoDB. I have been working with some graph databases as well, and MongoDB was my first touch with noSQL technology. I think I like it even more now, after these experiences I had. 

I use MongoDB from a development point of view. For some projects, we use Docker on local environments. MongoDB actually starts in some Docker microservices where we don't run the whole platform, we're actually running locally or maybe part of the platform. With this container, we don't need to do many things with the image in Docker, we're just developing the platform. And then the deployment and scale are managed by the DevOps guys, who do their magic. We use Azure in some projects, but we mostly use AWS.