MongoDB Enterprise Advanced Reviews

We use it for big projects. We have multiple DBs on multiple servers, so we have a good performance for it. Sometimes, we are using cloud systems, like Azure, or VMs.

We are using MongoDB like a warehouse for data that has no relation nor a need to scale.

• The document space is the main feature of it. 
• It has good performance.
• The community is great if you have problem.

You need integration with other tools to run the query in MongoDB.

I have been using this solution for two to three years. I have worked with it on multiple projects.

I did have some issues with putting up the server.

I have not used the technical support. If I get stuck, I search for the answers and will luckily find them.

I recommend the solution for my current company. They have used MongoDB for two projects now. We chose MongoDB because of its community.

The initial setup was easy, not complex.

We used consultants for the deployment. The initial deployment took 20 minutes to half an hour. It didn't take long, as it is very simple.

When you compare MongoDB to other DBs like the SQLOne, they are all the same system, in terms of performance. 

I did a benchmark between SQLBase and MongoDB. The performance and some queries in SQLBase are much better.

I would rate the rate the solution as a seven (out of 10).

We used MongoDB to implement a healthcare application into the Amazon Cloud. We deployed that architecture within the South African public health care sector.

One feature that we found most valuable is that it is completely open source - this was majorly important. Because we worked for a nongovernmental organization we had to work with only open source tools. So that was a big selling point for MongoDB. We also needed a document-based DB to build this FHIR application on top of, MongoDB offers. 

Another major selling point was that they're massively scalable. The fact that unlike relational databases, MongoDB allows a lot more scalability and it was more suited for the type of data that we were storing, which was semi-structured healthcare data. It provided very nicely for the standards that we were working - FHIR - which could be interfaced with JSON and Mongo. It had very good JSON capability and storage. Overall, it was a combination of what we were trying to store and the scalability in terms of being able to store a lot of this information over time.

We were quite happy with the product and the actual use of it. We had no particular problem.

In the future, if they could look into supporting FHIR better. FHIR is a healthcare standard. I don't know what that would mean, but, we had to implement a layer on top of it that implements FHIR. But if MongoDB can look into implementing that would be useful.

The two things that were very important for us were basically performance and compatibility.

I have been using this product for about a year.

It is very stable.

We had issues. It wasn't operationalized yet, but our feeling was that it was easy to set up and easy to operate and very stable. So I would say our compatibility and performance are the two things that came up that I know in the project we had problems with. The rest wasn't at any point an issue.

It's massively scalable. It is very scalable in terms of being able to store a lot of this information over time.

In terms of how many users are using this solution, it was a large database with many objects being pumped into it. But, for our purposes, it was just not necessarily the number of users, but the amount of automation being integrated

It was used by the Provincial department of health, or country. So it was basically the nine provinces in South Africa. And each of them had it. It was all the HIV and TB data for all the departments of health in South Africa. It was big.

I can't recall any issues that our technical team ever had. My feeling was that they were satisfied.

The initial setup was very straightforward. It was a pleasure to work with, for everyone. So setting it up, getting up and running, pumping data into it, and actually looking and querying the data was super simple. We were up and running within an hour. We could literally install and start ingesting information into it from the word go. It was very simple to set up and to have tools to actually query and pump objects into it.

We implemented ourselves.

I would definitely recommend MongoDB. I'm hoping MongoDB will continue to be developed from strength to strength because I think it's an awesome tool. I hope that other products, like DocumentDB, will find a way to work with MongoDB to improve the overall stability of the product. It would be good if other services that host Mongo would become more readily available. It was very useful to actually have a hosted MongoDB set up that is maintained by Mongo Atlas.

I would rate it 9 out of 10 because we had very little issues and it did exactly what we wanted it to do.

MongoDB Atlas was the deployment mechanism we went with and that was hugely helpful for us. MongoDB Atlas is part of the MongoDB suite, I think. It's just a deployment of the Mongo. We also deployed it on Amazon using DocumentDB, but we found that MongoDB Atlas worked better in the end.

We use MongoDB to enable streaming. We have a structured DB where everything is secure. We have everything in folders and structured data. MongoDB is much more better in terms of their response time.

It's easy to add and remove things in MongoDB. You can alter the tables. MongoDB is faster at reading, slower at writings.

The transaction could use improvement. From MySQL, for example, you cannot create a transaction if you are reading and writing a document at the same time.

