On this page

Can I bring an existing MongoDB deployment into MongoDB Atlas for management?

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

  • You can use the Live Migrate feature in Atlas to migrate from a source replica set to an Atlas replica set cluster.
  • You can use the Live Migrate feature in Atlas to migrate from a source sharded cluster to an Atlas sharded cluster.
  • You can use mongomirror to migrate data from an existing MongoDB replica set into MongoDB Atlas.
  • You can use mongodump and mongorestore to seed MongoDB Atlas clusters from an existing standalone, replica set, and sharded cluster.

For information, see Migrate or Import Data into Your Cluster.

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

Which versions of MongoDB does Atlas use for the clusters?

Atlas supports creating M10+ dedicated tier clusters with the following MongoDB versions:

  • MongoDB 3.6
  • MongoDB 4.0
  • MongoDB 4.2

M0 Free Tier and M2/M5 shared-tier clusters only support MongoDB 4.0.

As new maintenance releases become available, Atlas automatically upgrades to these releases via a rolling process to maintain cluster availability.

To learn more about how Atlas handles end of life of major MongoDB versions, see What happens to Atlas clusters using a MongoDB version nearing end of life?.

What happens to Atlas clusters using a MongoDB version nearing end of life?

Unsupported MongoDB Versions in Atlas

Atlas no longer supports MongoDB 3.2 and earlier.

MongoDB sends you an email notification at least six months before the MongoDB version reaches end of life. A few months after you receive this notification, Atlas:

  • Stops allowing you to deploy new clusters using the end of life version.
  • Notifies you of the version cut-off date. After the cut-off date, Atlas upgrades your clusters to the next MongoDB version unless you request and receive approval for an extension.


When MongoDB 3.4 reaches end of life, Atlas upgrades each of your clusters running MongoDB 3.4 to MongoDB 3.6.

This upgrade happens within your maintenance window if you configured one in your project settings.

In most cases, this upgrade won’t cause downtime or negatively affect your applications. You should upgrade your cluster before the cut-off date to ensure that your services and applications experience no downtime or other issues due to incompatibilities with the new MongoDB version.

To learn about potential issues for the cluster when upgrading MongoDB versions, see Compatibility Changes in the MongoDB Release Notes for the next MongoDB version.

See also

To review the end of life date for each MongoDB Server release, see MongoDB Server in the MongoDB Support Policy.

When does MongoDB upgrade the database version free and shared tier clusters use?

Atlas upgrades free and shared tier clusters to the newest MongoDB version after several patch versions become available for that version. To learn more about how MongoDB versions its software, see MongoDB Versioning.

Can I migrate between regions?

Yes. You can change one or more regions for a given cluster within the original cloud service provider for that cluster. Using a rolling-migration strategy for moving nodes from the original region to a new region, MongoDB Atlas preserves 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. However, the moved cluster may use a peering connection already defined in the new region. See Set up a Network Peering Connection for complete documentation.

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

Does Atlas support cross-region deployments?

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

Atlas does not support cross-cloud service provider deployments.

How many cross-region network permissions does Atlas support?

For a given region in an Atlas project with multi-region clusters or clusters in multiple regions, there is a limit of 40 MongoDB nodes on all other regions in that project. This limit applies across all cloud service providers and can be raised upon request. GCP regions communicating with each other do not count against this limit.


If an Atlas project has 20 nodes in Region A and 20 nodes in Region B, you can deploy no more than 20 additional nodes in that project in any given region. This limit applies even if Region A and Region B are backed by different cloud service providers.

For Atlas projects where every cluster is deployed to a single region, you cannot create a multi-region cluster in that project if there are already 40 or more nodes in that single region unless you request that the limit be raised.

Please contact Atlas support for questions or assistance raising this limit. To contact support, click Support from the left-hand navigation bar of the Atlas UI.

If you would exceed the cross-region permissions limit when creating a cluster through the Atlas API, the API returns the following error:

{"error":403,"detail":"Cannot have more than 40 cross-region network permissions.","reason":"Forbidden"}

What are Analytics Nodes?

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 is 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.

What AWS Regions does Atlas support?

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

How does MongoDB Atlas deliver high availability?

Atlas clusters use MongoDB’s replication capability to deliver high availability. All Atlas clusters are either replica sets or sharded clusters where each shard is a replica set. For complete documentation on 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 a 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.

