What needs improvement with MongoDB?

The free tools, like MongoDB Compass, could be enhanced. This is especially relevant for the IDEs or similar tools.

MongoDB should support TypeScript.

Some of the solution's transaction capabilities can be improved. Not much support is available on the transaction side. The size of the document that we can share is also limited. MongoDB also has sharding capabilities, but they are a bit complex. There is some issue with the replication of MongoDB across clusters. We're not able to replicate MongoDB.

MongoDB should improve its data loading part. If I update data with MongoDB via the browser, the loading takes a lot of time when I want to use the updated data. The loading is further slowed down if my internet is slow. We use MongoDB Compass to avoid these types of issues.

Improvements could be made in query optimization, particularly when performing lookups or joining tables. Input functions to restrict the amount of data passed in pipelines would be beneficial for this purpose. Additionally, enhancing the documentation to make it more beginner-friendly is crucial. As someone with seven years of experience with MongoDB, I find the ecosystem intuitive, but newcomers often need help with the documentation.

The analytics needs improvement.

They could provide more documentation and examples for adding pipeline stages. There could be a feature where commands made in MongoDB could be easily copied and shared in their original format. This functionality would enable seamless transition and compatibility between platforms like Linux and mobile devices, reducing the need for complex filters or Citrix-based solutions.

The dashboard is an area of concern in the solution where improvements are required. The price of the product may be a concern for the customers who use it, so improvements may be required in the pricing model.

The product's data consistency could be more efficient than traditional SQLs.

It has certain limitations when it comes to handling hierarchical data, enforcing relationships, and performing complex joins, which should be taken into account when designing databases for applications with intricate data requirements.

It isn't easy to recognize entities with MongoDB.

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 think that MongoDB's search engine should be improved.

The MongoDB documentation can be a little complicated sometimes.

The scalability of the solution has room for improvement.

The solution should more easily integrate with custom code. Kibana should be bundled with the solution as one software installation. Currently, Kibana is a separate software and that is redundant. Most developers install both Kibana and the solution so a bundle would make the process easier.

MongoDB could improve by not having so many updates and different versions.

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.

The product roadmap shows us that the MongoDB team is very professional. Since we started using the product, it's like having wizards that are one step ahead of our needs. They are looking at the community, the market, and the competition. From my point of view, they need a totally free IDE to work at high levels. The best I know is Studio3T, but licensing and an embargo in our country make it difficult to access. MongoDB needs something like Studio3T (Compass is just fine, but it isn't Studio3T) to really get the whole developer community.

In terms of what could be improved, that's a difficult question actually, because we're really very happy with it. As for what could be included in the next release, I'd like to see an ID generator. It's very technical but I don't think it has one, so we have to go to great lengths to work around that.

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

Our engineer is having a bit of trouble because it's a new concept database. Currently, we're just getting used to the product.

I have found the solution difficult to operate as an administrator. They could improve the experience by adding some more features to the UI. There needs to be better integration, we have been having some issues with some projects.

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.

I would like to see the scalability and security improved.

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.

Oracle is stronger in some specific features. For example, the remote cluster when you need to synchronize the enormous amount of data between two data centers and so on. It's that Oracle RDC and Oracle GoldenGate which are actually about the data replication which can be supported by the nature of the database scheme. We are actually validating each process and also new processes in what we call the operational tier, and if you are having the business-critical processes which need business-critical operative data, we actually prefer Oracle over MongoDB. MongoDB is the second option for non-critical processes at the moment. We do not yet trust it with critical items. We'd like information about client onboarding experience and success stories. It would help to have something to show to internal stakeholders. We need some use cases from the outside to begin to open discussions on how we can use this tech in more ways in the future.

MongoDB can improve large-size video or media frame operations. There are a lot of customers who want to upload media frames and video games but there is some difficulty. In MongoDB, we are looking out for solutions that are for large-size media files that can be saved and navigated efficiently.

I'd like to see improved scalability and elasticity. Also, the software should have certified container images so it can readily be used in production.

It could be much more flexible like SequoiaDB. I would like to see more flexibility in the next release, especially when working with Microsoft Windows. A lot of people struggle with MongoDB because of their Windows versions. But Linux is faultless and mostly runs nicely.

Currently, I understand that they're revamping and adding a lot of features, and things are moving a little slowly. The performance could be faster.

We'd like technical support to respond faster to queries.

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.

The solution could have more integration.

The solution should have better integration.

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.

The stability could be improved.

The auto transaction feature is something that I found a little bit problematic. If we want to run two or three transactions at a time, we get write conflicts. So, it becomes really difficult when concurrency comes into the picture. Sometimes, there are some problems in creating a connection with two or three tables, such as running two queries at a time or getting a reference from one table to another table. People generally don't use it much to join two or three tables, but I would like them to simplify that process. It can sometimes be a little bit difficult to understand for a newcomer.

They could improve the UI and the analytics part.

I think it would be good to have more search options such as an index resource. This will provide more options and resources to do advance searches. Criteria and filters would be good too as they will help us find what we are looking for. Filters will be useful if you want to filter something to a dashboard according to certain criteria.

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.

It should have GUI for managing clusters. MongoDB needs a more powerful GUI to manage clusters and make switchovers. Currently, there is no good, free tool to check the replication to find out if there is a gap.

MongoDB should be more stable, and support should be more efficient.

You can update the server from another platform (Mongoose) which sits on top of MongoDB and makes it a relational database. The beautiful thing about MongoDB is that it's not a relational database — multiple statements are there so it's easy to access. It serves the purpose for which we are using it. I suppose it could be a little more secure.

It would help if MongoDB offered a light solution for small projects. Its become a very big database, and we need a smaller solution for our end-users.

It would be good to have scalability for clusters. For example, if we have three clusters, we should be able to increase to five clusters if required. I am not sure if such a feature is currently there. I hope there is good documentation for this.

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.

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.

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.

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.

There should be better integration with other databases. The security should be improved.

Simplifying the aggregation framework would be an improvement. Also, the replica system could be improved.

The price can always be better. I mean, we are a big corporation so it is quite expensive for us. So perhaps they can improve on the price.

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.

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

The documentation for MongoDB is not very good and should be improved. Some of the documents are referring to legacy versions. MongoDB 4.2 has been released, but there are training documents and other documentation that still refers to versions 3.6 and 3.4, which is not good. They should definitely update the documentation as new software is released. Data encryption is possible using third-party tools but they should have their own encryption capability built-in to this solution. Information about upcoming and recently released features should be made available so that we are aware of the latest features, and how we can manage the issues that will accompany them.

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.

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.

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.

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.

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.