Relations in MongoDB is another issue. Trying to make a relation such as a connection or using the OIE can be very slow. It's not a fault, though, because it's not a positional database, so it isn't supposed to use it for relation.

It's stable. You can create sets which could be three servers, some reading and some writing, for example. This way if some servers go down the others are still up.

This solution is scalable.

There's no technical support in the server source.

MongoDB is more secure than similar databases. You can pass documents from there. You can add large data in the same record. It works with PostgreSQL and the like, and it is a structural database.

It was pretty easy to set up if you are using Linux servers. It only took a few minutes to deploy, since you don't have to create anything.

It only takes one person for maintenance and deployment.

My advice is not to use Relationships in MongoDB. MongoDB is not a relational database, so don't try to use Relationships in MongoDB.

I would rate MongoDB as eight out of ten.

Our primary use case of this solution is to directly monitor public services.

I like that this solution helps us to manage our allowed time on the release date or entry, but if you have a conventional application where you have to make a lot of queries with the joints, you have to mix the information of several tables. You cannot go to a non-relational database, you have to go to an Oracle or MariaDB or whatever. But if you have other queries like smaller tables with a lot of resistance, MongoDB will be okay.

MongoDB is very valuable for us due to the large amount of entries that we can install in the database. The solution makes it very easy for us to develop with these databases. It is also easy for development and to list all our entries in a single table. 

We find it difficult to incorporate MongoDB in some projects. It's also very complicated to join different tables. For example, MongoDB works very well with the note GS Java Script. But when you try to develop in Java, it is not so easy. So the integration is not very simple. 

My colleagues, however, reported that it's easy to manage the database. I also know that it is very easy to make an application in Java scripts. 

We haven't had any issues with stability since we started using this solution two years ago.

We're not currently using the alert implementation of MongoDB, but it's enough for us and we can escalate to put in more machines if we like. We are not using that many implementations.

We don't use the technical support because we have our own technical team that can help us.

We use MariaDB as the main product of the company, but we find it difficult to fine-tune the database and to increase our services. We also have problems with queries. So we implemented MongoDB with MariaDB because MariaDB doesn't have the same capabilities and now we can do some fine-tuning of the database. 

The initial setup was very easy and we did everything ourselves.

My advice to others would be not to use MongoDB for complex business applications or difficult queries. There are some integration issues that need to improve, so I will rate this solution an eight out of ten. Still, it is a very good product that is user-friendly and it works fast. 

I use it mainly for development. It's a plain document database that maps adjacent data structures. It doesn't cost us that much to integrate. It scales well and it's easy to replicate. It's very easy to set up and it's very easily monitored.

The solution is known for not requiring people to set a root password when you set it up, so it has leaked data, like a feed, and it's the first thing I need to teach everyone that sets the system up. There was a story out of China where there were 100 known users that were being monitored by the government and there was a MongoDB cluster. They forgot to set a root password so it was publicly available and that kinda happens over and over again so people need to at least supply some basic securities. 

Training would be very good, at least to get some basic production level set up. People need to figure it out because just setting one up is easy, but then you need to get a replica going and that's hard and then getting performers ready and that's even tougher and somewhere along the way people tend to forget about security. Every month some major company forgets to set the password.

More stable indexes would be helpful in a future release. That's been an issue for some time. I don't know if it's been fixed now but we transitioned to it because we needed a search index to be able to search for things and if that goes or starts disappearing, we have to move away from that solution. I don't know if they fixed it, last time I had this issue was three years ago so they might have solved it.

The solution is completely stable.

Scalability seems good. I've never been even close to finding the limits. I've run a couple of notes of redundancy but I've never had any problems with scalability.

I have never been in contact with the people who developed MongoDB. I've never bought any support from them or had any issues. When we've run into something like scalability or other issues, we've always managed to figure it out on our own. The community's also fairly strong so technical support isn't something we've needed.

I use Kubernetes. These are management tools where you can select which items you'd like to install first and you basically just provide what kind of features you want to be activated and how many nodes you want to be activated in the database. I would install it as part of a Kubernetes cluster and it's pretty straightforward because the chart, as its called, is managed by and used by thousands of people so I don't need to know exactly how to set up every single bit of it.

It's also all very automated, which makes it easy. In fact, I use it a lot in teaching as well because it's very easy to set up.

