MongoDB Reviews

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. 

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.