# $group accumulator memory caps > Source-anchored research for $group accumulator memory caps. Run status: COMPLETED. Parent: [MongoDB Advanced Explain: Aggregation, Sharded Plans, Loose Index Scans and the 8.3 Cost-Based Ranker](https://llms-explorer.com/tree/mongodb-advanced-explain-aggregation-sharded-plans-loose-index-scans-and-the-8-3-cost-based-ranker/) · 4 facets · 8 facts · page: https://llms-explorer.com/tree/group-accumulator-memory-caps/ ## 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](https://www.mongodb.com/docs/v8.3/reference/operator/aggregation/group/) ## 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](https://www.mongodb.com/docs/v8.3/reference/operator/aggregation/accumulator/) - 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](https://jira.mongodb.org/browse/SERVER-73315) - 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](https://www.mongodb.com/docs/v8.3/reference/operator/aggregation/accumulator/) - 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](https://www.mongodb.com/docs/v8.3/core/aggregation-pipeline-limits/) ## 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](https://jira.mongodb.org/browse/SERVER-73315) ## 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](https://jira.mongodb.org/browse/SERVER-49027) - 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](https://www.mongodb.com/docs/v8.3/reference/explain-results/)