Unique and TTL index side effects on removal
Parent: Hidden indexes and safe index removal · Published reference · snapshot 2026-10-31
↓ Facts as markdownall context files
Source-anchored research for Unique and TTL index side effects on removal. 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.
How it works
- For an ordinary collection whose only automatic expiration mechanism is the selected TTL index, dropping it removes that mechanism and allows expired documents to accumulate. This follows from TTL deletion using the index; it does not imply that other TTL indexes, application cleanup, or collection-level expiration stop. (medium confidence) [source]
- Recreating a TTL index over accumulated expired data can trigger a large delete workload after the index build completes. Plan off-hours creation or batch removal beforehand; TTL expiration itself does not guarantee immediate document deletion. (low confidence) [source]
- Dropping the only unique index enforcing a key removes that database constraint; duplicates can then enter unless another mechanism prevents them. Mongoose unique: true is an index-building helper, not an independent validator. This removal consequence is inferred from the documented enforcement mechanism. (high confidence) [source]
Problems, failure modes and limitations
- Hiding a unique index preserves its uniqueness constraint, and hiding a TTL index preserves expiration. A hide-before-drop experiment therefore cannot test the loss of these data semantics. (medium confidence) [source]
- A Parse Server issue opened on 2026-04-12 reports repeated startup failure with IndexKeySpecsConflict (code 86) on the _Idempotency TTL index after a server update against MongoDB 8.0. Treat it as a reported integration failure, not proof of a general MongoDB defect or a reason to drop all TTL indexes. (low confidence) (verified as of 2026-04-12) [source]
- Recreating a dropped unique index can fail if duplicates accumulated while the constraint was absent: MongoDB cannot create a unique index over existing violating data. Restoring an application schema declaration alone does not validate away those duplicates. (high confidence) [source]
Facts and statements
- Dropping the sole unique index enforcing a key removes that index’s uniqueness protection. If concurrent writes introduce duplicate keys during the gap, recreating the unique index fails until the violations are resolved; other unique indexes can still impose their own constraints. (medium confidence) [source]
- Hidden indexes remain maintained on writes and consume disk space and memory. Hiding an index is therefore not a way to reclaim the storage needed for another index build. (low confidence) [source]
- Changing an existing TTL interval with collMod does not require a complete index rebuild. Reducing expireAfterSeconds can make many documents immediately eligible for deletion, so MongoDB recommends removing documents in small batches before shortening the interval. (low confidence) [source]
- MongoDB prevents dropping the default _id index directly. The drop-all-indexes operation preserves it; removing it requires dropping the collection. (low confidence) [source]
- Percona ClusterSync documents temporary property changes during replication: source unique indexes become non-unique on the target, and TTL expiration is disabled with the original interval saved. Finalization converts the target indexes back to unique and restores expireAfterSeconds; operators must inspect warnings for unsuccessful index operations. (low confidence) (verified as of 2026-10-13) [source]
- Hiding a unique index keeps its unique constraint active; hiding a TTL index keeps document expiration active. Hidden indexes remain maintained and consume disk space and memory. A hide-first trial therefore tests query-planner impact but does not reproduce constraint, retention, or resource changes caused by dropping the index. (low confidence) [source]
- TTL expiration is asynchronous: the background task runs every 60 seconds, but workload can keep expired data present beyond that interval. Do not promise that rebuilding a TTL index will remove all expired documents within 60 seconds. (low confidence) [source]
- Removing a partial TTL index from a time-series collection does not necessarily disable retention: the collection can have its own expireAfterSeconds setting, and a shorter collection interval takes precedence over the partial TTL interval. (low confidence) [source]
- Before dropping an index, inspect db.collection.getIndexes() and identify the intended index by name; verify its absence afterward. A hidden-index trial can assess query performance, but the trial retains unique and TTL behavior and does not eliminate index maintenance costs. (medium confidence) [source]
Children
- Duplicate cleanup before unique-index recreation (frontier)
- TTL retention restoration and deletion backlog (frontier)
- Hidden-index semantic limitations (frontier)
Frontier under this node: Duplicate cleanup before unique-index recreation, Hidden-index semantic limitations, TTL retention restoration and deletion backlog