MongoDB Reviews

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. 

We are using MongoDB for storing user information and our customer data. If an application requires to save information, that data is stored in MongoDB.

MongoDB has helped my organization by being able to handle large amounts of data. Nowadays, if users are using our application all the data we store in our database. If you're trying to receive the information from the database, it's important we are able to retrieve the result as quickly as possible.

The most valuable feature of MongoDB is the NoSQL database. In a SQL database, we need to join data together with a unique ID amongst other things, but in MongoDB, it's not required. We can directly receive all the information. The performance is very good. Additionally, they have frequent updates.

I have been using MongoDB for approximately two years.

The stability of MongoDB is good.

MongoDB is scalable.

We have approximately seven backend developers using this solution.

The MongoDB community support is very good. I was facing some problems using some queries, so I posted my issue on that community channel, and within one day, I received a solution. The support was very quick.

I rate the support from MongoDB a four out of five.

I previously used MySQL and PostgreSQL, but I had permission and licensing issues with MySQL. I prefer MongoDB over others.

The initial setup of MongoDB is straightforward. We only had to use a few commands to install it.

There are different licenses available to be purchased, such as individual, premium, or enterprise.

I did evaluate other options before choosing MongoDB.

Only one person is required for the maintenance of the solution.

I recommend MongoDB to others.

I rate MongoDB a nine out of ten.

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. 

MongoDB is a document database that we use for internet applications, logs, and all kinds of things that need quick answers, especially in the document area.

I like that MongoDB has a free version. You can also buy the enterprise edition, which is cheaper than Oracle.

It could be more stable. It would be better if it were more user-friendly like Oracle, which is very easy. For example, creating an index is simple in Oracle. In MongoDB, it's quite challenging to do that.

Performance could be better. It's fast and good, but you cannot put every application that you would like to in MongoDB.

I've been using MongoDB for two or three years.

MongoDB isn't stable like Oracle, but it's okay.

MongoDB is a scalable solution. MongoDB has its own problems, but if you have good maintenance, it's okay. Since it's for internet applications, we can have tens of thousands or hundred thousand users.

There is no technical support since it's a community-supported database. If you would like to buy services like that, there are companies which sell that. But it's not like Microsoft or Oracle, where you have an option of buying support. Instead, there are third-party companies that are willing to provide support for a lot of money.

We switched from Oracle to MongoDB because of costs. Oracle also has a MongoDB solution inside it. In Oracle, you can install document databases, which helps, and it also supports JSON and just about everything. It's one-to-one. Whatever you do in MongoDB, you can do it in Oracle. But Oracle isn't free.

The main problem with Oracle today is the price. Many companies around the world are trying to move out of Oracle because of the cost. They are not moving because the database is not good. PostgreSQL is really like Oracle, and MongoDB is like Redis, and all these have free community databases. If you want to buy the enterprise edition, it costs a bit but not as much as Oracle.

The initial setup is straightforward. Even building the cluster and so on isn't a problem. But you have to know what to do because it's a bit different from relational databases. It only takes a couple of hours and not more than that. Once you have the right servers, firewalls, ports open, and so on, you're good to go.

One or two people are enough to maintain this database. But you'll need more people like programmers for the digital part of the application that you have to develop. 

I implemented this solution by myself.

MongoDB has a free version. You can also buy the enterprise edition, which is cheaper than Oracle.

I would recommend MongoDB to potential users depending on their requirements because it's not a relational database. It depends on what applications would they would like to put in it.

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

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.

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.

We do not use MongoDB extensively. Initially, we wanted to store login information, dumping the entire message into the database. It stores transaction details about the users, but only for login purposes. Essentially, we store information about access and usage.

In the future, we will build some reports for this data.

MongoDB is the best choice for us when we want to store NoSQL-type data.

The clustering is very good. It allows us to have high availability.

The performance is good. 

The user interface is not as friendly as Oracle, which is something that can be improved.

We have been working with MongoDB for a couple of years.

So far, MongoDB has been quite stable.

