MongoDB Reviews

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.

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.

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.

It stores historical data with ease. For example, if you are a healthcare member, then you will have multiple records of visits to the doctors. To store such data in Oracle Database, you have to create many records. You might also have duplication problems because your records are going in again and again, because of which the data warehouse and the maintenance cost will be huge. MongoDB is comparatively lightweight. It is a JSON extract. Once you define a schema and extract it, you can push all the relationships in any way you want. It is easier to define and get different types of transactions into MongoDB. It is also easier to set it up as compared to other solutions.

MongoDB is a NoSQL database, which means it is a document DB in which you can store documents that you created in BSON. It is pretty fast in response. It is faster than relational databases because it does not define any primary keys, secondary keys, tertiary keys, and all those kinds of things.

A normal Oracle or database tester will take some time to gear up to MongoDB because the way of writing queries is different in MongoDB. There should be some kind of midway where a person who is coming from an Oracle background can write a query and get a response by using something like a select * statement or other such things. There should be some way for MongoDB to interpret these commands rather than making a person learn MongoDB commands and writing them. I struggled while writing these MongoDB commands. I had not seen such queries before. It was pretty difficult to get them. This is one of the areas where it would help from the improvement standpoint.

It is stable.

It is scalable.

I haven't called them ever. I haven't seen any issues, so I would say it's pretty good.

I don't know, but I have heard from people who procure it that it is much cheaper than Oracle.

It is a good tool. You should give it a try. It has a very good and different perspective of looking at how data can be stored in a database and restored from a database because it is not like a straight query or record. The data is just in files. It does whatever a database should do.

I would rate MongoDB a nine out of ten.

We primarily use the solution as a database. It's basically used as a storage engine.

The solution is a very dynamic product. It becomes extremely easy for us to support user requirements and we also make use of the simplicity of a cloud redeployment.

The solution is easy to deploy.

The product can scale quite well.

The cloud version of the solution is very affordable.

The solution's most important aspect is its seamless database.

The solution offers excellent documentation.

The on-premises version of the solution is still pretty expensive, especially compared to the cloud version.

The management on the cloud is pretty good, however, the on-premises deployment model is a bit more difficult in this area.

If they want to make their product a little competitive, they'll have to go to organizations and get a bit more commercial in their approach. They need to think about pricing and licensing for RDBMS players. For them to be competitive in the market, they will have to think of strategies other than what they have currently. Their pricing definitely needs to improve.

We've been working with the solution for four years now. It's actually coming up on five years soon.

We've never faced any issues with stability. It's been very good so far. It doesn't crash or freeze, and it's not buggy by any means.

The solution is extremely scalable When we need to expand it out, we know we can do so easily.

We have about five products that factor into the needs of the BFSI segment in India. These proprietary products developed on five or ten platforms. We don't develop MongoDB, we just use it as a storage platform.

Currently, we also use RDBMS. We use Oracle for some other products. We don't just use MongoDB exclusively.

While Oracle is better for transactional services, MongoDB is extremely good at support services. That's the main difference. I have seen people use MongoDB for transactional as well, however, I have never attempted it, so I can't speak to it's capabilities.

The solution is very easy to deploy. The implementation is not complex at all.

The on-premise implementation takes a bit longer. We're looking at a six month implementation for one of our clients, for example.

We handle the implementation ourselves in-house. We don't need the assistance of a consultant or integrator.

For people who can afford it, there are good subscription offers that are available on the cloud as well as on-premises. On-premises is still a little expensive. However, if a company decides to go to the cloud, it is pretty affordable.

If the company is small, there is a community edition that can be taken advantage of. If a company needs to scale quite a bit, they'll need to move up to the enterprise version.

Due to the fact that we are a BFSI focused product company, we typically recommend that users go for the enterprise-level license.

There is also pricing surrounding support. We're in discussions with MongoDB about that now. I don't know the exact costing just yet, however, I know it isn't free.

We are a customer of MongoDB. We don't embed it in our application, however, we recommend it to our clients who use our product.

We're mostly on the cloud deployment version of the solution However, we do have a banking client who requires an on-premises solution. We work with both and have experience with both.

This solution is perfectly suited for companies of all sizes, from small to large. Small companies can definitely use the community version, however, this product offers an enterprise-level license for much larger organizations as well.

I'd advise new users to be flexible and be able to change their mindset when it comes to MongoDB and what is in the RDBMS. there's a bit to unlearn before you re-learn MongoDB. The solution does have a good survey of languages and it's quite good.

Due to the fact that is scales well, I'd rate it 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 are using this solution for storage and mapping. We have developed an application for mapping. We source the GeoJSON position for approximately eleven million points.

Our application is made for desktops, and we started using MongoDB for that application.

We have four teams in our laboratory and the other teams are developing their applications to be used with MongoDB.

The primary use of MongoDB is for mapping the application.

The most valuable feature is the geometric information done with GeoJSON. We search the points, and we can perform searches for the data using the RPA for MongoDB. We can ask for points in the geometric shapes or points near other points.

Simplifying the aggregation framework would be an improvement.

Also, the replica system could be improved.

I have been using MongoDB for approximately four years.

We have anywhere from 15 to 20 people using this solution on a daily basis.

This is a stable solution and we are happy with it.

It is possible to scale this solution but it has a problem with the replication.

I have not contacted technical support. We have been able to resolve any issues we have had on our own.

Previously we used MariaDB and we continue to use MariaDB for other purposes. We started using MongoDB to manage non-relational data.

The initial setup was simple and straightforward.

It took a couple of hours.

I am the only one maintaining this solution.

I completed the initial setup and implementation.

I did not use the help of a vendor or integration. I did it on my own.

MongoDB is an open-source solution.

We are a small laboratory and always look for open source solutions or solutions where the licensing is every year. We are prepared to do the troubleshooting ourselves.

The most important part is to evaluate the rest of the ecosystem integrations. When we started, the driver that we used to develop the application was in C++ wasn't relevant. At the start of the project, we had some difficulties because there was no documentation available. There were no examples and no support from the community. 

You have to take into account the languages that you are using. If you are going to develop in the main languages of the solution such as Python, or JavaScript, then you won't have to worry.

I would rate this solution a nine out of ten.