- Error code
- 292
- Code name
QueryExceededMemoryLimitNoDiskUseAllowed- Product
- MongoDB
- Versions
- MongoDB 6.0 to 8.0 (wordings checked against the 8.0 source; disk use is allowed by default since 6.0)
- Category
- Queries & Aggregation
- Last reviewed
- 24 October 2026
On this page
What it means
Error 292 means a blocking stage (a sort, $group or $setWindowFields) needed more than its memory limit, 100 megabytes by default, and the operation was not allowed to write temporary files to disk, so MongoDB stopped it.
A sort that cannot use an index must hold the documents in memory, and so must $group and window functions. MongoDB caps each of these stages at 100 megabytes (the sort limit is the parameter internalQueryMaxBlockingSortMemoryUsageBytes, default 104857600 bytes, which is the number in the message). When a stage reaches the cap it can spill to temporary files on disk, but only if disk use is allowed; if it is not, the operation fails with 292.
Since MongoDB 6.0 the allowDiskUseByDefault parameter is true, so on a default configuration large sorts spill instead of failing. The error therefore usually means one of three things: the query passed allowDiskUse: false (or .allowDiskUse(false)), an administrator set allowDiskUseByDefault to false, or the work runs on mongos, which the documentation says never writes temporary files to disk. The message prefix shows where it failed: PlanExecutor error during aggregation for aggregate, Executor error during find command for find.
Spilling is a way to finish, not a fix: it is slower and uses disk. The lasting fix is to make the stage need less memory, above all by letting an index supply the sort order. The current manual also describes a separate per-operation memory limit added in MongoDB 9.0; it does not apply to 8.0 and earlier, and when it is exceeded by a stage that can spill with disk use disallowed it is reported with this same code.
Common causes
- A sort on a field with no supporting index over many or large documents, with allowDiskUse: false.
- A $group with many distinct keys, or accumulators such as $push or $addToSet that collect large arrays, with disk use disallowed.
- allowDiskUseByDefault set to false on the server, so every large sort or group fails unless the query opts in.
- Whole documents carried into the sort or group when only a few fields are needed.
- A $sort without a following $limit where only the first few results are used.
Diagnose it
Read-only These mongosh commands only read data, indexes, statistics and server state (find, aggregate without $out or $merge, getIndexes, stats, currentOp, rs.status). They do not change data, users or settings, so they are safe to run first.
Is disk use allowed by default on this server?
db.adminCommand({ getParameter: 1, allowDiskUseByDefault: 1 })allowDiskUseByDefault: true is the default. If it is false, only operations that pass allowDiskUse: true can spill.
Does the sort use an index?
db.orders.find({ status: "shipped" }).sort({ created_at: -1 }).explain("queryPlanner")The winning plan. A SORT stage means the documents are sorted in memory; an IXSCAN over an index that ends with created_at, with no SORT stage, means the index supplies the order and no blocking sort is needed.
Which indexes exist, and what is the memory limit?
db.orders.getIndexes()
db.adminCommand({ getParameter: 1, internalQueryMaxBlockingSortMemoryUsageBytes: 1 })The indexes on the collection and the sort memory limit in bytes (104857600 by default). Look for an index whose keys start with the equality fields of the filter and end with the sort fields.
How to fix it
Each fix is labelled with what it changes. Try read-only checks and the least invasive fix first, and test changes outside production.
Create an index that supplies the sort order
Changes schemaPut the fields the filter matches exactly first, then the sort fields in the same order and direction. The sort then reads documents in index order and holds nothing in memory.
Caution: Building an index on a large collection adds load and takes time; build it outside peak hours and check that the extra index is worth its write cost.
db.orders.createIndex({ status: 1, created_at: -1 })Reduce what the stage holds
Client or network sideFilter first, keep only the fields you need before the sort or group, and add $limit directly after $sort so the sort keeps only the top results.
db.orders.aggregate([
{ $match: { status: "shipped" } },
{ $project: { _id: 1, customer_id: 1, total: 1, created_at: 1 } },
{ $sort: { created_at: -1 } },
{ $limit: 100 }
])Allow this operation to use disk
Client or network sideFor reports and batch jobs that genuinely need a large sort or group, opt in per operation. Temporary files use disk space for the duration of the operation.
db.orders.aggregate(pipeline, { allowDiskUse: true })
db.orders.find({}).sort({ total: -1 }).allowDiskUse(true)Restore the default allowDiskUseByDefault
Changes configurationIf the server was configured with allowDiskUseByDefault: false by mistake, set it back to true on each mongod (it has no effect on mongos). Make it permanent in the configuration file as well.
Caution: This changes behaviour for every query on the server: large sorts and groups will write temporary files instead of failing. Check free disk space and agree the change with whoever set the parameter.
db.adminCommand({ setParameter: 1, allowDiskUseByDefault: true })Examples
An unindexed sort with disk use turned off
Not reproduced here: no MongoDB server is installed for this site. The text is built in MongoDB 8.0's sorter.cpp and prefixed by run_aggregate.cpp (addContext joins the parts with " :: caused by :: "); it assumes a collection large enough to pass the 100 megabyte limit.
db.orders.aggregate(
[ { $sort: { total: -1 } } ],
{ allowDiskUse: false }
)MongoServerError: PlanExecutor error during aggregation :: caused by :: Sort exceeded memory limit of 104857600 bytes, but did not opt in to external sorting.
A large $group with disk use turned off
Not reproduced here: no MongoDB server is installed for this site. The $group text is the classic engine's (group_processor.cpp in MongoDB 8.0); when the slot-based engine runs the group the wording is the one in the variants above. The collection and fields are illustrative.
db.events.aggregate(
[ { $group: { _id: "$session_id", pages: { $push: "$url" } } } ],
{ allowDiskUse: false }
)MongoServerError: PlanExecutor error during aggregation :: caused by :: Exceeded memory limit for $group, but didn't allow external sort. Pass allowDiskUse:true to opt in.
How to prevent it
Index the sorts your application runs often, using the equality-then-sort key order, and check new queries with explain() for a SORT stage before they reach production.
Keep allowDiskUseByDefault at its default unless you have a reason, pass allowDiskUse: false only where you want a fast failure, and project away unneeded fields before blocking stages.
Common questions
How do I fix "Sort exceeded memory limit of 104857600 bytes"?
Best: add an index that supplies the sort order, or add $limit after $sort. Quick: run the operation with allowDiskUse: true so it can spill to disk.
Why do I get this error when allowDiskUse is on by default?
Since MongoDB 6.0 allowDiskUseByDefault is true, so the error means the query passed allowDiskUse: false, the parameter was set to false, or the stage ran on mongos, which never writes temporary files.
Can I raise the 100 megabyte limit instead?
The limit is a server parameter, but raising it makes every such query use more memory. An index or a smaller working set is the safer fix.
Learn more on CodeWithSQL
Official documentation
- Aggregation pipeline limits (memory restrictions)
- $sort (aggregation)
- cursor.allowDiskUse()
- MongoDB server parameters (allowDiskUseByDefault)
Last technically reviewed 24 October 2026; examples and diagnostics run on MongoDB 8.0 documentation and source (error_codes.yml r8.0.0); not run locally. Codes and code names are checked against MongoDB's error_codes.yml (8.0); no MongoDB server was available, so the examples were not run locally.