Atlas storage auto-scaling and disk reclaim via compact

Published reference · snapshot 2026-10-20 · skill mongodb-operations-expert/references/atlas-storage-auto-scaling-and-disk-reclaim-via-compact.md

↓ Facts as markdown all context files

Source-anchored research for Atlas storage auto-scaling and disk reclaim via compact. Run status: COMPLETED.

These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.

Definitions

compact is not replicated, so you run it on each node. On Atlas, rs.stepDown() and member-priority changes are unsupported, so the compact reference says to run compact on every node and use force: true on the primary. MongoDB staff and an official App Services page describe another route: compact each secondary one at a time, run Test Primary Failover in Atlas, then compact the former primary. (high confidence) (verified as of 2026-10-20) [source]

Structure and components

WiredTiger does not overwrite in place, so expect about 20% more disk than the compressed data occupies. MongoDB also uses part of the configured capacity for buffer, journal and log files. (low confidence) [source]

How it works

Oplog size can block a storage scale-up. Atlas delays an auto-scaling event until the oplog window covers the estimated scaling time. For storage auto-scaling to complete, Atlas requires oplogMinRetentionHours to be up to 60 seconds multiplied by the GB of configured disk space. When the oplog is too small Atlas raises 'Auto-scaling: Disk auto-scaling didn't initiate due to insufficient oplog size'. At the tier's disk ceiling it raises 'Auto-scaling: Disk auto-scaling didn't initiate due to the cluster reaching maximum available disk size'. (high confidence) (verified as of 2026-10-18) [source]
When the primary runs critically low on free disk, Atlas blocks writes on the replica set and keeps serving reads. On sharded clusters only writes routed to the affected shard are blocked. Writes resume automatically once free space passes the unblock threshold. Fix: raise storage or enable storage auto-scaling. Write blocking is active on M10+ clusters running MongoDB 8.0 or later. (medium confidence) (verified as of 2026-10-20) [source]
Atlas disables disk auto-scaling when the base nodes and analytics nodes use different cluster tier classes, for example a General base tier with a Low-CPU analytics tier. The message is 'Disk auto-scaling is not yet available for clusters with mixed instance classes.' (low confidence) (verified as of 2026-10-18) [source]
Index storage size can differ across replica set members holding identical data, because each node applies writes to its indexes independently. Remedies: compact the affected node, run an initial sync of it, or drop and recreate the index. Plan capacity for that variation. (low confidence) [source]
For dedicated Atlas Core clusters, restoring a snapshot larger than the destination cluster's storage does not trigger auto-scaling. (low confidence) (verified as of 2026-10-18) [source]
Storage auto-scaling can lose a race with the workload. Atlas needs time to prepare and copy data to new disks. A burst of high-speed writes, such as a bulk insert or a data migration, can fill the disk before the scale-up finishes. Other causes of a Disk Space % Used alert: auto-expand is off, or the cluster is already at the maximum storage for its tier. (high confidence) (verified as of 2026-10-18) [source]
Index storage size can differ across replica set members that hold identical data, because secondaries apply writes in different batches and order. To bring an oversized index back in line, compact that node, initial sync it, or drop and recreate the index. Account for this variation when planning capacity. (low confidence) [source]
A MongoDB forum answer (February 2025) says that more often than not there is no need to compact, because WiredTiger is a no-overwrite engine that reuses free blocks for new writes before it extends files. Inference: compaction pays off when you intend to shrink the disk or when the freed space will not be reused soon. (medium confidence) [source]

Measurements and reference values

