For AI agents: a documentation index is available at https://www.mongodb.com/docs/llms.txt — markdown versions of all pages are available by appending .md to any URL path.
Docs Menu

FAQ: Storage

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

  • For Free clusters (formerly known as M0) and Flex clusters, 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 Flex 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 Flex cluster that does not have space for the desired write operation, Atlas displays an error message similar to the following:

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

Tip

To learn about the differences between Flex clusters and dedicated clusters, see Atlas Flex Limits.

Tip

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.

Atlas retrieves database metrics every 20 minutes by default but adjusts frequency when necessary to reduce the impact on database performance.

To learn more about storage alerts, see DB Storage alert conditions.

Atlas calculates the storage limit for Flex clusters based on data usage, as opposed to the storageSize metric used by non-Flex 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.

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.

Yes, for AWS Gen2 Dedicated clusters you can change a cluster's IOPS rate without changing storage capacity by using Extended Standard IOPS. Extended Standard IOPS is only available for AWS Gen2 clusters. You can select Gen2 when configuring tier M30+ clusters on AWS. AWS Gen2 Dedicated clusters also offer a maximum standard IOPS rate of 80k IOPS.

To learn more, see AWS Gen2 Dedicated Clusters.

Switching a cluster between generations behaves like any other cluster tier change. You change the generation the same way that you change the cluster tier. To learn more, see Modify the Cluster Generation for AWS Gen2 Dedicated Clusters.

Atlas maintains your existing IOPS rate when you switch a cluster from Gen1 to Gen2.

For Gen2 clusters hosted on AWS, Atlas also keeps your existing IOPS type:

  • If your Gen1 cluster uses Provision IOPS, the Gen2 cluster uses High Performance IOPS.

  • If your Gen1 cluster doesn't use Provision IOPS, the Gen2 cluster uses Standard IOPS.

We don't recommend changing your cluster's generation and IOPS type at the same time. Instead, change one feature and confirm your cluster performs as expected before changing the other. To learn how to configure standard IOPS on Gen2, see Extended Standard IOPS for Gen2 Clusters.

For clusters hosted on AWS, Atlas preserves your existing IOPS type when you switch a cluster back to Gen1. Standard IOPS stays as Standard IOPS, and High Performance IOPS stays as High Performance IOPS. Atlas also checks your Gen2 configuration against the IOPS.

Atlas also checks your Gen2 configuration against the Gen1 configuration limits. If the move to Gen1 would breach a Gen1 limit, Atlas automatically reduces your IOPS to meet the Gen1 limit. For example, Gen1 clusters hosted on AWS support a maximum of 16,000 IOPS, so Atlas automatically reduces a Gen2 cluster of 16,000 IOPS. If a Gen2 cluster uses more than 16,000 IOPS, Atlas automatically reduces the cluster to 16,000 IOPS when you switch it to Gen1. If moving to Gen1 would result in fewer IOPS, Atlas displays a warning and requires you to confirm that the available IOPS are sufficient for your workload before proceeding.

Standard IOPS use AWS General Purpose SSD volumes instead of the AWS Provisioned IOPS SSD volumes that High Performance IOPS use, so they don't deliver the same latency or consistency characteristics. If your workload is sensitive to write latency or depends on a consistent IOPS rate, test the change in a non-production environment before you apply it to production.

Provisioned IOPS on Gen1 and High Performance IOPS on Gen2 refer to the same concept. To learn how the IOPS types differ, see IOPS Types.

Yes, both the generation change and any change to the IOPS type or rate affect cost. To estimate the cost of each change before you apply it, use the cluster builder in the Atlas UI.

On Gen2, you configure standard IOPS and storage capacity independently, and Atlas bills them separately. You can adjust each one to match your workload and optimize your costs. To learn how Atlas bills AWS Gen2 Dedicated clusters, see AWS Gen2 Dedicated Clusters.

For clusters that meet specific criteria, yes. To learn which clusters support extended storage and how to enable this for your projects, see Manage Project Settings.

You can use the autoCompact command on dedicated clusters to perform background compaction, which reduces your storage use. This command automatically iterates through available files and continuously attempts to release unneeded disk space to the operating system. To learn more about enabling the autoCompact privilege action, see Built-In Roles in the "Built-In Roles and Privileges" section.

The autoCompact command is supported only on dedicated clusters running MongoDB 8.0+.

To run autoCompact on a cluster, do the following steps:

  1. Create a database user and configure the autoCompact privilege.

  2. (Optional) If you are connecting to a sharded cluster, retrieve the connection string of each node in the sharded cluster. You can use an Atlas Administration API endpoint to retrieve this information.

  3. Connect to each node that you want to run autoCompact on.

  4. Run autoCompact on the admin database.