MongoDB Limits and Thresholds

MongoDB Atlas Limitations

The following limitations apply only to deployments hosted in MongoDB Atlas. If any of these limits present a problem for your organization, contact Atlas support.

BSON Documents

BSON Document Size

The maximum BSON document size is 16 megabytes.

The maximum document size helps ensure that a single document cannot use excessive amount of RAM or, during transmission, excessive amount of bandwidth. To store documents larger than the maximum size, MongoDB provides the GridFS API. See mongofiles and the documentation for your driver for more information about GridFS.

Nested Depth for BSON Documents

MongoDB supports no more than 100 levels of nesting for BSON documents. Each object or array adds a level.

Naming Restrictions

Use of Case in Database Names

Do not rely on case to distinguish between databases. For example, you cannot use two databases with names like, salesData and SalesData.

After you create a database in MongoDB, you must use consistent capitalization when you refer to it. For example, if you create the salesData database, do not refer to it using alternate capitalization such as salesdata or SalesData.

Restrictions on Database Names for Windows

For MongoDB deployments running on Windows, database names cannot contain any of the following characters:

/\. "$*<>:|?

Also database names cannot contain the null character.

Restrictions on Database Names for Unix and Linux Systems

For MongoDB deployments running on Unix and Linux systems, database names cannot contain any of the following characters:

/\. "$

Also database names cannot contain the null character.

Length of Database Names

Database names cannot be empty and must have fewer than 64 characters.

Restriction on Collection Names

Collection names should begin with an underscore or a letter character, and cannot:

• contain the $.

• be an empty string (e.g. "").

• contain the null character.

• begin with the system. prefix. (Reserved for internal use.)

• contain .system..

If your collection name includes special characters, such as the underscore character, or begins with numbers, then to access the collection use the db.getCollection() method in mongosh or a similar method for your driver.

Namespace Length:

For featureCompatibilityVersion set to "4.4" or greater, MongoDB raises the limit on collection/view namespace to 255 bytes. For a collection or a view, the namespace includes the database name, the dot (.) separator, and the collection/view name (e.g. <database>.<collection>),

Restrictions on Field Names

• Field names cannot contain the null character.

• The server permits storage of field names that contain dots (.) and dollar signs ($).

• MongodB 5.0 adds improved support for the use of ($) and (.) in field names. There are some restrictions. See Field Name Considerations for more details.

Restrictions on _id

The field name _id is reserved for use as a primary key; its value must be unique in the collection, is immutable, and may be of any type other than an array or regex. If the _id contains subfields, the subfield names cannot begin with a ($) symbol.

Naming Warnings

Namespaces

Namespace Length

For featureCompatibilityVersion set to "4.4" or greater, MongoDB raises the limit on collection/view namespace to 255 bytes. For a collection or a view, the namespace includes the database name, the dot (.) separator, and the collection/view name (e.g. <database>.<collection>),

Tip

See also:

Naming Restrictions

Indexes

Number of Indexes per Collection

A single collection can have no more than 64 indexes.

Number of Indexed Fields in a Compound Index

There can be no more than 32 fields in a compound index.

Queries cannot use both text and Geospatial Indexes

You cannot combine the $text query, which requires a special text index, with a query operator that requires a different type of special index. For example you cannot combine $text query with the $near operator.

Fields with 2dsphere Indexes can only hold Geometries

Fields with 2dsphere indexes must hold geometry data in the form of coordinate pairs or GeoJSON data. If you attempt to insert a document with non-geometry data in a 2dsphere indexed field, or build a 2dsphere index on a collection where the indexed field has non-geometry data, the operation will fail.

Tip

See also:

The unique indexes limit in Sharding Operational Restrictions.

NaN values returned from Covered Queries by the WiredTiger Storage Engine are always of type double

If the value of a field returned from a query that is covered by an index is NaN, the type of that NaN value is always double.

Multikey Index

Multikey indexes cannot cover queries over array field(s).

Geospatial Index

Geospatial indexes cannot cover a query.

Memory Usage in Index Builds

createIndexes supports building one or more indexes on a collection. createIndexes uses a combination of memory and temporary files on disk to complete index builds. The default limit on memory usage for createIndexes is 200 megabytes, shared between all indexes built using a single createIndexes command. Once the memory limit is reached, createIndexes uses temporary disk files in a subdirectory named _tmp within the --dbpath directory to complete the build.

