We are using MongoDB Atlas for our log storage, transactional log storage, and we are into CPaaS business, communication platform as a service.

We are also using PostgresSQL in some of the applications, alongside MongoDB Atlas.

The most valuable features of MongoDB Atlas in handling large data volumes include collection size and its NoSQL database capabilities.

The security features of MongoDB Atlas support our organization very well.

My company has seen financial benefits from using MongoDB Atlas because we are using open source.

There is nothing about MongoDB Atlas I would like to improve or any weak points at this time.

I have not thought through what other features I would like to see included in future updates.

MongoDB Atlas should support containerization.

I have been using this product for the past 5 years.

I find the installation process easy to deploy as it wasn't difficult to implement.

The stability of the product is very high, and I would rate it a nine out of ten for stability.

It's very much scalable, and I would rate scalability a nine.

For premium support, I would rate the support of MongoDB Atlas a nine.

Premium support requires additional payment; otherwise, you can manage whatever you can yourself.

Though I am currently not using support, I would rate it a nine.

Positive

I personally took part in the installation process.

I can deploy MongoDB Atlas in 2-3 hours.

When we make changes, responsibilities are always distributed. It will be a team whenever a production deployment comes.

My company has seen financial benefits from using MongoDB Atlas through savings because we are using open source.

Postgres is another option that is available for us. I have considered alternatives for MongoDB Atlas.

The database team consists of five to six people.

We are not currently using the AI functionality in MongoDB Atlas, though AI-driven projects are available in their vector search.

Based on my experience, I would recommend MongoDB Atlas to other users looking for NoSQL databases.

We do everything on our own and are not using third-party services for maintenance.

I am involved in the maintenance process.

We are using MongoDB Atlas for commercial purposes.

The number of people currently using this product in my organization is related to my platform hosted on MongoDB Atlas.

I think it's a competitive solution compared to others, though I cannot comment on pricing as I haven't seen pricing for other products.

I rate MongoDB Atlas a nine out of ten.

On-premises

Amazon Web Services (AWS)

I primarily use Oracle databases, but I work with many other databases such as MongoDB Atlas and several cloud databases. I utilize MongoDB Atlas predominantly for training-level projects in resource grooming and for sub-projects at my office. It is used alongside Oracle and Postgres in these training layers.

MongoDB Atlas offers replication, which is cheaper than Oracle RAC, making it appealing to certain industries. It is particularly useful for unstructured and semi-structured data because of its performance in these areas. Sharding and partitioning are supported, though they don't reach the same level as Oracle's capabilities. This cost-effective solution assists organizations in data storage and management.

It would be beneficial if MongoDB Atlas could better support OLTP aspects and data frames, as well as enhance its capabilities for data pipelines and visualization dashboards. Furthermore, supporting the medallion architecture could be a valuable addition, and incorporating improved spatial and vector handling for geographical data could make it more competitive. Enhancing vector processing for AI capabilities would also be critical.

MongoDB Atlas is effective for unstructured and semi-structured data, but when it comes to OLTP transactions, its performance declines. This is a continuous challenge I face when utilizing MongoDB Atlas.

MongoDB Atlas offers sharding as a scalability feature, although it does not perform as well as Oracle. Partitioning is also available; however, it lacks a multi-tenancy architecture, which affects its scalability in comparison.

Technical support from MongoDB Atlas, which is open source, is satisfactory in most cases. However, when compared to top databases like EDB, Postgres, and Oracle, the features of MongoDB Atlas fall short, resulting in an average rating due to higher-expectation features still lacking in its offerings.

The price of MongoDB Atlas is reasonable, which is why many organizations, including mine, are opting for it.

The overall rating for MongoDB Atlas is around 5.5. To improve, MongoDB should enhance support for demanding graph databases, vector databases, and spatial handling. Additionally, improvements in AI capabilities, particularly vector processing, are imperative. These developments could provide MongoDB Atlas with a competitive edge.

I used MongoDB Atlas for structured data storage as part of an application service provided to one of our customers. The application was based on MongoDB and Atlas. While Google Cloud SQL was used for consulting, I interacted with Google Cloud but was not the final decision maker.

From an operational point of view, there were no costs associated with maintaining the database on my side, and service costs were acceptable from both my side and the customer’s perspective.

I find MongoDB Atlas highly scalable and easy to use, with very good support. The pricing is quite scalable and applies to various scenarios, both for smaller and bigger companies. 

MongoDB Atlas has supported our data growth well, and my overall impression is very positive. It is easy to work with and has a reliable support structure. For structured data storage and performance, it provides a comprehensive solution, and the feedback was generally positive.

