What problem are you trying to solve?

Focus on the what and why of the need you have, not the how you'd like it solved.

When the Performance Advisor recommends a new index, there is no supported way to know how large that index will be before building it. The weight / Impact score tells us how much the index will improve query performance, but nothing in the API or UI tells us what it will cost in disk space or working-set memory. As a result, every recommendation is a one-sided picture: benefit is quantified, cost is not. We cannot make an informed approve/reject decision on an index recommendation without knowing both sides.

What would you like to see happen?

Describe the desired outcome or enhancement.

An estimated size value (in bytes) returned alongside each suggestion from the Performance Advisor API — and ideally also exposed as a standalone endpoint that accepts any index specification plus a target namespace, so the same estimation logic is available for indexes that did not originate from Performance Advisor. Because pre-build sizing is inherently approximate, returning a confidence range (e.g. low/high or p50/p95) rather than a single number would be more honest and more useful than no estimate at a

Why is this important to you or your team?

Explain how the request adds value or solves a business need.

We operate many Atlas clusters and have built automation that pulls Performance Advisor recommendations via the Admin API into a centralized change-approval workflow. The goal is to apply high-impact index recommendations quickly and consistently across the fleet without requiring a DBA to log into each cluster's GUI.

The missing size estimate breaks that workflow. Approving an index without knowing its size risks two concrete failure modes: oversized indexes pushing the working set out of the WiredTiger cache (which silently degrades performance across the entire cluster), and unexpected disk-pressure incidents on clusters with tight headroom. Because we cannot accept that risk in production, every recommendation today still requires manual capacity validation by a DBA before it can be approved — which eliminates most of the operational benefit of having an API in the first place.

In short: this gap is what currently prevents Performance Advisor recommendations from being safely operationalized at scale.

What steps, if any, are you taking today to manage this problem?

We escalated to MongoDB Support, who confirmed no supported pre-build estimation method exists. Their recommended workaround is to clone a subset of the target collection into a separate namespace, build the candidate index there, read collStats.indexSizes, and extrapolate to the full collection size.

We are evaluating this as a fallback, but it has real costs: it consumes cluster resources to clone and index sample data, requires non-trivial scripting to automate per-recommendation, adds time to every approval cycle, and produces a result that is itself only an estimate — because WiredTiger compression ratios and field cardinality distributions do not scale linearly with collection size, so extrapolation from a sample can be off by a meaningful margin.

In the meantime, for clusters where this workaround is too expensive, we either defer the recommendation entirely or accept the risk and measure the actual size post-creation — neither of which is a good answer.