You can override the memory limit by setting the maxIndexBuildMemoryUsageMegabytes server parameter. Setting a higher memory limit may result in faster completion of index builds. However, setting this limit too high relative to the unused RAM on your system can result in memory exhaustion and server shutdown.

• For feature compatibility version (fcv) "4.2" and later, the index build memory limit applies to all index builds.

Index builds may be initiated either by a user command such as Create Index or by an administrative process such as an initial sync. Both are subject to the limit set by maxIndexBuildMemoryUsageMegabytes.

An initial sync operation populates only one collection at a time and has no risk of exceeding the memory limit. However, it is possible for a user to start index builds on multiple collections in multiple databases simultaneously and potentially consume an amount of memory greater than the limit set in maxIndexBuildMemoryUsageMegabytes.

Tip

To minimize the impact of building an index on replica sets and sharded clusters with replica set shards, use a rolling index build procedure as described on Rolling Index Builds on Replica Sets.

Collation and Index Types

The following index types only support simple binary comparison and do not support collation:

• text indexes,

• 2d indexes, and

• geoHaystack indexes.

Tip

To create a text, a 2d, or a geoHaystack index on a collection that has a non-simple collation, you must explicitly specify {collation: {locale: "simple"} } when creating the index.

Hidden Indexes

• You cannot hide the _id index.

• You cannot use hint() on a hidden index.

Sorts

Maximum Number of Sort Keys

• You can sort on a maximum of 32 keys.

• Providing a sort pattern with duplicate fields causes an error.

Data

Maximum Number of Documents in a Capped Collection

If you specify a maximum number of documents for a capped collection using the max parameter to create, the limit must be less than 2 ³² documents. If you do not specify a maximum number of documents when creating a capped collection, there is no limit on the number of documents.

Replica Sets

Number of Members of a Replica Set

Replica sets can have up to 50 members.

Number of Voting Members of a Replica Set

Replica sets can have up to 7 voting members. For replica sets with more than 7 total members, see Non-Voting Members.

Maximum Size of Auto-Created Oplog

If you do not explicitly specify an oplog size (i.e. with oplogSizeMB or --oplogSize) MongoDB will create an oplog that is no larger than 50 gigabytes. [4]

[4]	The oplog can grow past its configured size limit to avoid deleting the majority commit point.

Sharded Clusters

Sharded clusters have the restrictions and thresholds described here.

Operations

Sort Operations

If MongoDB cannot use an index or indexes to obtain the sort order, MongoDB must perform a blocking sort operation on the data. The name refers to the requirement that the SORT stage reads all input documents before returning any output documents, blocking the flow of data for that specific query.

If MongoDB requires using more than 100 megabytes of system memory for the blocking sort operation, MongoDB returns an error unless the query specifies cursor.allowDiskUse(). allowDiskUse() allows MongoDB to use temporary files on disk to store data exceeding the 100 megabyte system memory limit while processing a blocking sort operation.

For more information on sorts and index use, see Sort and Index Use.

Aggregation Pipeline Stages

MongoDB limits the number of aggregation pipeline stages allowed in a single pipeline to 1000.

If an aggregation pipeline exceeds the stage limit before or after being parsed, you receive an error.

Aggregation Pipeline Memory

Each individual pipeline stage has a limit of 100 megabytes of RAM. By default, if a stage exceeds this limit, MongoDB produces an error. For some pipeline stages you can allow pipeline processing to take up more space by using the allowDiskUse option to enable aggregation pipeline stages to write data to temporary files.

The $search aggregation stage is not restricted to 100 megabytes of RAM because it runs in a separate process.

Examples of stages that can spill to disk when allowDiskUse is true are:

• $bucket

• $bucketAuto

• $group

• $sort when the sort operation is not supported by an index

• $sortByCount

Note

Pipeline stages operate on streams of documents with each pipeline stage taking in documents, processing them, and then outputing the resulting documents.

Some stages can't output any documents until they have processed all incoming documents. These pipeline stages must keep their stage output in RAM until all incoming documents are processed. As a result, these pipeline stages may require more space than the 100 MB limit.

If the results of one of your $sort pipeline stages exceed the limit, consider adding a $limit stage.

The profiler log messages and diagnostic log messages includes a usedDisk indicator if any aggregation stage wrote data to temporary files due to memory restrictions.

Aggregation and Read Concern