Retryable Writes with MongoDB 3.6

MongoDB 3.6+ drivers can automatically retry certain write operations a single time. Retryable writes provide built-in handling of automatic failovers and elections. The cluster must run MongoDB 3.6 or greater to support retryable writes. See retryable writes for complete documentation and requirements.

To enable this feature, add retryWrites=true to your Atlas URI connection string. See Connect via Driver for details on connecting to a Atlas cluster using a URI connection string.

For M10+ clusters, Atlas provides a Test Failover feature for application developers to check that their applications are designed to detect and react appropriately to a replica set election. By designing applications that can seamlessly handle a replica set election, developers no longer have to worry about the underlying maintenance occurring on their clusters.

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

Please contact MongoDB support if you would like help architecting your application to use MongoDB Atlas with optimal availability.

How can I pay for MongoDB Atlas without a credit card?

For alternative ways of purchasing Atlas, please contact MongoDB Inc..

Can I specify my own VPC for my MongoDB Atlas project?

No. An Atlas project, and its clusters, are associated with a region-specific Virtual Private Cloud (VPC).

Atlas creates a VPC when you deploy the first M10+ dedicated paid cluster to a given provider and region. For multi-region clusters, Atlas creates one VPC per region if there is not already a VPC for that region.

(AWS deployments only) Atlas also creates a VPC when you create a VPC peering connection to an AWS VPC. Atlas creates the VPC in the same region as the peered VPC.

To use a different VPC (e.g. on the customer’s own cloud infrastructure accounts), you would need to use MongoDB Cloud Manager or Ops Manager.

MongoDB Atlas or MongoDB Cloud Manager?

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 is best suited for 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.

Please contact MongoDB support for guidance on which MongoDB service best suits the needs of your organization.

As an existing MongoDB Cloud Manager account holder, how do I create a new MongoDB Atlas project?

In the Context drop down in Cloud Manager, select New Project.

The Create a New Project screen provides you the choice to create either an Atlas project or a Cloud Manager project. Select MongoDB Atlas and continue with the creating the project.

As an existing Atlas account holder, how do I create a new Atlas project?

In the Context drop down in Cloud Manager, select New Project.

The Create a New Project screen provides you the choice to create either an Atlas project or a Cloud Manager project. Select MongoDB Atlas and continue with the creating the project.

Can I disable SSL/TLS on my deployment?


How do I remove my project?

You can remove a project if:

  • You have the Project Owner role for the project.
  • The project has no outstanding invoices.
  • The project has no active clusters.

To delete a project for an organization, you can delete from the organization’s Projects view or the project’s Project Setting view. For details, see Delete a Project.

Can I pause or stop my Atlas clusters?

You can pause an M10+ paid cluster for up to 7 days at a time. Atlas automatically resumes the cluster after 7 days. For complete documentation, see Pause a Cluster.

How do I modify alerts?

To modify existing alert settings:

  1. Click Alerts in the Project section of the left navigation.
  2. Click Alert Settings.
  3. Click the ellipsis ... next to the alert you want to modify (edit, clone, disable, delete).

Does MongoDB Atlas expose the oplog?

Yes, for M10 tiers or greater.

See Oplog Access for details on accessing your cluster’s oplog.

Can MongoDB Atlas deploy clusters with more than 50 shards?

While MongoDB Atlas out of the box allows selection of up to 50 shards, customers interested in more than 50 shards should inquire with MongoDB. Contact us.

How does Atlas encrypt my data?

Atlas uses whole volume (disk) encryption for any data at rest, including your cluster data and backups of that data.

Atlas also requires TLS encryption for client data and intra-cluster network communications.

If your organization requires more specific information regarding Atlas encryption, please contact Atlas support. From the Atlas project or cluster view, click Support in the left-hand navigation bar.

Can I pre-split chunks in a Atlas sharded cluster?

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

See Create Chunks in a Sharded Cluster for complete documentation on sharded cluster chunk creation and management.

Is there a maximum number of collections allowed on a single Atlas cluster?

While there is no hard limit on the number of collections in a single cluster, the performance of a cluster may degrade if it serves larger numbers of collections and indexes. Larger collections have a greater impact on performance.