I am not an expert on what improvements could be made to MongoDB. The service is continually evolving with new features while maintaining reasonable pricing, making it attractive for developers.

I have been using MongoDB Atlas since 2017 and Google Cloud Platform since 2018.

There are no issues mentioned regarding stability. I evaluated MongoDB Atlas as not the best solution for the application in the long term, specifically when the services consolidate themselves.

MongoDB Atlas scales well and supports data growth effectively.

The technical support is very good. I have used them sometimes, even recently, and found the feedback to be spot on our needs.

Neutral

The pricing is quite acceptable and scalable. For our service, it was around 300 to 600 euros per month, which was acceptable for our customers. We could scale up for better performance and scale down when needed.

I highly recommend MongoDB Atlas for both smaller and larger companies. 

It is rated an eight out of ten, depending on the use case. As a document-based database, it is one of the better products on the market.

Other

We use an application called Fully Factory in the Indian stock market. It works by setting price ranges for stocks. For example, if the Bank of India stock sells between 800 and 810 rupees, you set a range of 800 to 850 rupees. The system prioritizes buyers with the lowest price and highest quantity.

MongoDB's "find first" function quickly locates and blocks the remote and quantity. The client's amount is shown in the record, and then it's processed. We take around 500 records, and the first 100 are processed in a batch. This gets executed and recorded. Developers handle tasks like JP, AR, and AP separately. We update the client's inventory and pass it to a third party. In Microsoft, we use the same client cover to determine the quantity and product details. This is then executed in their API Acondra server system.

So, MongoDB Atlas is used in stock market applications to handle large-scale data processing.

For security reasons, I prefer MongoDB Atlas. It supports role-based access control, so you have an entity for each individual. 

Spring Cloud ensures I have this set with Atlas, and Spring Security is entering the security for me. That's why I feel Spring Security is much better. Even if you expose a public method, it will be exposed via an authentication token.

If you're putting a direct authentication case authentication with their sync of Google token, just put a sync token directly. It will automatically type your method. Even if you expose a public method, it will be exposed via authentication token. Unmasked analytics, you have PeerSpot on or authentication token. It won't get executed.

It's better to use the predicate in Java side to sort. If you are trying to sort in MongoDB, the comparator of Sandal will be discussed. It can be sorted, but if you can do the competitor in Java, sorting using predicates (filtering conditions) and all, it'll be faster. That is what I noticed. For conditioning sorting in MongoDB might be slower, but I haven't verified that. I am doing sorting using predicate in Java.

Another concern:

When I use RoboMongo with MongoDB, it gets delayed and slower when the records are more than one billion. If the records are more than one billion, the document page will see it's all documents. If you have more than a thousand series in your system, it will be difficult to scroll down and get the reserve the directory. I think if they can have some horizontal way of displaying the reports, they can't be answered, but I'm not sure. The tool is providing protected. However, in RoboMongo, it is tough to see that, of course. It's better at one thousand or four thousand since in a single row.

I have experience with this product. I've used MongoDB intermittently since around 2020. It's a deep system. You need to find the data, and sometimes use queries. There's a conversion tool that helps transform static queries into MongoDB 3 format.

In RDBMS, we have an option to put triggers and functions in the database. In MySQL, you have an option to put a function as well as a trigger, but I haven't found that option in MongoDB. I can create functions, but I am not able to create a function trigger there. We have to create, get, update, and delete, which I can do in MySQL and SQL Server also. But in the same way, you can perform in MongoDB. That is the only thing I noticed. 

Other than that, the query that is performing, creating, updating, and deleting everything can be made possible in MongoDB. You cannot create only that trigger in MongoDB. I haven't found anywhere to create that trigger. 

Without triggers, you can't automatically execute actions in response to data changes in MongoDB.

That is the only drawback that I find with MongoDB: creating the trigger. Apart from that, I think everything can be possible. We can put function software into the database, and you can execute the review. But when creating the triggers, you need to perform separate functions for that. 

Scalability in MongoDB always depends upon the configuration. We can configure it accordingly, but it is definitely essential. 

Your hardware system should also ensure the number of resources your application is consuming. For example, in my application, if the unit is more than 400 kits. In a point of time, it will get executed. 

I tested that using JMeter. When I'm doing the amenity services, I always put the 500 resource at a time. At a single point of time, 500 resources will get in that 5, so I just find any issues on that. The client also has not had any issues.

When we are doing any of the microservices, we need to ensure using JMeter. Via JMeter, you can ensure, like, how much on the port of ten, how much in the source can be accessible.