My first foray into MongoDB was actually when I started using a Google data store which is very similar. We ran into problems because we didn't have any search or solutions for it. We switched over to MongoDB because that had the basic search engines we needed so we can actually get some basic search going and be able to scale out. 

We didn't do a technology selection. We just had other technologies that didn't pan out so we gradually moved into MongoDB. 

The solution scales very well and is very easy to replicate.

If you need something done quickly and you need something that does scale fairly well I would suggest MongoDB. You can always transition away from it later on. It's always a solid first bet if you want a simpler kind of web page or web system. It's a very solid choice if you want to get up and running quickly. It's my go-to for all these little startups that I manage.

MongoDB seems to give just exactly what we need and I find most of my clients have never transitioned away from MongoDB.

I would rate the solution seven out of ten.

One of the key component of our system uses MongoDB as its data store. We use it for storing data sent by devices. It is an IoT platform.

We capture more than 30 million records every week in IoT NS. 

MongoDB has been serving us well so far. It is easier to maintain the data with its document-based storage.

• Its capability to do quick, powerful aggregations has caught my attention. 
• The search queries are pretty fast and mean time to get response is around 50-100/ms. 
• The installation is very stable.

Its indexing capabilities could be further improved. The libraries, e.g., Mongoose could still be improved to handle MongoDB. The improvements could be made to intelligence to detect disk storage and prevent MongoDB from crashing.

No stability issues.

No scalability issues.

The setup is pretty straightforward. Just install, create a user, and start using it. 

I felt it was quicker to use MongoDB compared to MySQL.

We implemented it in-house.

We did compare Cassandra against MongoDB, but we faced a few problems while data was restoring with Cassandra and chose MongoDB to avoid such issues.

• Reliability
• Enterprise integration
• Documentation
• Certification
• Support

It allows us to have an alternative solution to licensed DB's.

It requires enterprise integration improvements from the security, and audit perspective (AD integration etc.). Also, existing integration into BI tools is not present.

I've used it for five years.

MongoDB has a "heavy" architecture, which limits the scalability options.

They provide a high level of technical support.

We switched due to a common OS integration strategy.

We had an RFP process to evaluate between similar product categories.

We primarily use the solution for web applications.

In our company we decided to invest in the knowledge of an alternative technology to SQL. MongoDB seemed like an obvious choice together with other leading technologies.Furthermore, it is a product that can be intuitive to use unless you come from years of SQL

It has quite good web analytics. It is pretty stable. There is more in-depth management of the data.

It's a NoSQL/Document DB and has some peculiarity related to the data schema but it's also good as a general-purpose DB.

The replication works very well and is in the box. 

In clusters, there is the choice to have horizontal scaling, which improves performance on a huge amount of data.

The aggregation framework is very powerful when elaborating on data. 

It has good high availability.

It's an essential DB. 

It has very good performance for queries.

It is free to use if you choose the community version.

It is stable and reliable.

You can easily scale the solution.

It's quite a good DB that is very strong on a lot of features. 

It is a product that works very well. I don't see a lot of areas that need improvement. 

I've used the solution for five to six years. I've used it for a while now. 

I'd rate the stability nine or ten out of ten. There are no bugs or glitches. It doesn't crash or freeze.

I'd rate the scalability nine or ten out of ten. It allows for horizontal scaling, which is quite useful when dealing with big data.

We have about ten people using the solution at this time. One-third of the company ends up using the solution.

We may increase usage. It depends on the business needs. However, in Italy, I have noted MongoDB is expanding.

The technical support is very good but is available only for the enterprise version. 

When I've used other DBs I found them to be inferior.

We have used also Atlas (MongoDB solution for Cloud), and MongoDB has developed a useful framework with lots of new features that are not included in MongoDB's on-premise version. If you choose a cloud DB, it's great if you are looking for a lot of innovative features. 

Many clients use SQL DBs and many are moving over to MongoDB.

The initial setup was pretty straightforward to set up. Compared to other SQL DBs, SQL databases are very complex. MongoDB is ready to go, and you need less operational knowledge. 

I do not invest in MongoDB. However, many customers can save money by leveraging the MongoDB community version. 

The community version is free. The enterprise version is reasonable as MongoDB wants to expand and outpace also SQL DBs. 

I am not using the latest version of the solution. 

Do not think of this solution as a SQL database. Consider your use case and set it up accordingly.

I'd rate the solution ten out of ten. It's the best database on the market.