The recommended maximum number of collections and indexes by Atlas cluster are as follows:

  • M10: 5,000 collections and indexes
  • M20 / M30: 10,000 collections and indexes
  • M40+: 100,000 collections and indexes

Where can I view the system status of the MongoDB Cloud?

Visit for the status of the MongoDB Cloud, including Atlas and Cloud Manager.

You can also subscribe to an RSS feed of the MongoDB Cloud Status page using your preferred RSS reader.

What versions of TLS does Atlas support?

Atlas deployments created after July 2018 support only Transport Layer Security (TLS) protocol versions 1.1 and 1.2 by default. Atlas deployments created before July 2018 support TLS protocol version 1.0, 1.1, and 1.2 by default. After August 2018, Atlas will support only TLS 1.1 and 1.2 by default for all Atlas clusters.

Deprecating TLS 1.0 improves your security of data-in-transit and aligns with industry best practices. This is why MongoDB 4.0 requires TLS 1.1 or later when TLS is enabled. As Atlas requires TLS connections for all Atlas clusters, Atlas clusters running MongoDB 4.0 always use TLS 1.1 or later by default.

You can read more about timing and reasons for the change from the Payment Card Industry (PCI) as well as the National Institute of Standards and Technology (NIST).

If you have questions about TLS support or cannot update your applications to support TLS 1.1 or later by late August 2018, please contact Atlas support.

To open a Atlas support ticket, log into the your Atlas account. Click the Support link in the Atlas UI and fill in the requested details.

How do I know if my applications support TLS 1.1 or later?

TLS 1.1 was defined in April 2006. Applications whose underlying programming languages or security libraries predate TLS 1.1 may require updating to a more recent version to support TLS 1.1 or later. You may also need to update the application host operating system to support TLS 1.1 or later.

MongoDB and Atlas do not provide services to audit external applications for which versions of TLS support they support. Third party services such as may provide the appropriate tooling. MongoDB does not endorse the aforementioned service, and its reference is intended only as informational. Defer to your organization’s procedures in selecting the appropriate vendor or service for auditing your applications to ensure TLS 1.0 is disabled.

What do I have to do to update my clusters for TLS 1.1 or later?

Atlas will automatically update your existing clusters to only support TLS 1.1 or later in late August 2018. The only thing you should consider doing is auditing your applications for support of TLS 1.1 or later and updating any components of your technology stack that do not support TLS 1.1 or later.

Can I force enable TLS 1.0?

Atlas allows users to manually enable TLS 1.0 during cluster creation and cluster modification.

Enabling TLS 1.0 for any Atlas cluster carries significant risks. Consider enabling TLS 1.0 only for as long as required to update your application stack to support TLS 1.1 or later.

What happens when I reach my Atlas storage limit?

The result of reaching your Atlas storage limit depends on the Atlas cluster you are using.

  • For shared clusters (M0, M2, M5), the maximum storage is a hard limit and cannot be exceeded. You can add additional storage by upgrading to a dedicated cluster (M10+). For details on how Atlas calculates storage limits for shared clusters, see this section of the FAQ.
  • By default, M10+ clusters auto-expand storage based on disk usage thresholds. To modify this setting to a fixed storage limit, refer to the Modify a Cluster page.

