<!-- llms-explorer concept facts · https://llms-explorer.com/tree/initial-sync-index-build-memory-limits/ · pack 2026-10-30 · ~1283 tokens -->

# Initial sync index build memory limits

> Source-anchored research for Initial sync index build memory limits. Run status: COMPLETED.

Parent: [Index build resource limits (maxNumActiveUserIndexBuilds, disk space)](https://llms-explorer.com/tree/index-build-resource-limits-maxnumactiveuserindexbuilds-disk-space/) · 5 facets · 11 facts · page: https://llms-explorer.com/tree/initial-sync-index-build-memory-limits/

## Structure and components

- Very low per-index budgets can also lengthen builds: a multi-index build divides memory across indexes, and SERVER-114768 reports that small budgets require intermediate merges of spill ranges. The server's sorter design confirms that spill iterators themselves consume part of the memory budget. (high confidence) — [source](https://jira.mongodb.org/browse/SERVER-114768)

## How it works

- More index-build memory does not guarantee faster logical initial sync. SERVER-111871 explicitly questioned the benefit of the increased default; SERVER-114768 reports cases where increasing memory lengthened builds when the indexed data still exceeded memory and required spilling. (high confidence) — [source](https://jira.mongodb.org/browse/SERVER-114768)
- Alibaba Cloud documents initial synchronization OOM when adding a node among the potential consequences of excessive collections and indexes. Its explanation includes in-memory WiredTiger dhandle overhead for open objects. This scopes diagnosis beyond the index sorter's configured budget; it does not prove that raising or lowering that budget fixes such failures. (low confidence) — [source](https://www.alibabacloud.com/help/en/mongodb/support/what-do-i-do-if-the-slow-running-or-an-exception-occurs-on-my-instance-due-to-a-large-number-of-collections)

## Measurements and reference values

- MongoDB introduced dedicated initial sync index-build controls in 8.2, with backports to 8.0.13 and 7.0.26. The default budget is 10% of available RAM, bounded below by 200 MB and above by 16384 MB; treating 200 MB as the universal initial sync default is incorrect for these releases. (high confidence) (verified as of 2026-10-30) — [source](https://www.mongodb.com/docs/v8.0/reference/parameters/)
- initialSyncIndexBuildMemoryPercentage, initialSyncIndexBuildMemoryMinMB, and initialSyncIndexBuildMemoryMaxMB control the initial sync budget. The percentage accepts 0 through 80; the minimum and maximum parameters each accept 50 through 10000000 MB. All three support startup and runtime configuration; acceptance at runtime does not establish that an already-running sorter is resized. (high confidence) (verified as of 2026-10-30) — [source](https://www.mongodb.com/docs/v8.0/reference/parameters/)
- The general maxIndexBuildMemoryUsageMegabytes setting defaults to 200 MB and shares its budget among indexes built by one createIndexes command. Index-build memory is separate from WiredTiger cache memory, so a small WiredTiger cache setting alone does not cap the index-build allocation. (high confidence) (verified as of 2026-10-30) — [source](https://www.mongodb.com/docs/v8.0/reference/parameters/)
- Percona's July 30, 2026 technical-preview announcement for its own MongoDB 8.3 distribution states that initial sync index builds use a tunable, bounded 10% of available RAM by default. This is distribution-specific confirmation, not an independent experimental validation of MongoDB's allocation algorithm or performance improvement. (low confidence) (verified as of 2026-07-30) — [source](https://www.percona.com/blog/percona-server-for-mongodb-8-3-technical-preview-is-now-available/)

## Comparisons and alternatives

- Index builds use an external sorter: collection scanning generates index keys, which are sorted in memory and spilled to temporary disk files as necessary. Reaching the sorter budget therefore can cause disk I/O rather than itself proving an out-of-memory failure. (medium confidence) — [source](https://github.com/mongodb/mongo/blob/master/src/mongo/db/index_builds/README.md)

## Facts and statements

- SERVER-102428 documented a logical initial sync accounting/allocation defect: secondary indexes shared maxIndexBuildMemoryUsageMegabytes while the simultaneously built _id index received an additional full allocation. The issue lists fixes in 8.2.0-rc0, 8.1.2, 8.0.13 and 7.0.26. This is historical defect evidence, not a description of all current versions. (low confidence) (verified as of 2025-09-29) — [source](https://jira.mongodb.org/browse/SERVER-102428)
- SERVER-114807 attributes avoidable per-key memory overhead to BSON serialization and sorter serialization observed during the initial-sync investigation. Its public description supplies neither a measured overhead factor nor a demonstrated remediation result. (low confidence) — [source](https://jira.mongodb.org/browse/SERVER-114807)
- Generic index-build memory consumption is separate from the WiredTiger cache. A sorter-memory parameter should therefore not be interpreted as a ceiling on all memory consumed by mongod during initial sync. (low confidence) — [source](https://www.mongodb.com/docs/v8.0/reference/parameters/)
