MongoDB Reviews

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.

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 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 use MongoDB in different products. The first is a Business Process Management System (BPMS) that we have developed for ourselves. MongoDB stores all of the data for business flow management.

The second product is in the capital market. We have implemented it to use all of the stock-related data.

We have also developed an online shipping product, using MongoDB for storing product features.

The most valuable feature is that you can store unstructured data, which is helpful when you don't know what the best structure should be and you cannot use a relational database because of that. For example, in our online shopping product, different products have different features and there is no structure for all of the data.

The usability is good.

Compared to a relational database, the performance is good.

The performance can be improved. While it is good compared to relational-type databases, it could still be improved.

Stability-wise, there is some room for improvement.

I have been working with MongoDB for between four and five years.

If you take care of the application and check everything then it will be stable. However, if you do not maintain it properly and do not have support then stability will be a problem.

We have not tried to scale our implementation of MongoDB.

We do not have direct support for this product. Instead, we have used the community-based resources that are available on the internet. For example, we have searched for questions and taken advice from the community in order to resolve our problems.

We may have used InfluxDB for some reason but I don't recall any of the details.

The initial setup is simple and not a problem to complete. I don't recall the exact length of time that it took to deploy, but I think that it was completed within one or two days.

We deployed MongoDB ourselves.

We have two administrators who maintain and work with it on a daily basis.

We use the open-source version, which is available to use free of charge.

My advice for anybody who is considering MongoDB is that when we want to have flexibility in storing our data, I recommend using it. We can store anything, in any format, in any size, and accessing the data is the same speed. In the case where you have structured data or it is in a unique format, this is not the product that you use.

In summary, this is a good product and it has been very useful for our purpose.

I would rate this solution a seven out of ten.

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.

We use it in our virtual environment.

Our software produces a lot of predefined JSON Structures. We save those JSONs in an encrypted form inside MongoDB.

It's simple storage of JSON. We do not perform any database functions.

In our case, it is most important to have redundancy. It supports a replica set and it allows us to use mutual TLS for authentications with the certificates.

The documentation is useful.

We work with the community edition and it would be really nice to have for the database side encryption, but it's not available in the community. It is only available in the enterprise edition.

We use mutual TLS, which means we use the certificate for authentication and connection encryption.

When I want to connect to a node, I need to supply the certificate that MongoDB trusts, even though I use an admin password. This is not useful, and it complicates things.

It would be much more useful if I have an admin user and a password.

I would like it to be more straightforward when connecting to a node.

We have been using MongoDB for the last 12 months.

We are using version 4.4.0.

It's pretty stable. We don't have any complaints.

It's a scalable solution. We haven't had any issues. 

We are in development mode, and not really used by users. We have five people for development.

We can't know for sure if we will continue to use this solution. We are still in the development phase so we have to see when we finish.

I have not contacted technical support. I used the official documentation, which was enough for me.

The initial setup was straightforward. We used Docker, so it was pretty easy.

It didn't take long to deploy.

It's free. It's a community edition, so we do not pay anything.

There are no additional costs.

We didn't really evaluate other solutions. We did not have strict requirements in choosing a database. We just needed to keep JSON files informed when we produce them and MongoDB seems to be fine for us.

I would rate MongoDB a nine out of ten.

When the company started, MongoDB was our primary database.

It offers great flexibility where developers can define any key and assign a value to it. This means that there is very little that one has to plan in terms of designing the schema upfront, so developers enjoy a lot of flexibility. Now that we have more use cases for which NoSQL is not suitable, we are trying to move those workloads out of MongoDB.

MongoDB is extremely developer-friendly because when you are starting, there is very little time needed upfront in terms of planning. Whenever a developer wants to build a certain feature, they simply define a key and a value and that's it.

It is very easy to create an index on a field that you want to have searchable.

All of the documents are stored in JSON format, which gives developers a lot of flexibility.

MongoDB should not be used for reporting, analytics, or number-crunching tasks.

The pricing should be improved because the whole design is around replication of data, so in terms of storage costs, in the long run, it will be expensive. The amount of storage grows very quickly when compared to other databases that store data in normalized form. If there were a way that some data could be partitioned or moved into cold storage then it would be very good.

We have been using MongoDB for about four and a half years.

There are bugs in the system but they are not very significant. We have found a workaround for each of those bugs and we have been running the full-scale production cluster for more than four and a half years. As we haven't had any issues, I would say that it is pretty stable.

This solution is used constantly by both us and our customers, every second of every day.

We are not looking at increasing our usage. Rather, we will be moving some of our workloads off of MongoDB. Ultimately, usage will be at a standstill or perhaps even reduced.

This is a scalable solution. We have close to 100 developers who use it. In addition, our entire business makes use of MongoDB. Everything the customer does makes use of this solution, so I would say that we have at least 100,000 users.

Because we are using the Community Edition, we don't have any support whatsoever.

We did interact with them for MongoDB Atlas, and we are still in contact with them to see if we can take something into production a couple of quarters from now.

We did not use another NoSQL database solution prior to MongoDB.

When we installed MongoDB the initial setup was complex. However, now with Atlas, it is very easy. It took us less than a week to deploy and now, with Atlas, there are a lot of things that you don't need to know that was required four years ago.

I did the original cluster deployment on my own.

We are using the Community Edition of MongoDB. However, we would be happy if the pricing for the full version were more competitive.

We use a lot of different database products and the choice depends on the use case.

With respect to NoSQL, we did not evaluate other vendors because when we implemented this solution four and a half years ago, it was the only scalable NoSQL database. This made it a rather obvious choice for us at the time.

The features that I have looked for are in this solution and we are using an older version. The current cloud-offering, MongoDB Atlas, has even more features. It would be a natural fit for us, but it will not be easy to move because we have a lot of dependencies. We have to update drivers, isolate collections, and take care of other issues before we can switch.

My advice for anybody who is implementing this solution, or any other database, is to take care to plan your indexes because it is extremely important. Spending some time designing the document structure in the initial phase will certainly help you in the long run.

I would also suggest that in terms of sharding, try to think about it as early as possible so that when you are ready to scale, it will certainly help to reduce the workload.

Do not rely on MongoDB for any of the analytics use cases. Aggregation works well but do not use it for your reporting or analytics or number crunching-related tasks.

I would rate this solution a nine 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.