# Atlas tier-fixed index build limits > Source-anchored research for Atlas tier-fixed index build limits. Run status: COMPLETED. Parent: [Index build resource limits (maxNumActiveUserIndexBuilds, disk space)](https://llms-explorer.com/tree/index-build-resource-limits-maxnumactiveuserindexbuilds-disk-space/) · 4 facets · 9 facts · page: https://llms-explorer.com/tree/atlas-tier-fixed-index-build-limits/ ## How it works - A createIndexes request counts as one active user index build even when it builds several indexes. The request shares its memory budget among those indexes; batching therefore avoids additional concurrency slots but does not grant each index a separate full memory budget. (high confidence) — [source](https://www.mongodb.com/docs/v8.3/reference/parameters/) ## Problems, failure modes and limitations - Atlas customers cannot modify maxIndexBuildMemoryUsageMegabytes: the parameter reference explicitly describes its Atlas values as unchangeable cluster-tier defaults, and the index-creation guide independently repeats the restriction. (high confidence) (verified as of 2026-10-23) — [source](https://www.mongodb.com/docs/v8.3/reference/parameters/) - The v8.3 parameter reference also explicitly says Atlas maxNumActiveUserIndexBuilds uses cluster-tier defaults that customers cannot change. Its nearby startup/runtime setParameter example describes server configurability and must not be read as an Atlas override procedure. (low confidence) (verified as of 2026-10-23) — [source](https://www.mongodb.com/docs/v8.3/reference/parameters/) - Reaching maxNumActiveUserIndexBuilds blocks additional user index-build requests until active builds drop below the limit; waiting alone does not establish a failed build. (high confidence) — [source](https://www.mongodb.com/docs/v8.3/reference/parameters/) ## Comparisons and alternatives - The index-build memory limit regulates sorter memory and spilling, rather than setting a maximum final index size: replicated index builds can write sorted runs to temporary files under dbpath/_tmp when their memory allowance is reached. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/index-creation/) ## Facts and statements - MongoDB engineering issue SERVER-114768 reports that dividing a build memory budget among many indexes can require intermediate spill-range merges and extend build duration. It also reports cases where increasing memory lengthens builds that still spill, so a larger budget is not a universal speed guarantee. This is server-level evidence, not an Atlas policy exception. (low confidence) (verified as of 2025-12-09) — [source](https://jira.mongodb.org/browse/SERVER-114768) - SERVER-130149 proposes letting a running build adopt increased maxIndexBuildMemoryUsageMegabytes after a spill boundary. The ticket describes a current runtime-adoption gap and had no fix version on its October 22 update; the proposal does not authorize changes to Atlas tier-fixed settings. (low confidence) (verified as of 2026-10-22) — [source](https://jira.mongodb.org/browse/SERVER-130149) - OneUptime's generic advice to change maxNumActiveUserIndexBuilds through setParameter must be scoped to deployments that permit configuration; MongoDB's Atlas restriction rules out assuming that recipe applies there. (medium confidence) (verified as of 2026-10-23) — [source](https://www.mongodb.com/docs/v8.3/reference/parameters/) - Percona's August 2019 recipe for increasing index-build memory through a configuration file is historical deployment advice, not evidence that current Atlas users can override the managed memory setting. (medium confidence) (verified as of 2026-10-23) — [source](https://www.percona.com/blog/mongodb-impact-free-index-builds-using-detached-replicaset-nodes/)