It's a one-click install. Maybe, like, two settings. If you already have MongoDB, five to ten minutes is regarding some MongoDB. The only thing that you should know is the port number and the IP address if you're exposing your application to a third party. I think if you're aware of those risks, you can install it immediately. It's easy if you need to collect that data. You might know five to ten minutes. 

We can install the remote engineer system. I don't think it will be a bigger task, but even if you're configuring for multiple people, you just need to add that particular port number in your system. Otherwise, it won't allow you to log in.

Even if you're using Microsoft authentication, we normally have multiple layers of authentication. So use the command password, and then you will get the notifications, whether you are getting log-in or not. That will take some time. 

Maintenance:

For getting queries only, we put a Java set. From the development perspective, once the database is set up and you configure the URLs, everything works fine. You have 192.138.1.1 URL, it automatically connects to the review if the network is enabled. Then it connects to the review. However, it definitely depends on the bus service we are passing. It should work fine with no issues if the configuration is okay.

That is how we install it. Once we have source, then it's the same network. If it is on the same network, we have a contract, the traffic is there, and the agent works.

If I want to test whether my microservices work fine, I use them again, and they test if my microservices are working fine. Normally, almost all microservices are in a rack server, so you don't get the performance there. I haven't found any issues directly.

If you are looking for a robust system with a lot of security concerns, then you should go for IBM. I'm not saying MongoDB is not 100% secure, but for highly confidential data, I would suggest other solutions. 

However, in MongoDB, you can do filing processes and vertical reports. Everything can be done in MongoDB, but the newest is a relationship. You cannot maintain the referential integrity relationship. You can maintain it, but it will be a little tough.

If you want to maintain the relational database in MongoDB, the resource should be at least a minimum of one and a half years highly exposed in MongoDB. Then only we'll be able to manage that data. Even for new joiners, it is a little tough to explain how the relational database is maintained in MongoDB. 

Overall, I would rate the solution an eight out of ten. 

The application we are working on is built on MongoDB.

MongoDB is a NoSQL tool. We can easily add fields. It provides more flexibility to store data. It is flexible to changes. I have not encountered any performance issues.

Searching and browsing through the collection must be made easier.

I have been using the solution for two years.

The product has been stable so far.

The installation was easy. The deployment took an hour. One person is enough to deploy the tool. It does not require much maintenance.

I am using the free version of the solution.

I have used DynamoDB before. MongoDB’s free version is quite good for our use cases. DynamoDB is expensive.

MongoDB is a very good tool for first-time users. Overall, I rate the solution an eight out of ten.

We store all our data in MongoDB. Our frontend application is .NET, our backend is .NET, and the database is MongoDB.

We have two products running on MongoDB: a financial expense management solution and a sustainability product.

It can store data as a flat file, similar to a file system. It's called Atlas GridFS and it works very well.

MongoDB is a very good database. The Community Edition is free, which is cost-effective for development.

The API support is excellent for integration.

From an improvement standpoint, MongoDB can improve security.

There are some challenges from a security point of view. Since the file can be easily accessed, there should be more security features. The data should be encrypted in some form to prevent unauthorized access.

We've been using MongoDB for three to four years.

I would rate the stability a nine out of ten.

We haven't seen high volumes of data yet. Our solution is for expense management, not a full ERP solution. So far, the system has been stable with the current number of users.

It should be scalable and easily work with other databases like SQL or Oracle. We shouldn't have trouble converting the data.

I would rate the scalability a nine out of ten. Some security features are still under development.

MongoDB isn't for our internal users; it's for our customers. Depending on the organization, it can go up to ten thousand or even a hundred thousand users. We have a lot of customers using our applications built on MongoDB.

We are a young company, only five years old. We recently started this product, but we know that around a hundred people are using it in one of our products for web and mobile.

We have a very strong internal technical team that manages everything. We haven't needed any support from MongoDB because our team is proficient in using it.

My team only recommended MongoDB. We haven't worked with other databases for our current projects. I have worked with SQL Server and Oracle in the past as an SAP consultant, but those were for ERP systems, not application development.

MongoDB's setup is very easy. We plan to only use MongoDB for our future database needs.

It works very well with the .NET and Angular platforms due to the flat file support. So, we went with that option.

The main benefits include cost savings and speed. The application runs fast, and accessing data is quick.

ROI is very good. 

It's very easy to manage for our technical data analysts.

Overall, I would rate the solution a nine out of ten. I recommend using MongoDB because it's free for development, scalable, and user-friendly for connecting with frontend and backend technologies like Angular and .NET.

Public Cloud

Microsoft Azure