On an Atlas Core dedicated cluster, storage auto-scaling is on by default. Atlas raises cluster storage when disk space used reaches 90% on any node. To opt out, clear the Storage Scaling checkbox in the Auto-scale section. (high confidence) (verified as of 2026-10-18) [source]
On AWS, Azure and Google Cloud, a storage scale-up sizes the new disk to bring used space to about 70%. (low confidence) (verified as of 2026-10-18) [source]
Atlas auto-scales storage up only. Lowering storage is a manual change on the Edit Cluster page. A user whose cluster auto-scaled from 8 GB to 32 GB after a one-time load had to try to scale it back by hand (forum thread, January 2024). (high confidence) (verified as of 2026-10-18) [source]
Deleting documents does not lower disk usage on its own, and a TTL index never triggers compaction. On Atlas, after deleting about 100 million of 110 million documents, one user's collection reported about 25 GB but cluster storage and backup size did not drop. In another thread, primary disk use fell from about 40 GB to about 6 GB only after a manual compact, and each secondary needed its own compact. (medium confidence) [source]
compact options by version: freeSpaceTargetMB (default 20 MB, the minimum recoverable space for compaction to proceed) since 7.3; dryRun and the autoCompact command since 8.0. With dryRun: true, compact only returns estimatedBytesFreed. A real run returns bytesFreed. On a replica set primary, compact needs force: true. (high confidence) (verified as of 2026-10-20) [source]
Atlas write-block thresholds by node disk size: 8 to 20 GiB blocks below 600 MiB free and unblocks above 900 MiB; 20 GiB to 1.25 TiB blocks below 4% free and unblocks above 6%; 1.25 TiB and up blocks below 50 GiB free and unblocks above 75 GiB. Blocked writes include deletes, because deleting can temporarily raise used disk. Logs show 'Replica set writes blocked, reason: InsufficientDiskSpace' on FCV 9.0 or later, and 'User writes blocked, reason: DiskUseThresholdExceeded' on earlier FCV. (low confidence) (verified as of 2026-10-20) [source]
On an Atlas Core (dedicated) cluster, storage auto-scaling is on by default. Atlas raises disk capacity when disk used reaches 90% on any node. On AWS, Azure and GCP it sizes the new disk so that usage lands at 70%. (high confidence) (verified as of 2026-10-18) [source]
With storage auto-scaling on, Atlas manages the oplog by the minimum oplog retention window (default 24 hours). With it off, Atlas manages the oplog by size: 5% of disk for General and Low-CPU clusters, 10% for NVMe. When storage decreases, Atlas scales the oplog down in the same ratio, but never below those minimums. (medium confidence) (verified as of 2026-10-18) [source]
Write blocking is Atlas's last guard against a full disk. If the primary runs critically low on free disk, Atlas blocks writes on the replica set (on a sharded cluster, only writes routed to the affected shard) and keeps serving reads. Thresholds by total disk size: 8-20 GiB blocks below 600 MiB free and unblocks above 900 MiB; 20 GiB-1.25 TiB blocks below 4% free and unblocks above 6%; 1.25 TiB or more blocks below 50 GiB and unblocks above 75 GiB. It is active on M10+ clusters running MongoDB 8.0 or later. (high confidence) (verified as of 2026-10-14) [source]
After compaction, Atlas can still reject a storage decrease. One user's dev cluster auto-scaled from 8 GB to 32 GB. They deleted the data, ran compact, then tried 8 GB and got 'The selected disk size (8.0 GB) is smaller than the amount of data currently used (16.04489517211914 GB)' while the UI showed 6.15 GB of data. The fetched thread has no reply. (low confidence) (verified as of 2024-01-15) [source]
Atlas logs every auto-scaling event in the project Activity Feed. The disk events are 'Disk auto-scaling initiated', 'Disk auto-scaling didn't initiate due to the cluster reaching maximum available disk size' and 'Disk auto-scaling didn't initiate due to insufficient oplog size'. Since early August 2024 these are configurable alerts that default to project owners. The default 'Disk space % used on Data Partition' alert fires at 90% of configured storage. (high confidence) (verified as of 2026-10-20) [source]

Problems, failure modes and limitations

