On this page
- Select the MongoDB Version of the Cluster
- Choosing a Release Cadence
- Configure Backup Options for the Cluster
- M2/M5 Tier Backup Options
- M10+ Tier Backup Options
- Termination Protection
- Deploy a Sharded Cluster
- About Shard Deployment
- About Config Servers Deployment
- Configure the Number of Shards
- Consideration for Upgrading a Replica Set to a Sharded Cluster
- Enable BI Connector for Atlas
- Read Preferences
- Sampling Settings
- Manage Your Own Encryption Keys
- Configure Additional Options
- View and Edit Additional Settings
- Set Minimum Oplog Window
- Set Oplog Size
- Enforce Index Key Limit
- Enable Logging of Redacted and Anonymized Query Data
- Set Minimum TLS Protocol Version
- Require Indexes for All Queries
- Default Read Concern
- Default Write Concern
- Set Transaction Lifetime
- Set Chunk Migration Concurrency
You can configure the following additional settings for your Atlas cluster.
Atlas supports creating clusters with the following tiers and MongoDB versions:
Supported on Free and Shared Tiers (
Latest Release (auto-upgrades)
If your cluster runs a release candidate of MongoDB, Atlas will upgrade the cluster to the stable release version when it is generally available.
To use a rapid release MongoDB version, you must select Latest Release for auto-upgrades. You can't select a specific rapid release version.
As new patch releases become available, Atlas upgrades to
these releases via a rolling process to maintain cluster
availability. During the upgrade to the next rapid release version,
the cluster card in the Atlas UI Database
Deployments page might show the
FCV of your cluster
instead of the MongoDB version to reflect the features that are
currently available on your cluster.
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?
Before you upgrade your cluster, refer to the current recommended best practices for major version upgrades.
To select the MongoDB version for your cluster, use the dropdown in the Additional Settings section of the cluster form.
You can upgrade an existing Atlas cluster to a newer major MongoDB version, if available, when you scale a cluster. However, you can't downgrade a cluster from one major version to a previous major version.
If your project contains a custom role that uses actions introduced in a specific MongoDB version, you can't create a cluster with a MongoDB version less than that version unless you delete the custom role.
You can set your Atlas clusters to follow either a major release cadence or a rapid release cadence.
Free-tier and shared-tier clusters must follow a major release cadence. You can configure a dedicated-tier cluster to follow a major release cadence by selecting a specific MongoDB version from the dropdown in the Additional Settings section of the cluster form.
Atlas does not automatically upgrade clusters on the major release cadence. You must schedule a manual upgrade to each new major release as it enters general availability.
You can configure a dedicated-tier cluster to follow a rapid release cadence by selecting Latest Release from the dropdown in the Additional Settings section of the cluster form.
You can configure a cluster for rapid releases only if it is running the most recent major release of MongoDB. If your cluster is running a prior major release, manually upgrade to the most recent major release to enable the transition to rapid release.
Atlas uses the most recent MongoDB release for clusters
that follow the rapid release cadence. Atlas automatically upgrades
these clusters to the new major and rapid release versions
via a rolling process to maintain cluster availability
as each release becomes available. During the upgrade to the next rapid
release version, the cluster in the Atlas UI
Database Deployments page might show the
of your cluster instead of the MongoDB version to reflect the
features that are currently available on your cluster.
If you switch a cluster from the major release to the rapid release cadence, it will upgrade directly to the currently available rapid release. For example, if MongoDB 6.2 is the latest rapid release and you configure a cluster running 6.0 for rapid release, it will upgrade directly to MongoDB 6.2
You can revert a cluster that follows the rapid release cadence to the major release cadence by selecting the most recent major release from the Select a Version dropdown menu. However, you can only do this before the first rapid release of the year is available. After a cluster updates from a major release version to a rapid release version, you can't revert the cluster until the next major release.
To learn more about MongoDB versions, see MongoDB Versioning in the MongoDB Manual. For additional details about the rapid release cadence, see Understanding the MongoDB Stable API and Rapid Release Cadence.
This section describes the backup configuration options for your Atlas cluster.
Atlas automatically enables backups for
shared clusters and you can't disable them. To learn more, see
Shared Cluster Backups.
To enable backups for an
M10+ Atlas cluster, toggle
Turn on Backup (M10 and up) to
If enabled, Atlas takes snapshots of your databases at
regular intervals and retains them according to your project's
If you have a Backup Compliance Policy enabled, you can't disable Cloud Backup. You can't disable Continuous Cloud Backup if the Backup Compliance Policy has the Require Point in Time Restore to all clusters option set to On without MongoDB Support. To disable Continuous Cloud Backup, the security or legal representative specified for the Backup Compliance Policy must request support and complete an extensive verification process.
Atlas provides the following backup options for
Atlas takes incremental snapshots of the data in your cluster and lets you restore the data from those snapshots. Atlas stores snapshots in the same cloud provider region as the replica set member targeted for snapshots.
Legacy Backup was deprecated on March 23, 2020.
To enable Termination Protection for a cluster, toggle Termination Protection to Yes.
If enabled, Atlas prevents users from deleting the cluster. To delete a cluster that has termination protection enabled, you must first disable termination protection. By default, Atlas disables termination protection for all database deployments.
To learn more about terminating your cluster, see Terminate One Deployment.
To deploy your cluster as a sharded cluster,
toggle Shard your cluster (M30 and up) to
Sharded clusters support horizontal scaling and consist of shards, config servers and mongos routers. To learn more, see About Config Servers Deployment. Config servers must remain readable for sharded read operations to continue to function
Atlas deploys each shard
as a three-node replica set, where each node deploys using the
configured Cloud Provider & Region,
Cluster Tier, and Additional Settings.
Atlas deploys one
mongod per shard node.
For cross-region clusters, the number of nodes per shard is equal to the total number of electable and read-only nodes across all configured regions. Atlas distributes the shard nodes across the selected regions.
Atlas deploys the config servers as a three-node replica set. The config servers run on M30 cluster tiers. In multi-region clusters, config servers are distributed across regions.
For cross-region clusters, Atlas distributes the config server replica set nodes to ensure optimal availability. For example, Atlas might deploy the config servers across three distinct availability zones and three distinct regions if supported by the selected cloud service provider and region configuration. Config servers must remain readable for sharded read operations to continue to function. To learn more, see Config Server Availability.
A regional outage or regional outage simulation that affects the highest priority regions in a sharded cluster could cause the cluster to become inoperable for read operations. To restore the config servers, do the following:
To calculate the number of
routers in a cluster, multiply the number of shards by the number of
replica set nodes per shard.
You cannot convert a sharded cluster deployment to a replica set deployment.
To learn more about how the number of server instances affect cost, see Number of Nodes.
To learn more about sharded clusters, see Sharding in the MongoDB manual.
This field is visible only if the deployment is a sharded cluster.
You can set the number of shards to deploy with the sharded cluster. Your cluster can have between 1 and 50 shards, inclusive.
If you are reducing the number of shards in your sharded cluster, Atlas
removes shards in descending order based on the number in the
"_id" field (see Sharded Cluster Configuration).
For example, consider a sharded cluster with the following three shards:
If you set the number of shards to two, Atlas
"shard2" from the cluster.
When you remove a shard, Atlas uses the movePrimary command to move any unsharded databases in that shard to a remaining shard.
All sharded collections remain online and available during the shard removal
process. However, read or write operations to unsharded collections during
movePrimary operation can result in unexpected behavior, including
migration failure or data loss.
We recommend moving the primary shard for any databases containing unsharded collections before removing the shard.
For more information, see Remove Shards from an Existing Sharded Cluster.
Don't create a sharded cluster with a single shard for production environments. Single-shard sharded clusters don't provide the same benefits as multi-shard configurations.
If your cluster tier is
M30 or higher, you can upgrade
your replica set deployment to a sharded cluster deployment.
Once the upgrade completes, you must restart all application clients and reconnect to your sharded cluster. If you don't restart the application clients, your data might be inconsistent once Atlas begins distributing data across shards.
To enable BI Connector for Atlas for this cluster, toggle Enable Business Intelligence Connector (M10 and up) to Yes.
The MongoDB Connector for Business Intelligence for Atlas (BI Connector) is only available for
The BI Connector is a powerful tool which provides users
SQL-based access to their MongoDB databases. As a result, the
BI Connector performs operations which may be CPU and memory
intensive. Given the limited hardware resources on
M20 cluster tiers, you may experience performance degradation of
the cluster when enabling the BI Connector. If this occurs,
upgrade to an
M30 or larger cluster or disable the
If enabled, select the node type from which BI Connector for Atlas should read.
nodeType read preference tag dictates the type of node BI Connector for Atlas
connects to. You can specify the following values for this option:
When you use the Analytics read preference, Atlas places BI Connector for Atlas on the same hardware as the analytics nodes that BI Connector for Atlas reads from.
By isolating electable data-bearing nodes from the BI Connector for Atlas, electable nodes don't compete for resources with BI Connector for Atlas, thus improving cluster reliability and performance.
For high traffic production environments, connecting to the Secondary Node(s) or Analytics Node(s) may be preferable to connecting to the Primary Node.
For clusters with one or more analytics nodes, select Analytics Node to isolate BI Connector for Atlas queries from your operational workload and read from dedicated, read-only analytics nodes. With this option, electable nodes don't compete for resources with BI Connector for Atlas, thus improving cluster reliability and performance.
The BI Connector generates a relational schema by sampling data from MongoDB. You can configure the following sampling settings:
BI Connector Option
Schema Sample Size
Optional. The number of documents that the BI Connector samples for each database when it gathers schema information. To learn more, see the BI Connector documentation.
Sample Refresh Interval
Optional. The frequency, in seconds, at which the BI Connector re-samples data to recreate the schema.To learn more, see the BI Connector documentation.
This feature is not available for
M0 free clusters,
M5 clusters. To learn more about which features are unavailable,
see Atlas M0 (Free Cluster), M2, and M5 Limitations.
Atlas encrypts all cluster storage and snapshot volumes,
ensuring the security of all cluster data at rest
(Encryption at Rest). Atlas
Project Owners can configure
an added layer of encryption on their data at rest using the
MongoDB Encrypted Storage Engine
and their Atlas-compatible Encryption at Rest provider.
Atlas supports the following Encryption at Rest providers:
You must configure the Atlas project for Encryption at Rest using your Key Management before you enable the feature for your Atlas clusters. To learn more, see Encryption at Rest using Customer Key Management.
To switch from one Encryption at Rest provider on your cluster to another, you must first disable Encryption at Rest for your cluster, then re-enable it with your desired Encryption at Rest provider. To learn more, see Encryption at Rest using Customer Key Management.
To start managing your own encryption keys for this cluster, toggle Encryption using your Key Management (M10 and up) to Yes.
Atlas Encryption at Rest using your Key Management is available for
M10+ replica set clusters. Atlas Encryption
at Rest supports encrypting Back Up Your Database Deployment only.
You can't enable Encryption at Rest on a cluster using
Legacy Backups (Deprecated).
Managing your own encryption keys incurs an increase to the hourly run costs of your clusters. To learn more about Atlas billing for advanced security features, see Advanced Security.
If Atlas can't access the Atlas project key management provider or the encryption key used to encrypt a cluster, that cluster becomes inaccessible and unrecoverable. Exercise extreme caution before you modify, delete, or disable an encryption key or the key management provider credentials that Atlas uses.
You can configure the following
mongod runtime options on
paid tier clusters.
To view and edit these settings:
To set the minimum oplog window:
Verify that storage auto-scaling is enabled and that you didn't opt out of it. Atlas enables auto-scaling by default.
Set the minimum oplog window to the desired value. If you don't set this value, Atlas retains oplog entries for 24 hours before the
mongodremoves them from the oplog.
You might want to set a fixed oplog size. For example, this is helpful during live migration or during an intensive data load.
You can set the Set Oplog Size configuration setting only if you opt out of the cluster's storage auto-scaling.
For clusters that have storage auto-scaling enabled, you can set the Minimum Oplog Window instead. See Set Minimum Oplog Window. Atlas enables storage auto-scaling by default.
The minimum oplog size you can set is 990 megabytes. Atlas returns an error if the oplog size you choose leaves your cluster's disk with less than 25 percent of its capacity free.
To check the oplog size:
Connect to your cluster via
Authenticate as a user with the
Atlas displays the current oplog size and time.
To set a fixed oplog size:
Opt out of storage autoscaling.
Set the Minimum Oplog Window to
Specify your desired Oplog Size in megabytes in the input box.
For sharded cluster deployments, this option modifies the oplog size of each shard in the cluster.
Reducing the size of the oplog requires removing data from the oplog. Atlas can't access or restore any oplog entries removed as a result of oplog reduction. Consider the ramifications of this data loss before you reduce the oplog.
Don't reduce the size of the oplog to increase the available disk
space. Only the oplog collection (
can reclaim the space that reducing the oplog size saves. Other
collections don't benefit from reducing oplog storage.
Enable or disable enforcement of the 1024-byte index key limit. Documents can only be updated or inserted if, for all indexed fields on the target collection, the corresponding index entries don't exceed 1024 bytes.
mongod writes documents that breach the limit but
doesn't index them. This option corresponds to modifying the
parameter via the
setParameter command for each
in the cluster.
Index Key Limit
was deprecated in MongoDB version 4.2 and is removed in MongoDB 4.4
and later. For MongoDB prior to 4.2, set this parameter to
Include redacted and anonymized
$queryStats output in MongoDB logs.
$queryStats output does not contain literals or field values.
Enabling this setting might impact the performance of your cluster.
You can enable logging of query data only for Atlas clusters that run MongoDB 7.1 or later.
Set the minimum TLS version that the cluster accepts for incoming
connections. This option corresponds to configuring the
net.ssl.disabledProtocols configuration file option
mongod in the cluster.
TLS 1.0 Deprecation
If you are considering this option as a method for enabling the deprecated Transport Layer Security (TLS) 1.0 protocol version, read What versions of TLS does Atlas support? before proceeding. Atlas deprecation of TLS 1.0 improves your security of data-in-transit and aligns with industry best practices. Enabling TLS 1.0 for any Atlas cluster carries security risks. Consider enabling TLS 1.0 only for as long as required to update your application stack to support TLS 1.1 or later.
Enable or disable the execution of queries that require a collection
scan to return results. This option corresponds to modifying the
notablescan parameter via the
setParameter command for each
Set the default level of acknowledgment requested from MongoDB for read operations for this cluster.
You can set the default read concern only for Atlas clusters that run MongoDB 4.4 or higher.
MongoDB 4.4 clusters default to available.
Starting with MongoDB 5.0, the default read concern for clusters is local.
Set the default level of acknowledgment requested from MongoDB for write operations for this cluster.
You can set the default write concern only for Atlas clusters that run MongoDB 4.4 or higher.
MongoDB 4.4 clusters default to 1.
Starting with MongoDB 5.0, the default write concern for clusters is majority.
Set the maximum lifetime of multi-document transactions. This option corresponds to modifying the
transactionLifetimeLimitSeconds parameter via the
setParameter command for each
mongod in the cluster.
You can't set the transaction lifetime to less than one second.
Starting with MongoDB 4.0, the transaction lifetime for clusters default to 60 seconds.
For sharded Atlas clusters running MongoDB version 5.0.15 or
6.0.6 and higher versions, you can set the number of threads on the source
and receiving shard to improve the performance of chunk
migration. You can set
the value to half the total number of CPU cores. To learn more, see