> For the complete MongoDB documentation index, see www.mongodb.com/docs/llms.txt # Guidance for Atlas Scalability ## Features for Atlas Scalability Auto-scaling enables clusters to automatically adjust their tier, storage capacity, or both, in response to real-time use. Atlas uses complementary auto-scaling mechanisms: - **Reactive auto-scaling** analyzes current CPU and memory utilization to trigger scaling events based on sustained high or low resource usage. Reactive auto-scaling occurs after workload changes and handles both upscaling and downscaling. - **Predictive auto-scaling** uses machine learning to anticipate future scaling needs based on historical usage patterns and attempts to scale up before cyclical workload spikes that it forecasts will arrive. Predictive auto-scaling is available for [eligible clusters](https://www.mongodb.com/docs/atlas/cluster-autoscaling-compute-core.md#std-label-eligible-clusters-predictive-autoscaling) and supports only upscaling. Downscaling remains reactive. See [Cluster tier scaling](https://www.mongodb.com/docs/atlas/cluster-autoscaling.md#std-label-cluster-autoscaling) to learn more about the conditions under which Atlas scales your cluster nodes up or down. You can also specify a range of maximum and minimum cluster sizes that your cluster can automatically scale to in order to guarantee minimum performance or control costs. Atlas generally won't scale a cluster if scaling would result in a tier that falls outside of your specified size range, though cluster tier and storage might scale in parallel if disk needs require it. Atlas also won't scale if your memory or CPU usage would exceed the capacity of the scaled tier. Auto-scaling is best suited for steadily growing or declining application loads and cyclical workload patterns. For unexpected, one-time traffic spikes such as product launches or unprecedented events, pre-scale programmatically. Reactive auto-scaling introduces a throttled delay to prevent application impact, and predictive auto-scaling handles only recurring patterns. Atlas deployment templates, as referenced in the [Recommended Deployment Topologies](https://www.mongodb.com/docs/atlas/architecture/current/deployment-paradigms.md#std-label-arch-center-deployment-topologies), provide you with horizontal and vertical scaling options. Specifically, sharding distributes data across numerous machines, which is useful when no single server can handle your workloads. Sharding follows a shared-nothing architecture, a distributed computing architecture where none of the nodes share any resources with each other. See [Choose a Shard Key](https://www.mongodb.com/docs/manual/core/sharding-choose-a-shard-key/) to learn more about the ideal choice of shard key that allows MongoDB to distribute documents evenly throughout your cluster while facilitating common query patterns. Furthermore, see [Performance Best Practices: Sharding](https://www.mongodb.com/blog/post/performance-best-practices-sharding) to learn about the key sharding strategies, such as ranged sharding, hashed sharding, and zoned sharding. Upgrading an Atlas cluster to the next available Atlas tier is available through the Atlas control plane GUI, the [Atlas Administration API](https://www.mongodb.com/docs/atlas/reference/api-resources-spec/v2/#tag/Clusters/operation/upgradeSharedCluster), or through IaC tools, such as the Atlas Kubernetes Operator, the MongoDB & HashiCorp Terraform, or the Atlas CLI. See [Guidance for Atlas Automated Infrastructure Provisioning](https://www.mongodb.com/docs/atlas/architecture/current/automation.md#std-label-arch-center-automation) to learn more. Changing an Atlas tier, either upscaling or downscaling, allows zero downtime. The tier changes in a rolling fashion, which involves electing a secondary member as a replacement, promoting this secondary member to become the new primary, then restoring or replacing the failing member to ensure that the cluster is returned to its target configuration as soon as possible. Horizontal scaling occurs post-deployment based on Administrator action, which can be triggered from a programmatic script. Some cluster templates require sharded clusters. Starting with MongoDB version 8.0, you may make use of [embedded config servers](https://www.mongodb.com/docs/manual/reference/command/transitionFromDedicatedConfigServer/) to reduce costs associated with config servers on small sharded clusters. The low CPU option in Atlas helps applications that require higher memory but not as much processing power. This option provides instances with half the vCPUs compared to the General tier of the same cluster size, reducing costs for workloads that are memory-intensive but not CPU-bound. Data tiering and archival allows you to archive data in low-cost storage while still enabling queries alongside live cluster data, which is particularly useful for long-term record retention. To optimize this process, MongoDB recommends that you automate data archiving with simple, configurable rules. See [Archive Data](https://www.mongodb.com/docs/atlas/online-archive/manage-online-archive.md#std-label-manage-online-archive) to learn more about the criteria that you can specify in an archiving rule. For scenarios where data retention is not a priority, Atlas offers the option to automatically delete unused data based on date criteria. For infrequently accessed data, [TTL indexes](https://www.mongodb.com/docs/manual/core/index-ttl/) are special single-field indexes that automatically delete documents from a collection after a specified period or at a set clock time. This is particularly useful for data like logs, session information, or event data that only needs to be retained for a limited time. To create a TTL index, you can define an index on a field that holds date values and specify a time-to-live duration in seconds. Atlas also provides you with automated tools, such as the [Performance Advisor](https://www.mongodb.com/docs/ops-manager/current/tutorial/performance-advisor/), to identify and optimize inefficient queries by adding or removing an index or changing your client's query structure. You can reduce unnecessary compute time and resource consumption by following Performance Advisor's actionable recommendations to enhance your query performance. Additionally, you can leverage intelligent index recommendations provided by Atlas to further improve data retrieval efficiency and minimize the resources needed for database operations. ## Recommendations for Atlas Scalability ### Single-Region Deployment Recommendations #### Recommendations that apply only to deployments in a single region For single-region deployments, focus on vertical scaling strategies that optimize performance within a single cloud region: - Enable auto-scaling for both compute and storage to handle gradual traffic increases without manual intervention. - Use sharding when your dataset exceeds the capacity of a single server, even within a single region, to distribute load across multiple shards. - Consider the low CPU instance option for memory-intensive workloads that do not require high processing power. - Implement data tiering and archival for historical data to reduce storage costs while maintaining query capabilities. - Monitor query performance with the Performance Advisor and implement recommended indexes to optimize resource utilization. - For one-time events such as product launches or unprecedented traffic spikes, pre-scale clusters programmatically before the event. Auto-scaling relies on either recurring cyclical workloads or responds after the workload change occurs, both of which might not work in your case. ### Multi-Region and Multi-Cloud Deployment Recommendations #### Recommendations that apply only to deployments across multiple regions or multiple cloud providers For multi-region and multi-cloud deployments, implement scaling strategies that account for geographic distribution and cross-cloud complexity: - Configure read replicas in regions closest to your users to reduce latency and distribute read workloads geographically. - Use zone sharding to partition data based on geographic or logical boundaries, ensuring data locality and compliance requirements. - Implement global clusters with local reads and writes to optimize performance across regions while maintaining data consistency. - Monitor network latency between regions and adjust replica priorities to ensure optimal failover behavior. - Consider the impact of cross-region data transfer costs when implementing auto-scaling across multiple regions. - Use different cluster tiers in different regions based on regional usage patterns and cost optimization strategies. - Implement region-specific backup and archival strategies to comply with data residency requirements. ### All Deployment Paradigm Recommendations The following recommendations apply to all [deployment paradigms.](https://www.mongodb.com/docs/atlas/architecture/current/deployment-paradigms.md#std-label-arch-center-paradigms) For development and testing environments, do not enable auto-scaling compute and auto-scaling storage. This saves costs in your non-production environments. For staging and production environments, we recommend that you: - Enable auto-scaling for compute and storage. When you enable auto-scaling, Atlas automatically uses both reactive and predictive autoscaling to scale up your clusters. Reactive auto-scaling triggers based on current resource usage. Predictive auto-scaling analyzes historical usage patterns and proactively scales up your cluster before cyclical demand spikes that it forecasts. Downscaling remains reactive for both approaches. To learn more, see [Predictive Auto-Scaling for Cluster Tier.](https://www.mongodb.com/docs/atlas/cluster-autoscaling-compute-core.md#std-label-predictive-autoscaling-overview) - If you use IaC (Infrastructure as Code) tools, leverage settings to ignore resource drift caused by auto-scaling. For example, in Terraform, if `disk_gb_enabled` is true, Atlas will automatically scale disk size up and down. This will cause the value of `disk_size_gb` returned to potentially be different than what is specified in the Terraform config and if one then applies a plan, not noting this, Terraform will scale the cluster disk size back to the original `disk_size_gb` value. To prevent this, use `use_effective_fields = true`. - Similarly, in Terraform, if `compute_enabled` is true, then Atlas will automatically scale up to the maximum provided and down to the minimum, if provided. This will cause the value of `provider_instance_size_name` returned to potentially be different than what is specified in the Terraform config, and if one then applies a plan, not noting this, Terraform will scale the cluster back to the original `instanceSizeName` value. To prevent this, use `use_effective_fields = true`. `use_effective_fields = true`. ## Automation Examples: Atlas Scalability **Tip:** For Terraform examples that enforce our recommendations across all pillars, see one of the following examples in GitHub: - [Staging/Prod](https://github.com/mongodb/docs/blob/main/content/atlas-architecture/current/source/includes/examples/tf-staging-prod-complete/) - [Dev/Test](https://github.com//mongodb/docs/blob/main/content/atlas-architecture/current/source/includes/examples/tf-dev-test-complete/) The following examples enable auto-scaling compute and storage using Atlas [tools for automation.](https://www.mongodb.com/docs/atlas/architecture/current/automation.md#std-label-arch-center-automation) These examples also apply other recommended configurations, including: ### Dev and Test Environments - Cluster tier set to `M10` for a dev/test environment. Use the [cluster size guide](https://www.mongodb.com/docs/atlas/architecture/current/hierarchy.md#std-label-arch-center-cluster-size-guide) to learn the recommended cluster tier for your application size. - Single Region, 3-Node Replica Set / Shard deployment topology. Our examples use AWS (Amazon Web Services), Azure (Microsoft Azure), and Google Cloud interchangeably. You can use any of these three cloud providers, but you must change the region name to match the cloud provider. To learn about the cloud providers and their regions, see [Cloud Providers.](https://www.mongodb.com/docs/atlas/reference/cloud-providers/) ### CLI **Note:** Before you can create resources with the Atlas CLI, you must: - [Create your paying organization](https://www.mongodb.com/docs/atlas/billing/#configure-a-paying-organization) and [create an API key](https://www.mongodb.com/docs/atlas/configure-api-access/) for the paying organization. - [Install the Atlas CLI](https://www.mongodb.com/docs/atlas/cli/current/install-atlas-cli/) - [Connect from the Atlas CLI](https://www.mongodb.com/docs/atlas/cli/current/connect-atlas-cli/) using the steps for Programmatic Use. ### Create One Deployment Per Project ### Dev and Test Environments For your development and testing environments, auto-scaling compute and storage is disabled to save costs. For more configuration options and info about this example, see [atlas clusters create.](https://www.mongodb.com/docs/atlas/cli/current/command/atlas-clusters-create.md#std-label-atlas-clusters-create)