MongoDB Atlas Reviews

In my day-to-day work, I use MongoDB Atlas primarily for storing and querying semi-structured or dynamic data where schema flexibility is important, as I work extensively on schema design, indexing, and query optimization. For example, in a system like policy or config management or aggregator response, the data structure evolves frequently and can be nested. MongoDB Atlas allows me to store data in document-oriented format and avoid complex joins, making faster reads possible.

A specific example in my project where MongoDB Atlas made my work easier and faster is that we store data as flexible documents, which allow us to onboard new partners or change the schema without requiring database migration or downtime. This made our development faster. We handle dynamic policy or config data for hotels, and the structure of the data varied across partners and kept evolving. Some had nested rules and different fields and optional attributes. MongoDB Atlas made our work easier to handle evolving nested structured data while maintaining performance and reducing development overhead.

One more aspect of my use case where MongoDB Atlas fits in our workflow is that I typically use MongoDB Atlas for flexible or read-heavy data, especially when the schema evolves frequently, and I combine it with Redis as a caching layer for hot data. This helps me balance flexibility and performance, and MongoDB Atlas acts as a primary store of semi-structured data while Redis handles low-latency accesses. Another important aspect is faster development cycles. Because of MongoDB Atlas's schema flexibility, I can iterate quickly without worrying about strict migration, which is very useful in fast-moving product environments. Since it is managed by MongoDB Atlas, I also benefit from high availability, automatic scaling, and monitoring, which reduce my operational overhead and allow me to focus more on building features.

One of the best features of MongoDB Atlas is that it provides a fully managed database. One of the biggest advantages I think is that MongoDB Atlas is a fully managed service, meaning it handles deployment, scaling, backup, patching, and maintenance automatically, which allows developers to focus more on application logic instead of infrastructure. Apart from this, there are a few more things I appreciate, such as easier scalability, higher availability, built-in monitoring and performance optimization, and security and compliance.

Among managed service, scalability, high availability, and built-in monitoring, one of the most valuable aspects for my team is that we focus more on the fully managed database service, which significantly reduces operational overhead. Instead of spending time on provisioning, scaling, backups, or handling failures, those responsibilities are handled by MongoDB Atlas. This allows engineers to focus more on building features, optimizing performance, and solving business problems. It also improves development speed and reliability. For example, setting up an environment or scaling during traffic spikes becomes much faster and safer without manual intervention.

MongoDb Atlas combines multiple capabilities into a single integrated platform. Features like automated backup, monitoring, scaling, and security all working together make it much easier to manage production systems compared to stitching together multiple tools. This improves not just operational but also developer confidence in the platform to handle many failure and scaling scenarios automatically.

MongoDB Atlas currently has almost all the features we require, but there are some points where I see certain improvements. One area is cost visibility and optimization. Since pricing is largely based on storage and cluster size, it can sometimes be difficult to predict or optimize cost without deeper insights. More granular cost breakdowns or recommendations would be helpful. Another area I can mention is performance tuning transparency. While MongoDB Atlas provides monitoring and suggestions, debugging deeper issues like slow queries, index efficiency, or shard imbalance can sometimes require more control or visibility. Cost optimization, deeper performance insight, and easier scaling decisions would make MongoDB Atlas even more powerful.

A couple of additional areas where MongoDB Atlas could improve are integrations and developer experience. For integrations, while MongoDB Atlas supports major cloud providers and tools, deeper and more seamless integration with observability patterns would make troubleshooting distributed systems easier. On the documentation side, while it is generally good, some advanced topics like sharding strategies, performance tuning, and real-world scaling patterns could benefit from more practical guidance. Additionally, a better local-to-cloud development experience, making it easier to replicate production-like MongoDB Atlas environments locally, would help developers test performance and scaling scenarios more efficiently.

I have used MongoDB Atlas for a long time; to be specific, I have been using MongoDB for around two plus years of experience.

From my use case, I can easily say MongoDB Atlas is very stable, and it is used on a global level. It is stable, and since it is a managed service, features like replication, automatic failover, and backups are handled by the platform.

MongoDB Atlas is highly scalable. One of its main features, because of which I use MongoDB Atlas, is its scalability. It supports both vertical scaling and horizontal scaling through sharding, where data is distributed across multiple nodes. This allows the system to handle large datasets and high throughput efficiently.

Customer support for MongoDB Atlas is very good. I remember I had a case where I needed to reach out for customer support. Most of the issues I encountered, like query performance or indexing, were handled internally through monitoring, optimization, and best practices. MongoDB Atlas has strong documentation and a large community, which makes troubleshooting easier. For any infrastructure-level concerns, my platform team typically coordinates with the provider if needed.

