Docs Menu
Docs Home
MongoDB Atlas
/ /

FAQ: Deployment

On this page

  • MongoDB Atlas or MongoDB Cloud Manager?
  • Can I bring an existing MongoDB deployment into MongoDB Atlas for management?
  • Can I migrate between regions?
  • Does Atlas support cross-region deployments?
  • What AWS regions does Atlas support?
  • Can I pause or stop my Atlas clusters?
  • Can I pre-split chunks in a Atlas sharded cluster?
  • Can MongoDB Atlas deploy clusters with more than 50 shards?
  • How does MongoDB Atlas deliver high availability?
  • What are Analytics Nodes?
  • Why can't I submit another disk storage change request?

Atlas offers a managed and simplified experience. Atlas users have access to a curated selection of configuration and infrastructure options. The available Atlas configuration and infrastructure options may not provide the flexibility that some users require. For example, Atlas requires TLS for cluster connectivity and does not surface options for disabling TLS. Atlas suits users who want fewer moving parts to manage, enabling developers and database administrators to be more productive.

MongoDB Cloud Manager offers more control by exposing more configuration options on the infrastructure of your choice. Cloud Manager users have access to advanced operations and a higher level of control, but must manage the full lifecycle of their infrastructure. Cloud Manager is best suited for users who require a higher level of control over their MongoDB clusters.

For guidance on which MongoDB service best suits the needs of your organization, contact MongoDB Support.

No. However, you can upload data from existing MongoDB deployment into MongoDB Atlas.

To learn more, see Migrate or Import Data.

You can also write scripts using official MongoDB supported drivers to upload data.

Yes. You can change one or more regions for a given cluster within the original cloud service provider or across different cloud service providers. MongoDB Atlas uses a rolling-migration strategy for moving nodes from the original region to a new region to preserve cluster availability.


AWS Only

Amazon Web Services (AWS) Virtual Private Cloud (VPC) peering connections are region-specific. Clusters utilizing an existing VPC peering connection to an AWS VPC in a given AWS region lose access to that peering connection if moved to a different AWS region. The moved cluster may use an existing peering connection in the new region.


If you need to migrate data between regions on different cloud service providers, you can:


  • When you transition to a new cloud provider, your deployment IP addresses change.

  • Data migration interrupts VPC peering and private endpoint operation. You must reconfigure these after completing migration.

  • Adding or moving a node to a new region or cloud provider without a primary or secondary node requires each newly migrated replica set member to perform an initial sync.

  • If you created an Atlas cluster on Google Cloud or Microsoft Azure before November 2, 2020 when Atlas added support for multi-cloud clusters, changing to a different provider changes the connection string to your new cluster. Consider scheduling a time to update your applications with the new connection string to connect to the cluster again.

Yes. You can specify additional regions for high availability or local reads when creating or scaling a deployment.

Atlas supports cross-cloud service provider deployments. To learn more, see Electable Nodes for High Availability.

Atlas supports all AWS regions other than those in China and US GovCloud. To learn more, see Amazon Web Services (AWS).

You can pause an M10+ paid cluster for up to 30 days at a time. Atlas automatically resumes the cluster after 30 days.

The Atlas admin database user role has the necessary privileges to pre-split chunks in an empty sharded collection.

To learn more about sharded cluster chunk creation and management, see Create Chunks in a Sharded Cluster.

Yes, MongoDB Atlas allows selection of up to 100 shards. If you're interested in more than 100 shards, contact MongoDB Support.

Atlas clusters use replication capability of MongoDB to deliver high availability. All Atlas clusters are either replica sets or sharded clusters where each shard is a replica set. To learn more about MongoDB replica sets and replication, see Replication.

Atlas uses a rolling upgrade strategy for executing maintenance or infrastructure operations, such as applying security patches or scaling up an Atlas cluster. The rolling upgrade strategy ensures that the cluster can process reads and writes for the majority of the maintenance or infrastructure operation. During the rolling upgrade procedure:

  • Atlas applies the changes to each secondary node in the cluster.

  • Atlas directs the primary node to step down to the secondary state and trigger an election of a new primary.

  • Once the cluster has a new primary, Atlas applies the changes to the former primary node.

Applications must hold write operations while the cluster elects a new primary. The cluster can continue to process secondary read operations during this period. Elections on Atlas clusters typically complete within a few seconds. Factors such as network latency may extend the time required for replica set elections to complete, which in turn affects the amount of time your cluster may operate without a primary. These factors are dependent on your particular cluster architecture.

You can enable retryable writes by adding retryWrites=true to your Atlas URI connection string. To learn more, see Retryable Writes.

For M10+ clusters, Atlas provides a Test Primary Failover feature that allows you to check that your applications can detect and react to a replica set election. By designing applications that can seamlessly handle a replica set election, you no longer have to worry about the underlying maintenance occurring on your clusters.

Atlas maintenance operations include OS patches and maintenance patches for the MongoDB database itself. Infrastructure operations include repair operations required to replace faulty infrastructure, and scheduled infrastructure replacements, such as changing the cluster tier.

Contact MongoDB Support for help with architecting your application to use MongoDB Atlas with optimal availability.

Available on M10+ clusters.

Analytics nodes are specialized read-only nodes used to isolate queries which you do not want to affect your operational workload. They are useful for handling analytic data such as reporting queries executed by BI tools.

Analytics nodes and read-only nodes are configured with distinct replica set tags that allow you to direct queries to desired node types and regions. For details on the pre-defined replica set tags implemented by Atlas, see Atlas Replica Set Tags.

You can have up to 50 total nodes on a multi-region cluster. Within that limit there's no maximum number of analytics nodes.

Analytics nodes cannot contribute to a cluster's availability because they cannot participate in elections, or become the primary for their cluster.

If you recently submitted a disk storage change request, AWS requires you to wait 6 hours and for the first request to complete before submitting another disk change request.

← FAQ: Databases