A storage scale-up can also change the cluster tier. If the new capacity exceeds what the current tier supports, Atlas raises the tier even when tier auto-scaling is off. Documented example: an M30 tops out at 480 GB, so a 600 GB need moves the cluster to M40. If the configured maximum tier cannot hold the new capacity, Atlas raises that maximum and turns off downward tier auto-scaling. (medium confidence) (verified as of 2026-10-18) [source]
After a disk auto-scale, further auto-scaling and manual disk scaling may be unavailable for a few hours. On AWS the cause is the EBS limit: at most four modifications per volume in a rolling 24 hours, and each must finish before the next starts. Atlas delays later storage or IOPS changes until AWS allows another. (high confidence) (verified as of 2026-10-18) [source]
No cloud provider shrinks a block volume in place. AWS states 'You can't decrease the volume size'. Google Cloud states a disk's size cannot be reduced; the workaround is a new smaller disk plus a copy. Atlas documents the same limit for Azure. So Atlas always lowers storage by provisioning new smaller volumes and syncing data from the old ones. Each node has downtime during its sync, and the Azure and GCP pages warn of a rolling restart. (high confidence) (verified as of 2026-10-18) [source]
On an Atlas Infinite cluster (public preview) storage grows with the data and there is no storage auto-scaling to configure. You set a maximum storage size, and Atlas blocks writes when logical data size approaches it. The 'Disk Space % Used' alert does not apply; Atlas raises 'Atlas Infinite: Storage Space Used %' instead. During preview Atlas may throttle writes before the limit. (medium confidence) (verified as of 2026-10-20) [source]
autoCompact details: runOnce: true makes one pass over every collection on the node. runOnce: false runs continuously and retries a collection that failed to compact after about one hour. It skips the oplog. It applies the same blocking behavior as compact, so a second call while it runs returns an error; send { autoCompact: false } first. After a mongod restart it stays off unless the enableAutoCompaction parameter is true (default disabled). It is not replicated, so enable it per node and per shard, never through mongos. (low confidence) (verified as of 2026-10-20) [source]
Atlas logs every auto-scaling event in the project Activity Feed, with the triggering metric and threshold. Auto-scaling alerts are set per project and cannot be scoped to one cluster. The default 'Disk space % used on Data Partition' alert fires at 90% of configured storage. It can fire even with Auto-Expand Storage on, when the disk fills too fast or the tier's maximum storage is reached. (high confidence) (verified as of 2026-10-20) [source]
Reported failure: after an auto-scale from 8 to 32 GB, deleting data and compacting one collection, a user saw 6.15 GB used but Atlas rejected a resize to 8 GB with 'The selected disk size (8.0 GB) is smaller than the amount of data currently used (16.04489517211914 GB)'. The January 2024 thread has no answer. A 2022 thread suggests Atlas judges disk by the primary's usage, and that user could shrink only after compacting the primary. The cause in the 2024 case is unconfirmed. (low confidence) [source]
On AWS and Azure the cloud provider cannot shrink a volume in place. Atlas lowers capacity by provisioning new volumes and syncing data from the old ones. Each node is unavailable while its data syncs. Atlas always uses this path for decreases, even though it can resize in place for increases. (high confidence) (verified as of 2026-10-18) [source]
AWS allows at most four Elastic Volumes modifications per EBS volume in any rolling 24 hours, and a new modification waits for the previous one to complete. Atlas inherits this limit, so repeated storage or IOPS changes, including auto-scaling, can be delayed. The Clusters page then shows: 'Some EBS volume changes are delayed because AWS has reached the maximum number of allowed EBS volume modifications for this volume within a 24-hour period.' (high confidence) (verified as of 2026-10-18) [source]
Storage auto-scaling can raise the cluster tier. If the new capacity exceeds what the current tier supports, Atlas also raises the tier, even when tier scaling is disabled. Docs example: an M30 at its 480 GB maximum and 90% full needs 600 GB, so Atlas moves it to M40. If a smaller tier cannot hold the configured disk, Atlas does not scale the cluster down to it and raises an event. (medium confidence) (verified as of 2026-10-20) [source]
Blocked writes include deletes, because deleting documents can temporarily increase used disk. Deleting data therefore cannot free space while writes are blocked. Recovery is to increase cluster storage or enable storage auto-scaling. Atlas unblocks writes by itself once free space on the primary rises above the unblock threshold. (medium confidence) (verified as of 2026-10-14) [source]
When a cluster reaches the maximum storage for its tier, disk auto-scaling cannot add more. Atlas raises the event 'Disk auto-scaling didn't initiate due to the cluster reaching maximum available disk size'. Options are a larger tier, extended storage, or sharding. On AWS, extended storage reaches 4 TB on M40, 8 TB on M50/M60 and 14 TB on M80+ for single-region General or Low-CPU Atlas Core clusters. The docs call it a temporary measure: it slows initial syncs and cross-project restores and can reduce high availability. (medium confidence) (verified as of 2026-10-20) [source]
NVMe clusters have a fixed disk size per tier and cannot resize storage independently. Auto-scaling moves them to the next higher tier when 90% of storage is consumed. Each NVMe tier change requires an initial sync, which is file-copy based on Atlas Core. (medium confidence) (verified as of 2026-10-20) [source]
Atlas disables disk auto-scaling when the base-tier and analytics-tier nodes use different cluster classes. The error text is 'Disk auto-scaling is not yet available for clusters with mixed instance classes.' (low confidence) (verified as of 2026-10-18) [source]
Atlas Infinite, in public preview as of October 2026, has no disk size and no storage auto-scaling to configure. Storage grows with data up to a max storage limit of 1 GB to 128 TB of logical data (field shardSizeLimitGB). Atlas blocks writes at the limit and keeps serving reads. Atlas meters storage hourly by uncompressed logical data size, including the oplog. (medium confidence) (verified as of 2026-10-14) [source]
The primary does not replicate compact to secondaries, so reclaiming disk on a replica set means running compact on each member. On a sharded cluster, run it on each shard's mongod. compact cannot run against mongos. Two concurrent compact commands on the same collection return an error. (high confidence) [source]
autoCompact (new in MongoDB 8.0) runs background compaction. It iterates over the available files and compacts when enough free space is recoverable. freeSpaceTargetMB sets that minimum (default 20 MB). runOnce: true makes one pass over every collection. A collection that fails to compact is retried after about an hour. The oplog is excluded. autoCompact applies the same blocking behavior as compact, and a second autoCompact call while one is active returns an error. (high confidence) (verified as of 2026-10-20) [source]
A rolling resync (initial sync, one member at a time) rebuilds a member's data files compactly. Percona's advisor calls it the safest way to reclaim disk, with no downtime or application impact, but slow for large data. Netdata adds that the sync source's oplog window must cover the sync and that only one member of a three-node set should resync at a time. The MongoDB manual also lists initial sync as an alternative to compact. (high confidence) [source]
Atlas users report they cannot start a resync themselves. In a July 2025 thread a reply says to contact MongoDB Support to resync the members when compact does not release the free blocks. An earlier thread (February 2025) has the user stating that Atlas allows no manual resync. (low confidence) (verified as of 2025-07-11) [source]