MongoDB is definitely scalable. By setting up a cluster, we are able to scale well.

At this point, we are only using it for login purposes and only with two or three applications.

We have not used technical support very much because we don't have any issues with it. It has been quite stable and also, we are only using it for a limited purpose at this point. 

We also use Oracle and we have found that if you want to have a DR site, you need to replicate the data from one site to the other. With MongoDB, we set up a cluster on the wide-area network, and we don't have to do any data replication. Instead, it will help you with these things.

With Oracle, the user interface makes it easy to explore the database. With MongoDB, the interface is quite primitive and it is more difficult to look at the data. It is not as user-friendly.

There are a lot of vendor and third-party tools that work on top of Oracle, but this is not so much the case with MongoDB.

I was not personally involved in the installation.

We have an in-house team for deployment and maintenance.

We did not evaluate other similar solutions before implementing MongoDB.

Prior to MongoDB, we focused on relational databases.

This is a good product and I recommend it for anybody who wants to store NoSQL data. It provides a lot of features and the clustering, in particular, is a good one.

I would rate this solution an eight out of ten.

We primarily use the solution for long-term storage. We use it to store all our data. We also use it to support microservices that already have calculated data. We don't use it for any other purpose.

The most valuable feature of the solution is the ability to easily store documentation regarding structures. 

We can easily connect to MongoDB and search without transformation, without joining. If we want to use a simple search it's really fast. 

The initial setup isn't really that complex.

The solution is pretty stable overall.

If we want to perform some joins or some other types of transformation that are more advanced, in that case, we cannot use MongoDB. We need to use another solution.

The solution needs to better support modern aspects of search engines. There is typically a microservice layer and MongoDB doesn't support well within search engines. If you want to create some complex structures, you need something like Elasticsearch, for example.

The pricing is expensive.

MongoDB should better support small and medium companies. There are a lot of clients out there that are interested, however, they need something lighter and less complex and something not so expensive upfront. 

I've been using the solution for the past two or three years.

The stability of the solution is very good. There are no bugs or glitches. It doesn't crash or freeze. It's pretty good overall.

I've never used technical support. I can't speak to their level of responsiveness or how knowledgeable they are.

We previously mostly used SQL databases. We used Microsoft SQL mostly and we needed some NoSQL databases. That's why we implemented Elasticsearch and MongoDB. We wanted a NoSQL database that we could search, however, was also capable of long-term storage. 

The initial setup is not so complex when we are talking about on-prem solutions. It's an easy initial setup. We are fine with that. 

I was surprised, however, by the lack of support offered during implementation. You are left to your own devices. There isn't much guidance - especially on so complex a transformation.

We have our own agent teams. Mostly we rely on our engineers, not consultants at other companies. We're able to handle everything rather well in-house.

The pricing is quite high and we don't appreciate the solution raising prices so much.

I'm following up with the licensing, however, I don't have the exact figures right now. I mostly advise some companies about that, and usually do not go into detail. What I'm interested in, for example, is when you implement some solution in some company what are the costs for that company in the near future, for example, in one or two years. This is what we are thinking about. 

It's not easy to implement some solutions in some small companies if at the beginning they need to pay some licensing costs upfront. For example, for Mongo DB. It would be easier if the small companies could operate without licensing for some period of time and then only after they grow to a certain size or need they would have to pay some for that usage.

While I may advise clients on MongoDB, I don't have a direct business relationship with the company.

We always use the latest version that is available.

As we implement the solution for clients, we deal with different deployment models. Typically, for banks, for example, the on-premises deployment is used. However, we've looked into the cloud as well and some clients may consider that deployment instead.

A company considering the solution needs to first think about the project and the infrastructure that they need to implement. Every solution is different. I cannot say that I feel some particular way about MongoDB. It always depends on the organizational need. 

I'd rate the solution at a seven out of ten. I'd rate it higher if it offered more upfront support and a lighter solution for smaller organizations. It would be great if they could build an open-source version, for example.