Before MongoDB Atlas, we were mostly relying on MySQL, where we did SQL queries. MySQL worked well for structured data and transactional use cases, but we started facing challenges when dealing with dynamic and nested data structures, especially where the schema kept evolving. Handling such changes required frequent schema migration and joins, which increased development effort and sometimes impacted performance. We moved to MongoDB Atlas for that specific use case because it provides schema flexibility and better support for document-based data.

For pricing and setup cost, those are managed by my infrastructure or platform team, so from a developer perspective, I am not directly involved in these things. However, from a user perspective, I understand that costs are mainly driven by cluster size, storage, and throughput. Because of that, we remain mindful about efficient schema design, indexing, and avoiding unnecessary data growth. From a setup standpoint, MongoDB Atlas made it quite easier.

We have seen a return on investment; while we do not have the exact numbers, as it is saving our time and making our development easier, we can easily say the cost is being reduced. My team is using it even after a long time, and the main reason is that it provides cost savings.

Before choosing MongoDB Atlas, I explored a few options; one of them was using a relational database that includes JSON columns for flexibility. However, that still required managing schema constraints and did not scale up well for deeply nested or evolving data structures, especially with complex queries. I also considered other NoSQL solutions like DynamoDB, which offered good scalability, but it had more rigid access pattern design and less flexibility for ad-hoc queries and evolving schema compared to MongoDB Atlas. MongoDB Atlas stood out because it provided a good balance for schema flexibility, rich query capabilities, and managed infrastructure.

For advice, I would want to give to others who are looking into using MongoDB Atlas is to design your data models because of access patterns rather than trying to replicate a relational schema. MongoDB Atlas works best by leveraging embedding for related data and avoiding unnecessary joins. It is also important to invest early in proper indexing because performance on MongoDB Atlas is heavily dependent on how well queries are supported by indexes. One more thing to tell others is to plan for scaling and sharded key selection upfront if you expect large data volumes since changing it later can be complex.

Overall, I want to say MongoDB Atlas is very powerful, but getting the best out of it requires thoughtful data modeling, indexing, and planning for scaling from the beginning. My review rating for MongoDB Atlas is 9 out of 10.

I still have recent experience with MongoDB Atlas as I have a contact with a representative for Brazil.

Azure and OCI are what we use as our main cloud providers.

I have hands-on experience with OCI, although I don't have a cloud for MongoDB Atlas; I have a cloud for databases and DevOps.

I don't develop directly with only MongoDB Atlas. However, I know the organization has a license with the product.

It's a very elastic solution for the purposes of our systems and the developers appreciate it for software development.

MongoDB Atlas's encryption capabilities help ensure data confidentiality and integrity.

I believe the software has performed well for us regarding data confidentiality and integrity.

I would say pricing is an area where MongoDB Atlas could improve.

I don't have extensive experience with Linux products since it's not my area in my organization.

I believe the support is very good because I don't have a problem with the availability of the software.

I am aware of the horizontal scaling capability.

I would be willing to provide a review for one of the Oracle solutions or other solutions such as Linux as we have a Linux server, X8H56. OCI is the server name I remember, it's OCP.

Positive

Our main cloud provider is Azure, not AWS.

We have MongoDB Atlas; MongoDB Atlas is what we use.

I have tried to use Coherence, but it was a bad experience for us.

I didn't purchase MongoDB Atlas through AWS Marketplace; I only have a MongoDB Atlas license, not AWS.

I have no idea about the pricing or setup cost with MongoDB Atlas.

I find it easy to use.

I think it's a good product.

I have no idea about the pricing or setup cost with MongoDB Atlas.

We have MongoDB Atlas; MongoDB Atlas is what we use.

I am only familiar with databases and applications. I am from the development team and I am a user of database and cloud but I don't know the infrastructure.

As a user, I deal with the Oracle Database.

I know the organization has a license with the product.

We don't utilize real-time analytics with MongoDB Atlas.

I don't use MongoDB Atlas directly, so I don't know how it can be improved.

I would place MongoDB Atlas at a medium level. I would rate it at a six or seven. I believe MongoDB Atlas can improve a little. My overall review rating for this product is six out of ten.

MongoDB Atlas serves as our primary database for storing data. We utilize MongoDB Atlas as our main database solution, which provides us with free space to work with and some MB of free storage. When working with Express.js code as our backend, storing data in JSON format is not required, unlike the problem encountered with SQL. Once we require unstructured data, that is what we use MongoDB Atlas for, and it also frees up some of the memory and storage, so it works very well for our use cases. MongoDB Atlas has free storage that allows us to work with the tools and understand them better. I have highlighted several aspects of this solution.