Comparisons and alternatives

If a deployment uses secondary reads and multi-shard transactions, MongoDB advises an initial sync instead of compact. Compact makes WiredTiger adjust its block-manager strategy, which slows checkpoints and delays transaction commits. The docs name read latency, replication lag and operational queuing as the result. (low confidence) (verified as of 2026-10-20) [source]
Before a bulk insert, migration or other high-speed write job, raise disk capacity (or the tier) by hand instead of waiting for the 90% trigger. The Atlas docs advise scaling up in advance of bulk inserts. (medium confidence) [source]
If a deployment uses secondary reads and multi-shard transactions, compact makes WiredTiger adjust its block-manager strategy, which can slow checkpoints and delay transaction commits. The manual warns this can cause significant read latency, replication lag and operational queuing, and suggests an initial sync instead of compact. (low confidence) [source]

Facts and statements

On AWS the first storage increase is done in place with no downtime. For later increases Atlas provisions new volumes and syncs data from the old ones if the last change was under 6 hours ago (volumes under 1 TB) or under 6 hours per TB ago (volumes over 1 TB). During that sync the cluster stays reachable, but a node being modified is unreachable until its new volume attaches. Otherwise Atlas waits out the cooldown and modifies in place. On M40+ non-NVMe AWS clusters, Atlas also uses one EBS modification for fast disk pre-warming during a cloud-based initial sync. Single vendor page. (low confidence) (verified as of 2026-10-18) [source]
After deletes, WiredTiger keeps the freed blocks in its data files for reuse and does not return them to the OS, so disk usage stays flat. compact releases obsolete blocks to the OS for a collection and its indexes. How much it frees depends on how many free blocks exist and where they sit in the file. It can free nothing. freeStorageSize in collStats shows the reusable space; Percona points to wiredTiger.block-manager 'file bytes available for reuse' in collection stats. (high confidence) [source]
autoCompact (new in 8.0) turns on background compaction: the server walks all files and compacts whenever enough space is recoverable. For Atlas, the compact reference suggests autoCompact to avoid running compact on every node. It is not supported on M0 and Flex clusters. With authentication on, Atlas users need the Atlas-only built-in role 'autoCompact', which grants the cluster 'compact' action. (high confidence) (verified as of 2026-10-20) [source]
With autoCompact on, the server tries to keep free space in each collection and index below freeSpaceTargetMB (default 20). Before enabling it, run $collStats with storageStats: {} and compare freeStorageSize to freeSpaceTargetMB. If freeStorageSize is smaller, background compaction has no effect. (medium confidence) (verified as of 2026-10-20) [source]
Synthesis: lowering an Atlas bill after a large purge takes three separate steps. First, free space inside the files: delete or archive, then compact every node. Second, confirm used disk on every node fits the smaller size. Third, reduce storage by hand, which Atlas does through the new-volume sync with per-node downtime. Compaction alone leaves the provisioned size and cost unchanged, and auto-scaling never lowers it. One 2022 user could shrink the disk only after compacting the primary as well. (medium confidence) (verified as of 2026-10-18) [source]
Atlas community threads give these connection details for per-node compact: connect straight to each node, not through the mongodb+srv:// string (node hostnames are in the metrics view), set tls=true and usually authSource=admin. One user fixed a failed secondary connection by adding directConnection=true. (medium confidence) [source]
With storage auto-scaling on, the disk size Atlas holds drifts from the Terraform value. The Atlas scalability guidance warns that applying a plan then sets the disk back to the original disk_size_gb. Per the storage-change docs, any reduction takes the new-volume sync path. Set use_effective_fields = true (API header 'Use-Effective-Instance-Fields: true') so the spec keeps your configured values and the effective specs show the auto-scaled ones. (high confidence) (verified as of 2026-10-20) [source]
Archive or expire history first, then compact. The Atlas scalability guidance recommends data tiering, archival and TTL indexes to cut storage cost. Percona's field report: a cloud customer on eight shards (4 TB per node, 96 TB across all nodes) archived data and ran compact, cutting each node to 2.5 TB (60 TB total) and the cloud bill with it. The report dates from August 2022 and names no Atlas cluster. (medium confidence) [source]
Bulk writes can outrun a storage scale-up. Atlas needs time to prepare and copy data to new disks, so a bulk insert or data migration can fill the disk first, and the 'Disk Space % Used' alert fires even with Auto-Expand Storage on. Scale up before bulk loads. (high confidence) [source]
Compaction, manual or automatic, checkpoints the database regularly. On busy systems that can delay or prevent backups, so the docs say to disable compaction before a backup. The autoCompact page also recommends running it in low-traffic periods. (medium confidence) [source]
Inference, not a documented rule: compact may need extra disk space to run, and a write-blocked Atlas node also rejects deletes. So start compaction well before the write-block threshold. The docs give no safe free-space margin. (low confidence) [source]
autoCompact skips the oplog. In a 2022 Atlas thread (M10, MongoDB 4.4), shrinking the oplog from the console did not free disk until compact ran on oplog.rs on each secondary, then on the former primary after Test Failover. (low confidence) [source]
Storage auto-scaling only grows disks. As of the 2026-10-18 Atlas docs, Atlas does not shrink a disk automatically. Lowering capacity is a manual change from the Edit Cluster page. (medium confidence) (verified as of 2026-10-18) [source]
After a disk auto-scaling event, further disk auto-scaling and manual disk scaling may be unavailable for a few hours. On AWS the first change is made in place without downtime. A later increase made inside the cooldown (6 hours, or 6 hours per TB above 1 TB) provisions new volumes and syncs data. After the cooldown Atlas modifies the volume in place. (medium confidence) (verified as of 2026-10-18) [source]
On Atlas Core, Atlas delays a storage auto-scaling event until the oplog window covers the estimated scaling time. The docs state that Atlas requires oplogMinRetentionHours 'to be up to (60 seconds) * (GB of disk space configured)'. If the oplog is too small, Atlas raises the event 'Auto-scaling: Disk auto-scaling didn't initiate due to insufficient oplog size' and does not scale. (medium confidence) (verified as of 2026-10-20) [source]
Write-blocking log errors depend on the cluster feature compatibility version. FCV 9.0 or later returns a MongoServerError like 'Replica set writes blocked, reason: InsufficientDiskSpace'. Earlier FCV returns 'User writes blocked, reason: DiskUseThresholdExceeded'. (low confidence) (verified as of 2026-10-14) [source]
Atlas bills dedicated-cluster storage by configured capacity, not by bytes used. The tier price includes the default capacity. If you set a custom capacity, Atlas charges for the full custom amount. Inference from this rule: blocks freed inside a disk lower the bill only after you also lower the configured disk size. (medium confidence) (verified as of 2026-10-18) [source]
On Gen2 dedicated clusters (AWS and Google Cloud, M30+), storage capacity and extended standard IOPS are configured independently, and Atlas bills them separately. The storage charge includes the baseline IOPS for that disk size. (medium confidence) (verified as of 2026-10-18) [source]
WiredTiger keeps the space freed by deletes inside its data files and reuses it for later writes. It does not return that space to the operating system. Deleting documents therefore does not shrink disk usage. Dropping a collection or database removes its files and frees the space at once. (high confidence) [source]
compact rewrites one collection and its indexes and tries to release obsolete blocks to the operating system. The manual says effectiveness depends on how many blocks are available to release and where they sit in the data file. It can free little or nothing, and it may need extra disk space to run. A first run can leave the physical size unchanged and need repeating. (high confidence) [source]
Compact outcomes vary widely. Percona reports a customer whose per-node footprint fell from 4 TB to 2.5 TB (96 TB to 60 TB across eight shards) after archiving data and compacting. On an Atlas 6.0.24 three-node replica set with about 2 TiB of free blocks, compact on each collection freed about 1 TiB per node, and a second run freed no more. (medium confidence) [source]
On Atlas, rs.stepDown() and member-priority changes are unavailable, so the self-managed sequence 'compact secondaries, step down, compact the old primary' does not apply as written. The manual says to run compact on every node and to use force: true on the current primary. A MongoDB forum answer (February 2025) instead says to compact secondaries one at a time, run Atlas Test Failover, then compact the former primary. (medium confidence) (verified as of 2026-10-14) [source]
The current manual says compact does not block CRUD operations on the database. Since MongoDB 6.1.0 (and 6.0.2) a secondary keeps replicating and serves reads while compact runs. Percona lists backports to 5.0.12 and 4.4.17 and says drop, createIndex(es), dropIndex(es) and collMod are still blocked. Percona's 2022 blog says that before 4.4 compact took a write lock on the database. (medium confidence) (verified as of 2026-10-20) [source]
Compaction checkpoints the database regularly. On a busy database this can delay or prevent backups, so disable compaction (compact or autoCompact) before taking a backup. (high confidence) [source]
Percona's checklist before compacting: take a full backup, confirm the replication oplog window is large enough, run compact on secondary and hidden nodes first, and compact the primary last after stepping it down. The MongoDB manual gives the same secondary-first order for self-managed replica sets. (medium confidence) [source]
On Atlas, autoCompact is supported only on dedicated clusters running MongoDB 8.0 or later, and not on M0 or Flex clusters. The database user needs the autoCompact privilege (built-in role). Connect to each node and run the command against the admin database. For a sharded cluster, fetch each node's connection string from the Atlas Administration API. (high confidence) (verified as of 2026-10-20) [source]
autoCompact does not survive a mongod restart by default. The enableAutoCompaction parameter is disabled by default, so you must re-run autoCompact after a restart or start mongod with enableAutoCompaction=true. Atlas rolling maintenance and scaling restart nodes, but no fetched source says whether Atlas re-applies autoCompact afterwards. (low confidence) (verified as of 2026-10-20) [source]
Measure reclaimable space before acting. Run collStats (or $collStats with storageStats) and read freeStorageSize. If freeStorageSize is below freeSpaceTargetMB, background compaction has no effect. On 8.0+, compact with dryRun: true returns estimatedBytesFreed without compacting. Percona reads db.<collection>.stats().wiredTiger['block-manager']['file bytes available for reuse'] per collection. (high confidence) [source]
If Terraform manages an auto-scaled Atlas cluster, enable effective fields (API header Use-Effective-Instance-Fields: true). Spec attributes then keep your configured diskSizeGB and instanceSize, and the auto-scaled values appear in effective specs such as effectiveElectableSpecs, so no drift occurs. Without effective fields you must add lifecycle.ignore_changes, which the docs do not recommend. (low confidence) (verified as of 2026-10-14) [source]