• The $out stage cannot be used in conjunction with read concern "linearizable". If you specify "linearizable" read concern for db.collection.aggregate(), you cannot include the $out stage in the pipeline.

• The $merge stage cannot be used in conjunction with read concern "linearizable". That is, if you specify "linearizable" read concern for db.collection.aggregate(), you cannot include the $merge stage in the pipeline.

2d Geospatial queries cannot use the $or operator

Tip

See:

• $or

• 2d Index Internals

Geospatial Queries

For spherical queries, use the 2dsphere index result.

The use of 2d index for spherical queries may lead to incorrect results, such as the use of the 2d index for spherical queries that wrap around the poles.

Geospatial Coordinates

• Valid longitude values are between -180 and 180, both inclusive.

• Valid latitude values are between -90 and 90, both inclusive.

Area of GeoJSON Polygons

For $geoIntersects or $geoWithin, if you specify a single-ringed polygon that has an area greater than a single hemisphere, include the custom MongoDB coordinate reference system in the $geometry expression; otherwise, $geoIntersects or $geoWithin queries for the complementary geometry. For all other GeoJSON polygons with areas greater than a hemisphere, $geoIntersects or $geoWithin queries for the complementary geometry.

Multi-document Transactions

For multi-document transactions:

• You can create collections and indexes in transactions. For details, see Create Collections and Indexes in a Transaction

• The collections used in a transaction can be in different databases.

  Note

  You cannot create new collections in cross-shard write transactions. For example, if you write to an existing collection in one shard and implicitly create a collection in a different shard, MongoDB cannot perform both operations in the same transaction.

• You cannot write to capped collections.

• You cannot use read concern "snapshot" when reading from a capped collection. (Starting in MongoDB 5.0)

• You cannot read/write to collections in the config, admin, or local databases.

• You cannot write to system.* collections.

• You cannot return the supported operation's query plan using explain or similar commands.

• For cursors created outside of a transaction, you cannot call getMore inside the transaction.

• For cursors created in a transaction, you cannot call getMore outside the transaction.

• You cannot specify the killCursors command as the first operation in a transaction.

  Additionally, if you run the killCursors command within a transaction, the server immediately stops the specified cursors. It does not wait for the transaction to commit.

The following operations are not allowed in transactions:

• Creating new collections in cross-shard write transactions. For example, if you write to an existing collection in one shard and implicitly create a collection in a different shard, MongoDB cannot perform both operations in the same transaction.

• Explicit creation of collections, e.g. db.createCollection() method, and indexes, e.g. db.collection.createIndexes() and db.collection.createIndex() methods, when using a read concern level other than "local".

• The listCollections and listIndexes commands and their helper methods.

• Other non-CRUD and non-informational operations, such as createUser, getParameter, count, etc. and their helpers.

Transactions have a lifetime limit as specified by transactionLifetimeLimitSeconds. The default is 60 seconds.

Write Command Batch Limit Size

100,000 writes are allowed in a single batch operation, defined by a single request to the server.

The Bulk() operations in mongosh and comparable methods in the drivers do not have this limit.

Views

The view definition pipeline cannot include the $out or the $merge stage. If the view definition includes nested pipeline (e.g. the view definition includes $lookup or $facet stage), this restriction applies to the nested pipelines as well.

Views have the following operation restrictions:

• Views are read-only.

• You cannot rename views.

• find() operations on views do not support the following projection operators:

  • $

  • $elemMatch

  • $slice

  • $meta

• Views do not support $text.

• Views do not support map-reduce operations.

Projection Restrictions

$-Prefixed Field Path Restriction

The find() and findAndModify() projection cannot project a field that starts with $ with the exception of the DBRef fields.For example, the following operation is invalid:

db.inventory.find( {}, { "$instock.warehouse": 0, "$item": 0, "detail.$price": 1 } )

$ Positional Operator Placement Restriction

The $ projection operator can only appear at the end of the field path, for example "field.$" or "fieldA.fieldB.$".For example, the following operation is invalid:

db.inventory.find( { }, { "instock.$.qty": 1 } )

To resolve, remove the component of the field path that follows the $ projection operator.

Empty Field Name Projection Restriction

find() and findAndModify() projection cannot include a projection of an empty field name.For example, the following operation is invalid:

db.inventory.find( { }, { "": 0 } )

