<!-- llms-explorer concept facts · https://llms-explorer.com/tree/archive-and-ttl-data-lifecycle-followed-by-compaction/ · pack 2026-10-31 · ~1557 tokens -->

# Archive and TTL data lifecycle followed by compaction

> Source-anchored research for Archive and TTL data lifecycle followed by compaction. Run status: COMPLETED.

Parent: [Atlas storage auto-scaling and disk reclaim via compact](https://llms-explorer.com/tree/atlas-storage-auto-scaling-and-disk-reclaim-via-compact/) · 5 facets · 15 facts · page: https://llms-explorer.com/tree/archive-and-ttl-data-lifecycle-followed-by-compaction/

## How it works

- When introducing TTL to an existing populated collection or shortening expireAfterSeconds, many documents may become eligible at once. MongoDB recommends deleting qualifying documents in small batches and scheduling index creation during quiet periods to control the deletion workload. (low confidence) — [source](https://www.mongodb.com/docs/manual/core/index-ttl.md)
- Creating a TTL index over an existing backlog, or shortening expireAfterSeconds, can trigger a large delete workload. MongoDB recommends deleting qualifying records in small batches first; after extensive deletion, collection compaction or initial sync may be needed to reclaim space. (medium confidence) — [source](https://www.mongodb.com/docs/manual/core/index-ttl.md)
- Validate post-cleanup compaction by comparing collection statistics before and after and checking operating-system disk usage. Monitor progress through MongoDB logs or currentOp; retain disk headroom because compact itself may need additional space. (medium confidence) — [source](https://www.mongodb.com/docs/manual/reference/command/compact.md)
- For MongoDB 8.0, compact introduced dryRun to estimate reclaimable bytes without performing compaction. Use the estimate after retention cleanup when deciding whether the maintenance is worthwhile; it is not a promise of the eventual amount recovered. (low confidence) (verified as of 2026-10-31) — [source](https://www.mongodb.com/docs/manual/reference/command/compact.md)

## Measurements and reference values

- In a self-reported case study, Geopits says it archived roughly 140 GB of April–September 2025 data to S3, compacted six collections during approved downtime, and recovered approximately 128 GB, reducing utilization from 87% to 56%. This is an environment-specific outcome, not a reclaim ratio for TTL or Atlas Online Archive. (low confidence) — [source](https://www.geopits.com/case-studies/shemaroo-mongodb-disk-space-optimization)

## Problems, failure modes and limitations

- A recent first-party reporter in SERVER-135779 described continuous short-lived large-document deletion followed by compact freeing no bytes, despite a smaller rewritten collection. The opened ticket was updated October 28, 2026 and marked Closed / Cannot Reproduce; treat this as an anecdotal limitation, not a confirmed server defect. (low confidence) (verified as of 2026-10-31) — [source](https://jira.mongodb.org/browse/SERVER-135779)

## Comparisons and alternatives

- Compaction after a substantial permanent deletion can reclaim operating-system disk space, but it is conditional maintenance rather than a mandatory step after every TTL pass. MongoDB describes it as an attempt; Percona motivates it specifically when the collection will not reuse the deleted space. (high confidence) — [source](https://www.mongodb.com/docs/manual/reference/command/compact.md)

## Facts and statements

- TTL indexes automatically delete expired documents; Atlas Online Archive instead preserves infrequently accessed data in cloud object storage and provides queries across live and archived datasets. Choose deletion or preservation according to the retention requirement before planning reclamation. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/index-ttl.md)
- Atlas Online Archive offers managed archival of infrequently accessed data to S3; archived data remains accessible through Atlas Data Federation. (medium confidence) — [source](https://www.mongodb.com/docs/manual/core/index-ttl.md)
- TTL expiration is asynchronous: the monitor runs every 60 seconds, and workload can delay removal beyond that interval. Reaching the retention cutoff does not prove the cleanup has finished; metrics.ttl.deletedDocuments and currentOp expose deletion activity. (low confidence) — [source](https://www.mongodb.com/docs/manual/core/index-ttl.md)
- After substantial archival-related deletion or a TTL retention reduction, evaluate whether compact or initial sync is needed to recover disk space. MongoDB documents these as possible follow-up operations after large deletions, and Percona documents the same maintenance alternatives. (medium confidence) — [source](https://www.mongodb.com/docs/manual/core/index-ttl.md)
- Routine TTL expiry does not establish a universal requirement for scheduled compaction. In a reproducible MongoDB 7.0.16 experiment with steady inserts and five-minute TTL expiry, storage stabilized without manual compact; a manual compact reduction was temporary as insertion continued. This experiment does not establish the outcome for a one-time large retention cut. (low confidence) — [source](https://dev.to/mongodb/mongodb-ttl-and-disk-storage-2d35)
- A practical sequence is archive eligible historical records, complete the deletion phase, then assess targeted compaction. This is a synthesis of MongoDB lifecycle/deletion guidance and Geopits first-party archival-and-compaction work; compaction does not itself move documents into an archive. (medium confidence) — [source](https://www.mongodb.com/docs/manual/core/index-ttl.md)
- Plan compaction as a measured maintenance operation after cleanup: MongoDB says compact may need additional disk space and can interfere with backups through checkpoint overhead; Percona recommends an up-to-date backup before compact maintenance. (medium confidence) — [source](https://www.mongodb.com/docs/manual/reference/command/compact.md)
- Successful command completion does not guarantee that compaction shrinks the physical footprint. MongoDB says effectiveness depends on available blocks and their location; Percona also reports cases where compact returns OK with unchanged physical collection space. (high confidence) — [source](https://www.mongodb.com/docs/manual/reference/command/compact.md)
