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.

In my SaaS role, MongoDB Atlas helped me meet compliance standards by keeping tenant and customer data in separate databases. I improved performance by setting up Atlas clusters in each region. In a high-restriction context, data replication between regions ensured smooth failover without constant snapshots. For added security, I even took data snapshots to another cloud. Choosing MongoDB Atlas depends on your specific SLA and disaster recovery needs.

The most beneficial MongoDB features for our workload are the ability to scale up and down using automatic sharding and clustering. This is crucial for handling diverse requirements and integrations with different configurations. The flexibility to support various deployments, whether on AWS, Azure, or GCP, by easily adding additional clusters, has been another significant advantage.

There is room for improvement in the cost of certain features like encryption. The web console isn't very intuitive, especially for large data. The new feature, Cube, for BI needs better documentation, and more workshops or videos would be helpful for users and developers. Additionally, real-time performance monitoring in MongoDB Atlas needs improvement.

I have been working with MongoDB Atlas for about two months, but my company has been using it for a couple of years.

MongoDB is quite stable.

The technical support is very good. I would rate it as an eight out of ten.

Positive

I have worked with MySQL and PostgreSQL. MongoDB stands out for managing JSON and document types most efficiently. While other databases support JSON fields, MongoDB offers the best solution for handling JSON data.

The deployment was quite straightforward and it only took about half a day. 
Maintenance is generally manageable with MongoDB, but it becomes challenging when facing issues or disasters. The profiler and logs are not very user-friendly which makes it harder to identify and resolve problems quickly.

The ROI with MongoDB Atlas depends on how well you manage your data and throughput. It is crucial to understand your data and use their tools effectively. Mismanagement can lead to higher costs, especially with scaling, so careful monitoring is essential.

I don't have any concerns about MongoDB Atlas pricing and licensing.

MongoDB's default encryption provides a baseline for data protection. The flexibility to let customers manage their encryption keys enhances security.

MongoDB Atlas supports our organization's implementation of microservices architecture by seamlessly fitting into our domain-driven design. While we primarily use domain-driven design rather than microservices, MongoDB Atlas offers flexibility and scalability to meet various requirements. It easily accommodates diverse data structures and events related to our customers, allowing for efficient and straightforward implementation.

Overall, I would rate MongoDB Atlas as a seven out of ten.

My advice to new users is to design your schema thoughtfully, considering MongoDB's document limitations. Utilize profiling and set up alerts for scaling issues. Understand how to query efficiently and focus on proper indexing for improved performance.