In previous versions, MongoDB treats the inclusion/exclusion of the empty field as it would the projection of non-existing fields.

Path Collision: Embedded Documents and Its Fields

You cannot project an embedded document with any of the embedded document's fields.For example, consider a collection inventory with documents that contain a size field:

{ ..., size: { h: 10, w: 15.25, uom: "cm" }, ... }

The following operation fails with a Path collision error because it attempts to project both size document and the size.uom field:

db.inventory.find( {}, { size: 1, "size.uom": 1 } )

In previous versions, lattermost projection between the embedded documents and its fields determines the projection:

• If the projection of the embedded document comes after any and all projections of its fields, MongoDB projects the embedded document. For example, the projection document { "size.uom": 1, size: 1 } produces the same result as the projection document { size: 1 }.

• If the projection of the embedded document comes before the projection any of its fields, MongoDB projects the specified field or fields. For example, the projection document { "size.uom": 1, size: 1, "size.h": 1 } produces the same result as the projection document { "size.uom": 1, "size.h": 1 }.

Path Collision: $slice of an Array and Embedded Fields

find() and findAndModify() projection cannot contain both a $slice of an array and a field embedded in the array.For example, consider a collection inventory that contains an array field instock:

{ ..., instock: [ { warehouse: "A", qty: 35 }, { warehouse: "B", qty: 15 }, { warehouse: "C", qty: 35 } ], ... }

The following operation fails with a Path collision error:

db.inventory.find( {}, { "instock": { $slice: 1 }, "instock.warehouse": 0 } )

In previous versions, the projection applies both projections and returns the first element ($slice: 1) in the instock array but suppresses the warehouse field in the projected element. Starting in MongoDB 4.4, to achieve the same result, use the db.collection.aggregate() method with two separate $project stages.

$ Positional Operator and $slice Restriction

find() and findAndModify() projection cannot include $slice projection expression as part of a $ projection expression.For example, the following operation is invalid:

db.inventory.find( { "instock.qty": { $gt: 25 } }, { "instock.$": { $slice: 1 } } )

In previous versions, MongoDB returns the first element (instock.$) in the instock array that matches the query condition; i.e. the positional projection "instock.$" takes precedence and the $slice:1 is a no-op. The "instock.$": { $slice: 1 } does not exclude any other document field.

Sessions

Sessions and $external Username Limit

To use Client Sessions and Causal Consistency Guarantees with $external authentication users (Kerberos, LDAP, or x.509 users), the usernames cannot be greater than 10k bytes.

Session Idle Timeout

Sessions that receive no read or write operations for 30 minutes or that are not refreshed using refreshSessions within this threshold are marked as expired and can be closed by the MongoDB server at any time. Closing a session kills any in-progress operations and open cursors associated with the session. This includes cursors configured with noCursorTimeout() or a maxTimeMS() greater than 30 minutes.

Consider an application that issues a db.collection.find(). The server returns a cursor along with a batch of documents defined by the cursor.batchSize() of the find(). The session refreshes each time the application requests a new batch of documents from the server. However, if the application takes longer than 30 minutes to process the current batch of documents, the session is marked as expired and closed. When the application requests the next batch of documents, the server returns an error as the cursor was killed when the session was closed.

For operations that return a cursor, if the cursor may be idle for longer than 30 minutes, issue the operation within an explicit session using Mongo.startSession() and periodically refresh the session using the refreshSessions command. For example:

var session = db.getMongo().startSession()
var sessionId = session
sessionId  // show the sessionId
var cursor = session.getDatabase("examples").getCollection("data").find().noCursorTimeout()
var refreshTimestamp = new Date() // take note of time at operation start
while (cursor.hasNext()) {
  // Check if more than 5 minutes have passed since the last refresh
  if ( (new Date()-refreshTimestamp)/1000 > 300 ) {
    print("refreshing session")
    db.adminCommand({"refreshSessions" : [sessionId]})
    refreshTimestamp = new Date()
  }
  // process cursor normally
}

In the example operation, the db.collection.find() method is associated with an explicit session. The cursor is configured with noCursorTimeout() to prevent the server from closing the cursor if idle. The while loop includes a block that uses refreshSessions to refresh the session every 5 minutes. Since the session will never exceed the 30 minute idle timeout, the cursor can remain open indefinitely.

For MongoDB drivers, defer to the driver documentation for instructions and syntax for creating sessions.