We primarily utilize MongoDB Atlas for tasks such as IoT integration. Additionally, it serves as a general-purpose database that aggregates analytics data before transferring it to a data lake. Its versatility allows for various applications, providing flexibility and ensuring the availability of essential data across different systems. While it is used in diverse contexts, many use it for IoT-related initiatives.

We prefer MongoDB Atlas over SQL because most of the data generated with IoT devices is unstructured. This gives you flexibility; you don't have to define specific schemas all the time, and sometimes, the structure of the object varies.

It improves data management along the same lines. MongoDB Atlas supports structured data with IoT projects.

MongoDB Atlas was explicitly designed to support IoT applications. Many databases offer features tailored for IoT use cases.

One area for enhancement is containerization. They could explore ways to facilitate deploying MongoDB containers within the platform.

I have been using MongoDB Atlas for five years.

I rate the solution’s stability a nine out of ten.

Two people use this solution because they work with sensors and other variations of IoT.
I rate the solution’s scalability a nine out of ten.

The tool provides a forum where users can engage with experts. These experts offer assistance tailored to your specific needs, whether you're focused on product-centric queries or diving deep into particular use cases. Ultimately, the support you receive depends on your requirements and the extent of your experience with the platform.

The initial setup of MongoDB Atlas is straightforward. The user-friendly UI guides you through the setup process seamlessly. It would be beneficial if they could maintain this simplicity across different operating systems. Additionally, if they can streamline the process to easily deploy with containers, it would greatly enhance user experience and make life easier.

MongoDB Atlas offers various options based on your needs. It can accommodate both, whether you require the enterprise version with advanced features or prefer to start with an open trial version.

Security is primarily organized around organizational principles, allowing you to customize and adjust each tool according to your specific security policies. I recommend the product. Every product serves a purpose as long as it addresses the right problem. MongoDB Atlas has proven particularly effective for applications such as analytics and IoT, making it a recommended choice for those use cases.

Overall, I rate the solution a nine out of ten.

We may use it as an application database. The application stores the data as documents in the database, which is a preference for our company because it’s a Document DB and a NoSQL database, which are preferred over traditional relational databases.

MongoDB has wrapped up the whole development lifecycle. MongoDB has multiple built-in tools such as MongoDB Shell, Compass, and other tools. It helps the developers to use that specific tool efficiently. Users do not have to worry about finding the tools and then installing and using that specific tool to communicate with their database cluster. MongoDB has a built-in option using MongoDB Shell or Compass for that purpose.

So, it has positively impacted the development speed and productivity.

There are many valuable features, but scalability stands out. It can scale across zones. You can define multiple nodes. They have also partnered with AWS, offering great service with multiple features, including built-in backup, all under the same roof, without the need for external tools.

So, the scalability feature supported our data growth overall. The growth of the database depends on the application side. The database aids in scaling when the application requires more storage. 

It’s configured to scale automatically across zones and regions, ensuring that performance doesn’t degrade even when scaling down.

The scalability aspect is quite difficult to implement. It should be much easier for the end user. You cannot use less than two nodes; you have to use at least two nodes, and they categorize their nodes, like m5, m10, and m20, according to their resource practices, which are also a bit expensive.

The end-user has to learn a bit about it. MongoDB has great content on its site. They call it MongoDB University. They actually have great content for that. Anyone can learn it, but one has to study it before diving into it or starting to use it.

I have been using MongoDB Atlas for almost three years.

The scalability is good. In my team, almost the whole development team is using it. So, there are around five end users. 

I contacted customer service and support for multiple purposes while configuring. The support is quite efficient, and the guidance is quite good. Initially, when I was working on it, I had to communicate with the support team.

So, I had a good experience with the support. 

Positive

The initial setup is not too difficult but can be somewhat tricky. 

It is tricky mainly in terms of configuration, especially if it's not internet-accessible, configuring it to stay within the same data center while allowing developers access without network barriers.

It is worth my money at the end of the day.

The pricing is not that expensive, but it can be, especially when we have deployed it across multiple zones.

If you want to go with NoSQL, I would suggest using MongoDB. 

If you are saving documents and prefer AWS services, AWS also has their DynamoDB for that purpose. I would suggest using AWS service if all of your services are already on AWS.

Overall, I would rate it a seven out of ten.

We restore our golden data from various sources and then push it to MongoDB. We make our CDP from MongoDB, which serves as a device-centric system.

There is a built-in feature called Autoscaling In MongoDB Atlas. This feature automatically adjusts the configuration of MongoDB based on the volume of users we ingest daily. Autoscaling dynamically scales the resources to accommodate the load when our data flow increases.

