# Safe index removal: locks, rollback and regression checks > Source-anchored research for Safe index removal: locks, rollback and regression checks. Run status: COMPLETED. Parent: [Unused index detection with $indexStats](https://llms-explorer.com/tree/unused-index-detection-with-indexstats/) · 4 facets · 19 facts · page: https://llms-explorer.com/tree/safe-index-removal-locks-rollback-and-regression-checks/ ## How it works - Preserve the pre-change usage baseline: hiding or unhiding an index resets its $indexStats statistics when the visibility changes. Index recreation and mongod restarts also reset counters, so post-change zeroes are not a continuous history of non-use. (medium confidence) — [source](https://www.mongodb.com/docs/manual/core/index-hidden.md) ## Problems, failure modes and limitations - dropIndexes kills queries using the dropped index, including queries considering it during planning. A removal change therefore needs application error monitoring as well as latency monitoring. (low confidence) — [source](https://www.mongodb.com/docs/manual/reference/command/dropIndexes.md) - Review explicit application hints before hiding or dropping an index. Hidden indexes cannot be hinted; the experimental MongoDB hint article shows that hints force index selection and that a missing named index or an ambiguous key-pattern hint can error. A fallback index does not by itself make an application hint safe. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/index-hidden.md) - A unique-index rebuild can fail if existing or concurrent writes violate the constraint at the end of the build. Together with continued uniqueness enforcement while hidden, this means a successful hide test does not establish that dropping and later recreating a unique index is a safe semantic rollback. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/index-hidden.md) - The Indexterity architecture records a concrete regression-monitoring blind spot: a slow-query-only profiler may miss fast failed hints to a hidden index. Its documented response compares pre-hide and post-hide failures and reports unavailable or partial coverage. This is project-specific operational evidence, not a MongoDB-wide guarantee or an independently reproduced benchmark. (low confidence) — [source](https://github-wiki-see.page/m/FullmetalBober/Indexterity/wiki/Architecture) - Check failed operations separately from latency. Hidden indexes cannot be hinted; the Indexterity author reports that hiding a text index caused queries to fail quickly while its latency-only gate appeared stable. Inference: a faster latency metric alone cannot certify a safe removal trial. (medium confidence) — [source](https://www.mongodb.com/docs/manual/core/index-hidden.md) - Use the explicit reviewed index name for a single-index removal. The dropIndexes wildcard selects multiple indexes, while the default _id index cannot be dropped; a wildcard command is therefore inappropriate for a one-candidate experiment. (low confidence) — [source](https://www.mongodb.com/docs/manual/reference/command/dropIndexes.md) ## Comparisons and alternatives - Treat zero usage as a removal candidate rather than authorization. Percona recommends comparing the uptime window, reviewing every replica-set member because usage is node-local, and confirming with the application team before dropping. (low confidence) — [source](https://docs.percona.com/percona-monitoring-and-management/3/reference/dashboards/dashboard-mongodb-unused-indexes.html) - Recommended regression checks are application latency and errors plus query-level plan and scan work: compare slow queries, collection scans, documents examined versus returned, and host I/O against a representative baseline. This is a synthesis of MongoDB query-plan inspection and Netdata operational guidance about silent index regressions, not a universal numerical acceptance threshold. (medium confidence) — [source](https://www.mongodb.com/docs/manual/core/query-plans.md) - Check node coverage and observation history before approving removal: $indexStats is node-local, and an index unused on one replica-set member can be used on another. Review all relevant members and account for restarts rather than relying on one zero counter. (medium confidence) — [source](https://www.mongodb.com/docs/manual/reference/operator/aggregation/indexStats.md) ## Facts and statements - Hide a candidate index before dropping it to test the effect of excluding it from query planning. If the workload regresses, unhide the maintained index; it is available without rebuilding. A satisfactory hide test can be followed by dropping the still-hidden index. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/index-hidden.md) - The dropIndexes command acquires an exclusive lock on the target collection for the operation duration. The concurrency FAQ also identifies dropIndexes as a collection-locking command. Plan for DDL contention, but do not turn the command page wording into an unconditional claim that every modern read blocks: the FAQ separately documents lock-free reads. (high confidence) — [source](https://www.mongodb.com/docs/manual/reference/command/dropIndexes.md) - Hiding does not simulate every consequence of dropping: hidden indexes still enforce unique constraints, expire TTL documents, receive write updates, and consume disk and memory. SERVER-49160 requested different TTL behavior but was resolved Works as Designed; its proposal is not evidence that hidden TTL expiration stops. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/index-hidden.md) - Creating, deleting, or hiding an index clears the relevant collection plan cache. explain ignores existing cache entries and does not populate the cache, so an explain result alone does not prove the steady-state behavior of application queries after index DDL. (low confidence) — [source](https://www.mongodb.com/docs/manual/core/query-plans.md) - A recovery plan after actual deletion must budget for a new index build. MongoDB describes builds as taking collection locks at their beginning and end and warns that heavy writes can reduce write performance and prolong builds. Saving the exact index definition before deletion is an operational implication of needing recreation, not an instant undo guarantee. (high confidence) — [source](https://www.mongodb.com/docs/manual/reference/command/dropIndexes.md) - dropIndexes obtains an exclusive collection lock. Operations requiring conflicting locks can wait for its release, so account for that contention during removal. Starting in MongoDB 5.0, eligible lock-free reads such as find, count, distinct and aggregate are not blocked solely by a collection-level exclusive lock. (medium confidence) — [source](https://www.mongodb.com/docs/manual/reference/command/dropIndexes.md) - A hidden index remains maintained on writes and continues consuming disk and memory. Hiding therefore tests planner dependence; it does not measure the write or storage savings of physically removing the index. (medium confidence) — [source](https://www.mongodb.com/docs/manual/core/index-hidden.md) - Hidden unique indexes still enforce uniqueness, and hidden TTL indexes still expire documents. Since $indexStats excludes internal TTL deletion activity, zero query accesses and a successful hide test do not establish that removing these indexes preserves application semantics. (medium confidence) — [source](https://www.mongodb.com/docs/manual/core/index-hidden.md) - Regression checks should watch query latency and scan efficiency after hiding or dropping an index. Netdata identifies silent index regressions through COLLSCAN and increasing documents examined relative to documents returned; the Indexterity author describes a hide-and-observe workflow that reverses a hide on degradation. (medium confidence) — [source](https://www.netdata.cloud/guides/mongodb/)