What is MongoDB Atlas?
Who uses MongoDB Atlas?
Why developers like MongoDB Atlas?
Here are some stack decisions, common use cases and reviews by companies and developers who chose MongoDB Atlas in their tech stack.
We went with MongoDB , almost by mistake. I had never used it before, but I knew I wanted the *EAN part of the MEAN stack, so why not go all in. I come from a background of SQL (first MySQL , then PostgreSQL ), so I definitely abused Mongo at first... by trying to turn it into something more relational than it should be. But hey, data is supposed to be relational, so there wasn't really any way to get around that.
There's a lot I love about MongoDB, and a lot I hate. I still don't know if we made the right decision. We've been able to build much quicker, but we also have had some growing pains. We host our databases on MongoDB Atlas , and I can't say enough good things about it. We had tried MongoLab and Compose before it, and with MongoDB Atlas I finally feel like things are in a good place. I don't know if I'd use it for a one-off small project, but for a large product Atlas has given us a ton more control, stability and trust.
Database is at the heart of any technology stack. It is no wonder we spend a lot of time choosing the right database before we dive deep into product building.
When we were faced with the question of what database to choose, we set the following criteria: The database must (1) Have a very high transaction throughput. We wanted to err on the side of "reads" but not on the "writes". (2) be flexible. I.e. be adaptive enough to take - in data variations. Since we are an early-stage start-up, not everything is set in stone. (3) Fast & easy to work with (4) Cloud Native. We did not want to spend our time in "ANY" infrastructure management.
Based on the above, we picked PostgreSQL and MongoDB for evaluation. We tried a few iterations on hardening the data model with PostgreSQL, but realised that we can move much faster by loosely defining the schema (with just a few fundamental principles intact).
Thus we switched to MongoDB. Before diving in, we validated a few core principles such as: (1) Transaction guarantee. Until 3.6, MongoDB supports Transaction guarantee at Document level. From 4.0 onwards, you can achieve transaction guarantee across multiple documents.
(2) Primary Keys & Indexing: Like any RDBMS, MongoDB supports unique keys & indexes to ensure data integrity & search ability
(3) Ability to join data across data sets: MongoDB offers a super-rich aggregate framework that enables one to filter and group data
(4) Concurrency handling: MongoDB offers specific operations (such as findOneAndUpdate), which when coupled with Optimistic Locking, can be used to achieve concurrency.
Above all, MongoDB offers a complete no-frills Cloud Database as a service - MongoDB Atlas. This kind of sealed the deal for us.
Looking back, choosing MongoDB with MongoDB Atlas was one of the best decisions we took and it is serving us well. My only gripe is that there must be a way to scale-up or scale-down the Atlas configuration at different parts of the day with minimal downtime.
We are in the process of building a modern content platform to deliver our content through various channels. We decided to go with Microservices architecture as we wanted scale. Microservice architecture style is an approach to developing an application as a suite of small independently deployable services built around specific business capabilities. You can gain modularity, extensive parallelism and cost-effective scaling by deploying services across many distributed servers. Microservices modularity facilitates independent updates/deployments, and helps to avoid single point of failure, which can help prevent large-scale outages. We also decided to use Event Driven Architecture pattern which is a popular distributed asynchronous architecture pattern used to produce highly scalable applications. The event-driven architecture is made up of highly decoupled, single-purpose event processing components that asynchronously receive and process events.
To build our #Backend capabilities we decided to use the following: 1. #Microservices - Java with Spring Boot , Node.js with ExpressJS and Python with Flask 2. #Eventsourcingframework - Amazon Kinesis , Amazon Kinesis Firehose , Amazon SNS , Amazon SQS, AWS Lambda 3. #Data - Amazon RDS , Amazon DynamoDB , Amazon S3 , MongoDB Atlas
To build #Webapps we decided to use Angular 2 with RxJS
#Devops - GitHub , Travis CI , Terraform , Docker , Serverless
After getting the first 400 registered users at https://tool-seo.com, we have decided to switch from the self-hosted version of MongoDB to MongoDB Atlas This decision was taken in order to reduce the time that we need for the maintenance and optimization of the Database, as well as to avoid server capacity problems as the number of users continue to grow.
When creating small proofs of concept or personal projects with document data models, that require a lot of data storage but don't warrant paying for hosting, I use Atlas because of the 500 MB free tier and ease of setup.
Often paired with AWS Lambda or Google Cloud Functions. MongoDB Atlas
migrated from compose.io. better granular controls over machine hardware. MongoDB Atlas
MongoDB Atlas's Features
- Global clusters for world-class applications. Support for 60+ cloud regions across AWS, Azure, & GCP.
- Secure for sensitive data. Built-in security controls and features to meet your existing protocols and compliance standards.
- Designed for developer productivity. Integrated tools to manipulate, visualize, and analyze your data. Execute code in real time in response to data changes.
- Reliable for mission-critical workload. Highly available with distributed fault tolerance and backup options to meet your data recovery objectives.
- Built for optimal performance. On-demand scaling, resource optimization tools, and real-time visibility into database performance.