MongoDB Atlas impacts our organization positively as it is our primary source of working, and we work on multiple client projects to demonstrate at least a demo to them. MongoDB Atlas works very well in our organization. When discussing one of the projects on MongoDB Atlas, the UI is very aesthetically pleasing; we do not have to go and deploy some RDS or other solutions. The cluster is already there; we just have to log in and start working on it. Additionally, there is a simple connection string that allows us to manage security as well. MongoDB Atlas UI facilitates managing security, and there is IP address tracking available, which we can specify. It is separate from others, and I would say the scalability is also very good—the ability to scale the database directly is excellent and does not require server adjustments.

During my development phase, this is very good and easy to understand, which is beneficial if anyone new comes on board.

The best feature I would say is that there is free storage, which any NoSQL database provides, such as MongoDB Atlas. Apart from that, there is a very good MongoDB Atlas UI where we can see the cluster, databases, and all these features. When we are using it, the transactions go for real-time processing. These are the features that it offers us, and the connection is very good to any framework we are using in the backend.

MongoDB Atlas is our primary database, and we prefer this because of the reliability of MongoDB Atlas. The UI is very good for Atlas, and the non-structured database is advantageous because we do not have required schema restrictions. The cluster management and the database handling of Atlas are very good. By using the UI, we can manage this efficiently, and these are the features on MongoDB Atlas that give us what we need.

I do not find any necessary improvements for MongoDB Atlas; it is already good at handling tasks, and we have a local compass as well. There is no disturbance with MongoDB Atlas; it operates well. The UI is good, although I have checked one aspect in MongoDB Atlas: when we make transactions, they do not process in real-time and require a refresh. I attribute this delay to a minor browser issue, but overall, the compass is already integrated, so I do not see any improvements needed.

I have been working here for more than three years.

MongoDB Atlas is stable.

MongoDB Atlas scalability is very good.

I have not reached out to customer support, as I have not encountered any problems, so I have not needed to contact them.

I have previously used multiple SQL databases, and I encountered problems in the deployment phase, which often required purchasing services such as RDS or others to deploy SQL databases, leading to additional costs. MongoDB Atlas defines a GUI aspect and database storage advantage.

My experience with pricing, setup cost, and licensing is that the pricing is very good, and the setup is very good as well. Licensing for the basic version is free, which is a benefit, although the pricing increases significantly when we use many features. We can also mitigate costs a little by sharing and scaling; these aspects are good in MongoDB Atlas.

I evaluated other options before choosing MongoDB Atlas, primarily focusing on SQL databases, and I encountered deployment problems with them, particularly regarding the necessity to purchase services for RDS. MongoDB Atlas resolved these issues.

I would advise others looking into using MongoDB Atlas to note that it is very cost-efficient, and I suggest trying it ourselves. Whitelisting APIs and IPs is a straightforward process, and these are features of MongoDB Atlas worth exploring. MongoDB Atlas is deployed as its own cloud solution, and there is no SS deployment; it is already clustered within MongoDB Atlas. In our organization, I would say it operates in a private cloud setup. I give this product a review rating of ten out of ten.

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.

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.

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. 

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.

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.

MongoDB Atlas is a schema-less database.

MongoDB Atlas is very easy to use and user-friendly, and you get what you're paying for. MongoDB Atlas is very easy to use when you are familiar with MongoDB and how to write query functions. I would give the solution a nine out of ten for usability.

MongoDB Atlas should improve its user experience by providing better explanations or a wizard for people working with its UI. The solution should include a query builder that will help people who aren't developers get data.

I have been using MongoDB Atlas for two years.

MongoDB Atlas is a stable solution.

MongoDB Atlas is a scalable solution. Around ten people were working with the solution in my organization.

The solution's initial setup is straightforward.

MongoDB Atlas provides good value for money. MongoDB Atlas is not expensive, and since it's a cloud-based solution, you pay by usage.

MongoDB Atlas is a cloud-based solution. The solution's installation, setting up, and integration are relatively easy. MongoDB Atlas provides the functionalities it promises.

Users should focus on the technical design and figure out how they want the data, what data scheme they're aiming for, how to build properly, and how to design data properly. For everything else, they provide you with enough tools to understand what you're doing pretty much by yourself.

Overall, I rate MongoDB Atlas a nine out of ten.