The real-time data visible within MongoDB Atlas is not accurate. If they can improve the UI that monitors real-time data. It's more impressive and more attractive. It could be more user-friendly.

I have been using MongoDB Atlas for two years.

The product is pretty stable.

The solution is scalable. Autoscaling supports it.

50 users are using this solution

Whenever we have doubts during configuration, we reach out for assistance. We must upgrade certain parameters in our MongoDB setup, prompting us to contact their support team. They resolve such issues within four to five hours.

The initial setup is not very complex. It is easy to use. It's easy to deploy on MongoDB. We push from GitHub. From there, we specify where the data is restored in MongoDB. We continue to connect. It puts the data and delivers it to Argo City.

The product has a yearly subscription.

We have assigned DevOps for security.

The overview and monitoring part will address this issue, and then we will use it to observe any increasing traffic on our website. We also monitor the rising number of connections due to this traffic. It's quite easy to oversee everything in one place. However, the UI isn't particularly user-friendly.

I've also used it in my previous company and found it handy and easy to configure, including easy capabilities.

We are establishing SLAs that are directly tied to MongoDB. All are interconnected with MongoDB. If MongoDB experiences downtime or RAM or CPU usage spikes significantly, users may encounter difficulties logging in. This reliance on MongoDB can pose challenges for user accessibility, particularly when considering the conferencing tools we use.

Overall, I rate the solution an eight out of ten.

We use it in a cloud setup on Google Cloud Platform as part of a microservices-based cloud solution. These microservices communicate with messages, and one use case for MongoDB is storing specific messages we're interested in.

MongoDB has supported our organization's need for scalable and flexible data storage.

We use it internally, where different teams manage different microservices. Sometimes, internal incidents arise, requiring teams to dedicate personnel to resolve and communicate with other teams. 

With MongoDB, other teams can now access some of our data and investigate issues on their own, freeing up personnel for other tasks.

Moreover, this solution simplifies real-time data analytics or application development for our business.

It simplifies things by automating previously manual tasks. It acts as a self-service portal for our team, reducing manual work and enabling automation.

We're happy with the performance, maintenance, and especially the ease of use within Google Cloud.

Given our microservices architecture, it's like a large puzzle, and MongoDB feels like it fills the gaps we were facing. So, the global clusters feature has enhanced our application performance and user experience.

It helps us optimize team performance, which is valuable.

The initial configuration could be a bit easier.

I have been using this solution for a couple of years. 

We've experienced some issues, but most MongoDB issues are resolved quickly. The issues we face are mainly with other systems.

So, it is a stable solution. 

It is a scalable solution because we use quite a lot of data, and it handles it well.

It's a microservice solution, so each microservice runs on several pods, maybe eight. Each pod uses MongoDB and makes its own connections, so multiply by eight, maybe 100, so roughly a thousand users.

These are internal users, so we're fine with the current number.

MongoDB offers free support online, and they seem to be doing a good job overall.

We have used other databases as well, including Google Cloud, for the past two years on our current project. My company policy guides such decisions. Overall, the company is happy with MongoDB.

The setup is automated through our partner using Terraform for provisioning, not just for MongoDB but for our whole infrastructure. We manage daily deployments using TerraForm, and MongoDB setup on Google Cloud is very smooth.

The deployment is very quick. For example, microservices using MongoDB start very quickly, possibly within a minute.

We haven't had major issues with deployment or configuration. Maybe initial configuration fine-tuning for performance can be time-consuming, but the initial effort pays off later with reduced maintenance needs. 

Expertise in automation and deployment processes is helpful and worth learning within the team.

We do it in-house. It's integrated with Google Cloud, GitHub, and GitLab actions. Everything is cloud-based and easy to work with. It's been continually improving over the years.

We don't use external consultants, as we have in-house expertise. It's a 100% cloud solution.

We don't have engineers dedicated to maintenance. It's part of our continuous integration and delivery environment, so there's not much manual intervention needed. Issues usually arise when deploying incorrectly and rolling back, but deployment itself is straightforward.

In some teams, companies, and projects, there might be two to three people dedicated to everything, which is a lot. If these skills to analyze productivity or cost saving can be automated, these people can teach others and do more valuable work. It's all win-win.

The price is cheap enough. It is comparable and has average pricing. We have a long-term license.

The pricing is acceptable for enterprise tier.

We haven't faced any major issues so I would rate this solution a nine out of ten.

In this project, it's more integrated than previous ones. The level of integration, automation, and evolution is impressive when used well. It's flawless, straightforward, and hassle-free.

Public Cloud

Google