Children

Archive and TTL data lifecycle followed by compaction (frontier)
Atlas Infinite storage metering and max storage limit (frontier)
Atlas Infinite storage model (max storage limit, no auto-scaling) (frontier)
Atlas disk decrease by volume replacement on AWS, Azure and GCP (frontier)
Atlas disk write-blocking thresholds and recovery (frontier)
Atlas write-blocking thresholds and Intelligent Workload Management (frontier)
MongoDB 8.0 autoCompact background compaction on Atlas (frontier)
Oplog minimum retention window and storage auto-scaling (frontier)
Oplog sizing under storage auto-scaling
Reducing Atlas storage capacity (new-volume sync, per-node downtime) (frontier)
Rolling resync (initial sync) as a space-reclaim technique on Atlas (frontier)
Terraform effective fields and auto-scaling drift (frontier)
WiredTiger block reuse, file fragmentation and freeStorageSize (frontier)

Frontier under this node: Archive and TTL data lifecycle followed by compaction, Atlas Infinite storage metering and max storage limit, Atlas Infinite storage model (max storage limit, no auto-scaling), Atlas disk decrease by volume replacement on AWS, Azure and GCP, Atlas disk write-blocking thresholds and recovery, Atlas write-blocking thresholds and Intelligent Workload Management, MongoDB 8.0 autoCompact background compaction on Atlas, Oplog minimum retention window and storage auto-scaling, Reducing Atlas storage capacity (new-volume sync, per-node downtime), Rolling resync (initial sync) as a space-reclaim technique on Atlas, Terraform effective fields and auto-scaling drift, WiredTiger block reuse, file fragmentation and freeStorageSize

← the whole tree · 3D view· how to read this page