If you attempt to write to a shared cluster that does not have space for the desired write operation, Atlas displays an error message similar to the following:

  "writeError": {
    "code": 8000,
    "errmsg": "you are over your space quota, using 513 MB of 512 MB"

For more information on the differences between shared and dedicated clusters, see Atlas M0 (Free Tier), M2, and M5 Limitations.


You can configure alerts which trigger once your allocated storage reaches a specified threshold. Atlas calculates allocated storage using metrics returned by the dbStats() command. For information on storage alerts, see DB Storage alert conditions.

How does Atlas calculate storage limits for shared clusters (M0, M2, M5)

Atlas calculates the storage limit for shared clusters based on data usage, as opposed to the storageSize metric used by non-shared clusters (which includes compression). Atlas determines data usage by summing a cluster’s dataSize and indexSize. You can issue the db.stats() method to view the values of these fields.

Why has Atlas stopped monitoring my cluster?

Atlas pauses monitoring for M0 Free Tier clusters which have had no connection activity for 7 days. Monitoring resumes once a successful connection occurs through the Atlas API, Driver, mongo shell, or Data Explorer.

How do I get support for my Atlas clusters?

You can request support through the Atlas UI by using the in-app chat or by opening a support case. Support for development and performance of the database requires an upgraded support plan. For more information on support plans, contact MongoDB Inc..

How do I delete my user account?

To delete your Atlas account, take the following action based on your Support Plan:

Support Plan Action
Basic In the lower right corner of the Atlas UI, click the chat icon to speak with a MongoDB Support representative.
Developer In the lower right corner of the Atlas UI, click the chat icon to speak with a MongoDB Support representative or open a private support case.
Premium In the lower right corner of the Atlas UI, click the chat icon to speak with a MongoDB Support representative or open a private support case.
A screenshot of the chat icon in the |service| UI.


You cannot reuse the email address that is associated with the deleted account to create a new Atlas account.

See Request Support for more information.

How do I get my Atlas-side hostnames so that I can open up my outbound firewall?

If your firewall blocks outbound network connections, you must open outbound access from your application environment to MongoDB Atlas. To configure your application-side networks to accept Atlas traffic you can either use the:

You can parse these hostname values and pass the IP addresses programmatically into your application-tier orchestration automation to push firewall updates.

To find the public IP address for any node in your cluster, use the nslookup tool from the command line. The IP address is shown in the Address portion of the output.

$ nslookup


Do Atlas clusters’ public IPs ever change?

An Atlas cluster’s public IPs do not change when:

  • The cluster is vertically scaled.
  • The cluster is unpaused.
  • The cluster’s topology changes.
  • The cluster is terminated then re-deployed with the same name within 36 hours.
  • A maintenance event occurs.
  • A healing event occurs.

An Atlas cluster’s public IP addresses must change when you:

  • Change a replica set to a sharded cluster.
  • Add shards to a sharded cluster.
  • Change the region(s) into which a cluster is deployed.

To find the public IP address for any node in your cluster, use the nslookup tool from the command line. The IP address is shown in the Address portion of the output.

$ nslookup


Why did my Atlas payment fail?

Payments will fail if there is an issue with your Payment Method. To learn how to verify your Payment Method and retry your payment, see Retry a Failed Payment.

Customers in the European Economic Area (EEA) may experience payment failures due to Strong Customer Authentication (SCA), a European regulatory requirement. To learn how to authenticate a credit card and comply with SCA, see Strong Customer Authentication (SCA).

How can I reduce my data transfer costs?

There are a number of ways to optimize data transference depending on the configuration of your project. See How to Reduce Data Transfer Costs on the Billing page for a list of common options.

Without using Provisioned IOPS on MongoDB Atlas on AWS, what kind of IOPS should I expect?

Atlas provides an estimate of how many 16K IOPS you can expect, calculated as the lesser of 3 IOPS per provisioned GB, or the cluster node’s maximum IOPS capacity.

However, non-provisioned IOPS on AWS can burst above this estimate or drop below it. As a result, customers who are interested in consistent IOPS throughput should consider leveraging Provisioned IOPS.

Which certificate authority signs MongoDB Atlas cluster TLS certificates?

The MongoDB Atlas TLS certificate will change on February 25, 2020.

MongoDB Atlas is moving to Let’s Encrypt as the new Certificate Authority (CA) for TLS certificates for all Atlas clusters.

All newly created M10+ Atlas clusters already utilize the new certificates and can be used to test connectivity.

Please review the following scenarios to ensure that you will not experience connectivity issues:

Hard-coded Certificate Authority

If you hard-coded the DigiCert root CA as the only trusted CA utilized for your application’s connection to Atlas, please ensure that you add the Let’s Encrypt root CAs to your certificate store. Add both of the following root CAs for Let’s Encrypt:

Java Users

Let’s Encrypt is not present in the default trust store for Java version 7 prior to the 7u111 update, or Java version 8 prior to the 8u101 update. Instead, you must use a Java release after July 19, 2016.

Please ensure your Java client software is up-to-date. The latest Java versions are strongly recommended for many improvements beyond these new CA requirements for our TLS certificates.

If you have your own trust store, you will need to add the Let’s Encrypt certificate to it. To learn more, see Hard-coded Certificate Authority.

Everyone Else

You should not be impacted by this change if you use a recent programming language and operating system version.