What does allowDiskUse: true do in a MongoDB aggregate() call?

## What the option is `allowDiskUse` is an option on the `aggregate` command (and on `db.collection.aggregate()` in `mongosh`, and on the corresponding driver method). It takes a boolean and applies to the whole pipeline execution, not to one stage: ```javascript db.orders.aggregate(pipeline, { allowDiskUse: true }) ``` It changes nothing about the *results* of the pipeline. It only changes what the server does when a stage runs out of the memory it is allowed to use. ## The 100 MB per-stage limit MongoDB caps the memory an individual aggregation stage may use for accumulated state at 100 MB. This is a per-stage budget, not a per-pipeline one, and it applies to the state the stage holds — not to the total volume of data that flows through it. A pipeline can happily stream a terabyte through `$match` and `$project`, because those stages look at one document at a time and forget it immediately. Blocking stages are different. `$sort` cannot emit its first output document until it has seen its last input document, so in the general case it holds the whole input. `$group` builds one entry per distinct grouping key, each carrying its accumulator state (`$sum`, `$push`, `$addToSet` …), so its footprint grows with the number of distinct keys — and `$push`/`$addToSet` can make each entry large on their own. ## What spilling actually does When a blocking stage exceeds its budget and disk use is permitted, it switches to an external algorithm: partial results are written to temporary files in the server's data directory and merged back later. The operation completes, but it has traded RAM for disk I/O. On a busy production node that I/O competes with everything else the server is doing, so a pipeline that spills is usually both slow itself and disruptive to neighbours. When disk use is *not* permitted, the stage fails the whole operation with a memory-limit error naming the offending stage and telling you to pass `allowDiskUse:true`. ## The default changed in 6.0 Historically the default was "fail loudly": you had to pass `allowDiskUse: true` yourself, and forgetting to do so was one of the most common aggregation errors. From MongoDB 6.0 the server parameter `allowDiskUseByDefault` defaults to true, so a pipeline that exceeds a stage's budget spills instead of erroring, and you can pass `allowDiskUse: false` on a specific operation to opt back into the hard failure. This is worth knowing in an interview because it explains why the same pipeline behaves differently on an older cluster: the failure mode moved from a visible error to a silent slowdown. ## Which stages care Only stages that accumulate state need it — `$sort` and `$group` are the two you should be able to name without hesitating. Streaming stages (`$match`, `$project`, `$addFields`, `$limit`, `$skip`, `$unwind`) hold at most a document (or a document's array) at a time, so the option is irrelevant to them. ## What allowDiskUse is not It does not raise the 16 MB BSON limit that applies to every document the pipeline emits — a `$group` that builds one enormous array with `$push` will still fail on document size no matter how much disk it is allowed. It does not grant a stage more RAM; the budget stays at 100 MB and the overflow goes to files. It does not make anything faster; if anything, a pipeline that starts spilling has just got slower. And it is not a substitute for the real fixes — filtering earlier so less data reaches the blocking stage, carrying fewer fields, or reshaping the work so the blocking stage sees a smaller input. ## How to talk about it The answer an interviewer wants is two-part: what the flag permits (external sort/group when the 100 MB stage budget is exceeded), and the judgment that needing it is a signal. "We turned on allowDiskUse and the job stopped failing" is a fine first-aid story; "we turned it on, then went and found out why a stage was holding that much state" is the senior version.