$group accumulator memory caps
Parent: MongoDB Advanced Explain: Aggregation, Sharded Plans, Loose Index Scans and the 8.3 Cost-Based Ranker · Published reference · snapshot 2026-10-21 · skill ranked-a146e5ac
↓ Facts as markdownall context files
Source-anchored research for $group accumulator memory caps. 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.
Measurements and reference values
- MongoDB 8.3 documents a 100 MB RAM threshold for each $group stage. If the stage can spill and disk use is enabled, it writes temporary data. Since MongoDB 6.0, allowDiskUseByDefault controls the default for eligible stages, and a command's allowDiskUse option can override it. Profiler and diagnostic logs expose usedDisk when a stage spills. (high confidence) (verified as of 2026-10-20) [source]
Problems, failure modes and limitations
- MongoDB's 8.3 $accumulator manual describes a spill path for a custom accumulator operation that exceeds its memory limit: with allowDiskUse enabled, MongoDB stores the in-progress state on disk and later merges disk and memory states through the supplied merge function. The manual also marks server-side JavaScript accumulators deprecated starting in version 8.0. (high confidence) (verified as of 2026-10-21) [source]
- MongoDB's server issues specify a separate default 100 MB cap for each $push and $addToSet accumulator. If either accumulator exceeds its own cap, the query returns ExceededMemoryLimit and cannot spill that accumulator's state, even when the surrounding $group may spill. The internal parameters internalQueryMaxPushBytes and internalQueryMaxAddToSetBytes configure these limits. (high confidence) (verified as of 2026-10-21) [source]
- The MongoDB 8.3 manual marks server-side JavaScript $accumulator as deprecated starting in MongoDB 8.0 and recommends using it only when built-in aggregation operators cannot meet the requirement. (low confidence) (verified as of 2026-10-20) [source]
- Disk spilling does not remove the 16 MiB BSON document limit on returned results. Because $group returns accumulator values in its output document and $push returns an array, one oversized grouped result can still fail even if the stage used disk. (high confidence) [source]
Comparisons and alternatives
- MongoDB Jira SERVER-73315 reproduced a classic-engine case where $push exceeded its 100 MB accumulator guardrail while $group merged spilled segments; the reported sorter merge used about 990 MB. The issue lists 7.1.0-rc0 as the fix version, so this is a historical pre-7.1 bug rather than evidence that MongoDB 8.3 lacks the guardrail. (high confidence) (verified as of 2026-10-21) [source]
Facts and statements
- MongoDB issue SERVER-49027 records that aggregate executionStats and allPlansExecution were extended to report the maximum runtime memory footprint per accumulator, with fix version 4.9.0. The 8.3 explain reference documents stage-level peakTrackedMemBytes but does not say whether the historical per-accumulator field appears in both current execution engines. (medium confidence) (verified as of 2026-10-21) [source]
- MongoDB 8.3 explain documentation lists $group spill metrics including usedDisk, spills, spilledBytes, spilledRecords, and spilledDataStorageSize. It also lists peakTrackedMemBytes for GROUP and SORT; this field is new in 8.3 and reports peak tracked memory during stage execution. (high confidence) (verified as of 2026-10-21) [source]
Children
- custom $accumulator spill and merge semantics (frontier)
- per-accumulator explain memory statistics (frontier)
Frontier under this node: custom $accumulator spill and merge semantics, per-accumulator explain memory statistics