Docs Home → Develop Applications → MongoDB Manual
MongoDB Limits and Thresholds![](/docs/v5.3/assets/link.svg)
On this page
This document provides a collection of hard and soft limitations of the MongoDB system.
BSON Documents![](/docs/v5.3/assets/link.svg)
- 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![](/docs/v5.3/assets/link.svg)
- Database Name Case Sensitivity
Database names are case-sensitive in MongoDB. They also have an additional restriction, case cannot be the only difference between database names.
Example
If the database
salesDB
already exists MongoDB will return an error if if you attempt to create a database namedsalesdb
.mixedCase = db.getSiblingDB('salesDB') lowerCase = db.getSiblingDB('salesdb') mixedCase.retail.insertOne({ "widgets": 1, "price": 50 }) The operation succeeds and
insertOne()
implicitly creates theSalesDB
database.lowerCase.retail.insertOne({ "widgets": 1, "price": 50 }) The operation fails.
insertOne()
tries to create asalesdb
database and is blocked by the naming restriction. Database names must differ on more than just case.lowerCase.retail.find() This operation does not return any results because the database names are case sensitive. There is no error because
find()
doesn't implicitly create a new database.
- 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.
- 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.)
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 inmongosh
or a similar method for your driver.Namespace Length:
For featureCompatibilityVersion set to
"4.4"
or greater, MongoDB raises the limit for unsharded collections and views to 255 bytes, and to 235 bytes for sharded collections. For a collection or a view, the namespace includes the database name, the dot (.
) separator, and the collection/view name (e.g.<database>.<collection>
),For featureCompatibilityVersion set to
"4.2"
or earlier, the maximum length of unsharded collections and views namespace remains 120 bytes and 100 bytes for sharded 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.
Naming Warnings![](/docs/v5.3/assets/link.svg)
Warning
Use caution, the issues discussed in this section could lead to data loss or corruption.
MongoDB does not support duplicate field names![](/docs/v5.3/assets/link.svg)
The MongoDB Query Language is undefined over documents with duplicate field names. BSON builders may support creating a BSON document with duplicate field names. While the BSON builder may not throw an error, inserting these documents into MongoDB is not supported even if the insert succeeds. For example, inserting a BSON document with duplicate field names through a MongoDB driver may result in the driver silently dropping the duplicate values prior to insertion.
Import and Export Concerns With Dollar Signs ($
) and Periods (.
)![](/docs/v5.3/assets/link.svg)
Starting in MongoDB 5.0, document field names can be dollar ($
)
prefixed and can contain periods (.
). However,
mongoimport
and mongoexport
may not work
as expected in some situations with field names that make use of these
characters.
MongoDB Extended JSON v2
cannot differentiate between type wrappers and fields that happen to
have the same name as type wrappers. Do not use Extended JSON
formats in contexts where the corresponding BSON representations
might include dollar ($
) prefixed keys. The
DBRef mechanism is an exception to this
general rule.
There are also restrictions on using mongoimport
and
mongoexport
with periods (.
) in field names. Since
CSV files use the period (.
) to represent data hierarchies, a
period (.
) in a field name will be misinterpreted as a level of
nesting.
Possible Data Loss With Dollar Signs ($
) and Periods (.
)![](/docs/v5.3/assets/link.svg)
There is a small chance of data loss when using dollar ($
) prefixed
field names or field names that contain periods (.
) if these
field names are used in conjunction with unacknowledged writes
(write concern w=0
) on servers
that are older than MongoDB 5.0.
When running insert,
update, and
findAndModify
commands, drivers that are 5.0 compatible remove restrictions on
using documents with field names that are dollar ($
) prefixed or
that contain periods (.
). These field names generated a client-side
error in earlier driver versions.
The restrictions are removed regardless of the server version the driver is connected to. If a 5.0 driver sends a document to an older server, the document will be rejected without sending an error.
Namespaces![](/docs/v5.3/assets/link.svg)
- Namespace Length
For featureCompatibilityVersion set to
"4.4"
or greater, MongoDB raises the limit for unsharded collections and views to 255 bytes, and to 235 bytes for sharded collections. For a collection or a view, the namespace includes the database name, the dot (.
) separator, and the collection/view name (e.g.<database>.<collection>
),For featureCompatibilityVersion set to
"4.2"
or earlier, the maximum length of unsharded collections and views namespace remains 120 bytes and 100 bytes for sharded collection.
Tip
See also:
Indexes![](/docs/v5.3/assets/link.svg)
- Index Key Limit
Note
Changed in version 4.2
Starting in version 4.2, MongoDB removes the Index Key Limit for featureCompatibilityVersion (fCV) set to
"4.2"
or greater.For MongoDB 2.6 through MongoDB versions with fCV set to
"4.0"
or earlier, the total size of an index entry, which can include structural overhead depending on the BSON type, must be less than 1024 bytes.When the Index Key Limit applies:
MongoDB will not create an index on a collection if the index entry for an existing document exceeds the index key limit.
Reindexing operations will error if the index entry for an indexed field exceeds the index key limit. Reindexing operations occur as part of the
compact
command as well as thedb.collection.reIndex()
method.Because these operations drop all the indexes from a collection and then recreate them sequentially, the error from the index key limit prevents these operations from rebuilding any remaining indexes for the collection.
MongoDB will not insert into an indexed collection any document with an indexed field whose corresponding index entry would exceed the index key limit, and instead, will return an error. Previous versions of MongoDB would insert but not index such documents.
Updates to the indexed field will error if the updated value causes the index entry to exceed the index key limit.
If an existing document contains an indexed field whose index entry exceeds the limit, any update that results in the relocation of that document on disk will error.
mongorestore
andmongoimport
will not insert documents that contain an indexed field whose corresponding index entry would exceed the index key limit.In MongoDB 2.6, secondary members of replica sets will continue to replicate documents with an indexed field whose corresponding index entry exceeds the index key limit on initial sync but will print warnings in the logs.
Secondary members also allow index build and rebuild operations on a collection that contains an indexed field whose corresponding index entry exceeds the index key limit but with warnings in the logs.
With mixed version replica sets where the secondaries are version 2.6 and the primary is version 2.4, secondaries will replicate documents inserted or updated on the 2.4 primary, but will print error messages in the log if the documents contain an indexed field whose corresponding index entry exceeds the index key limit.
For existing sharded collections, chunk migration will fail if the chunk has a document that contains an indexed field whose index entry exceeds the index key limit.
- Index Name Length
Note
Changed in version 4.2
Starting in version 4.2, MongoDB removes the Index Name Length limit for MongoDB versions with featureCompatibilityVersion (fCV) set to
"4.2"
or greater.In previous versions of MongoDB or MongoDB versions with fCV set to
"4.0"
or earlier, fully qualified index names, which include the namespace and the dot separators (i.e.<database name>.<collection name>.$<index name>
), cannot be longer than 127 bytes.By default,
<index name>
is the concatenation of the field names and index type. You can explicitly specify the<index name>
to thecreateIndex()
method to ensure that the fully qualified index name does not exceed the limit.
- 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 a2dsphere
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.
- Limited Number of 2dsphere index keys
To generate keys for a 2dsphere index,
mongod
maps GeoJSON shapes to an internal representation. The resulting internal representation may be a large array of values.When
mongod
generates index keys on a field that holds an array,mongod
generates an index key for each array element. For compound indexes,mongod
calculates the cartesian product of the sets of keys that are generated for each field. If both sets are large, then calculating the cartesian product could cause the operation to exceed memory limits.indexMaxNumGeneratedKeysPerDocument
limits the maximum number of keys generated for a single document to prevent out of memory errors. The default is 100000 index keys per document. It is possible to raise the limit, but if an operation requires more keys than theindexMaxNumGeneratedKeysPerDocument
parameter specifies, the operation will fail.
- 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 thatNaN
value is alwaysdouble
.
- 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 forcreateIndexes
is 200 megabytes (for versions 4.2.3 and later) and 500 (for versions 4.2.2 and earlier), shared between all indexes built using a singlecreateIndexes
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.Changed in version 4.2.
For feature compatibility version (fcv)
"4.2"
, the index build memory limit applies to all index builds.For feature compatibility version (fcv)
"4.0"
, the index build memory limit only applies to foreground 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
, a2d
, or ageoHaystack
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![](/docs/v5.3/assets/link.svg)
Data![](/docs/v5.3/assets/link.svg)
- Maximum Number of Documents in a Capped Collection
If you specify the maximum number of documents in a capped collection with
create
'smax
parameter, the value must be less than 2 31 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![](/docs/v5.3/assets/link.svg)
- 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. [1][1] Starting in MongoDB 4.0, the oplog can grow past its configured size limit to avoid deleting the majority commit point
.
Sharded Clusters![](/docs/v5.3/assets/link.svg)
Sharded clusters have the restrictions and thresholds described here.
Sharding Operational Restrictions![](/docs/v5.3/assets/link.svg)
- Operations Unavailable in Sharded Environments
$where
does not permit references to thedb
object from the$where
function. This is uncommon in un-sharded collections.The
geoSearch
command is not supported in sharded environments.In MongoDB 5.0 and earlier, you cannot specify sharded collections in the
from
parameter of$lookup
stages.
- Covered Queries in Sharded Clusters
Starting in MongoDB 3.0, an index cannot cover a query on a sharded collection when run against a
mongos
if the index does not contain the shard key, with the following exception for the_id
index: If a query on a sharded collection only specifies a condition on the_id
field and returns only the_id
field, the_id
index can cover the query when run against amongos
even if the_id
field is not the shard key.In previous versions, an index cannot cover a query on a sharded collection when run against a
mongos
.
- Sharding Existing Collection Data Size
An existing collection can only be sharded if its size does not exceed specific limits. These limits can be estimated based on the average size of all shard key values, and the configured chunk size.
Important
These limits only apply for the initial sharding operation. Sharded collections can grow to any size after successfully enabling sharding.
Use the following formulas to calculate the theoretical maximum collection size.
maxSplits = 16777216 (bytes) / <average size of shard key values in bytes> maxCollectionSize (MB) = maxSplits * (chunkSize / 2) Note
The maximum BSON document size is 16MB or
16777216
bytes.All conversions should use base-2 scale, e.g. 1024 kilobytes = 1 megabyte.
If
maxCollectionSize
is less than or nearly equal to the target collection, increase the chunk size to ensure successful initial sharding. If there is doubt as to whether the result of the calculation is too 'close' to the target collection size, it is likely better to increase the chunk size.After successful initial sharding, you can reduce the chunk size as needed. If you later reduce the chunk size, it may take time for all chunks to split to the new size. See Modify Chunk Size in a Sharded Cluster for instructions on modifying chunk size.
This table illustrates the approximate maximum collection sizes using the formulas described above:
Average Size of Shard Key Values512 bytes256 bytes128 bytes64 bytesMaximum Number of Splits32,76865,536131,072262,144Max Collection Size (64 MB Chunk Size)1 TB2 TB4 TB8 TBMax Collection Size (128 MB Chunk Size)2 TB4 TB8 TB16 TBMax Collection Size (256 MB Chunk Size)4 TB8 TB16 TB32 TB
- Single Document Modification Operations in Sharded Collections
All
update
andremove()
operations for a sharded collection that specify thejustOne
ormulti: false
option must include the shard key or the_id
field in the query specification.update
andremove()
operations specifyingjustOne
ormulti: false
in a sharded collection which do not contain either the shard key or the_id
field return an error.
- Unique Indexes in Sharded Collections
MongoDB does not support unique indexes across shards, except when the unique index contains the full shard key as a prefix of the index. In these situations MongoDB will enforce uniqueness across the full key, not a single field.
Tip
See:
Unique Constraints on Arbitrary Fields for an alternate approach.
- Maximum Number of Documents Per Chunk to Migrate
By default, MongoDB cannot move a chunk if the number of documents in the chunk is greater than 1.3 times the result of dividing the configured chunk size by the average document size.
db.collection.stats()
includes theavgObjSize
field, which represents the average document size in the collection.For chunks that are too large to migrate, starting in MongoDB 4.4:
A new balancer setting
attemptToBalanceJumboChunks
allows the balancer to migrate chunks too large to move as long as the chunks are not labeled jumbo. See Balance Chunks that Exceed Size Limit for details.The
moveChunk
command can specify a new option forceJumbo to allow for the migration of chunks that are too large to move. The chunks may or may not be labeled jumbo.
Shard Key Limitations![](/docs/v5.3/assets/link.svg)
- Shard Key Size
Starting in version 4.4, MongoDB removes the limit on the shard key size.
For MongoDB 4.2 and earlier, a shard key cannot exceed 512 bytes.
- Shard Key Index Type
A shard key index can be an ascending index on the shard key, a compound index that start with the shard key and specify ascending order for the shard key, or a hashed index.
A shard key index cannot be an index that specifies a multikey index, a text index or a geospatial index on the shard key fields.
- Shard Key Selection is Immutable in MongoDB 4.2 and Earlier
Your options for changing a shard key depend on the version of MongoDB that you are running:
Starting in MongoDB 5.0, you can reshard a collection by changing a document's shard key.
Starting in MongoDB 4.4, you can refine a shard key by adding a suffix field or fields to the existing shard key.
In MongoDB 4.2 and earlier, the choice of shard key cannot be changed after sharding.
In MongoDB 4.2 and earlier, to change a shard key:
Dump all data from MongoDB into an external format.
Drop the original sharded collection.
Configure sharding using the new shard key.
Pre-split the shard key range to ensure initial even distribution.
Restore the dumped data into MongoDB.
- Monotonically Increasing Shard Keys Can Limit Insert Throughput
For clusters with high insert volumes, a shard key with monotonically increasing and decreasing keys can affect insert throughput. If your shard key is the
_id
field, be aware that the default values of the_id
fields are ObjectIds which have generally increasing values.When inserting documents with monotonically increasing shard keys, all inserts belong to the same chunk on a single shard. The system eventually divides the chunk range that receives all write operations and migrates its contents to distribute data more evenly. However, at any moment the cluster directs insert operations only to a single shard, which creates an insert throughput bottleneck.
If the operations on the cluster are predominately read operations and updates, this limitation may not affect the cluster.
To avoid this constraint, use a hashed shard key or select a field that does not increase or decrease monotonically.
Hashed shard keys and hashed indexes store hashes of keys with ascending values.
Operations![](/docs/v5.3/assets/link.svg)
- 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()
(New in MongoDB 4.4).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.Changed in version 4.4: For MongoDB 4.2 and prior, blocking sort operations could not exceed 32 megabytes of system memory.
For more information on sorts and index use, see Sort and Index Use.
- Aggregation Pipeline Operation
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:$sort
when the sort operation is not supported by an index
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.Starting in MongoDB 4.2, 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
Starting in MongoDB 4.2, the
$out
stage cannot be used in conjunction with read concern"linearizable"
. That is, if you specify"linearizable"
read concern fordb.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 fordb.collection.aggregate()
, you cannot include the$merge
stage in the pipeline.
- 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 the2d
index for spherical queries that wrap around the poles.
- Geospatial Coordinates
Valid longitude values are between
-180
and180
, both inclusive.Valid latitude values are between
-90
and90
, 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, includethe 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 specify read/write (CRUD) operations on existing collections. For a list of CRUD operations, see CRUD Operations.
Starting in MongoDB 4.4, 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. (Starting in MongoDB 4.2)
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
, orlocal
databases.You cannot write to
system.*
collections.You cannot return the supported operation's query plan (i.e.
explain
).
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.
Starting in MongoDB 4.2, you cannot specify
killCursors
as the first operation in a transaction.
Changed in version 4.4.
The following operations are not allowed in transactions:
Operations that affect the database catalog, such as creating or dropping a collection or an index when using MongoDB 4.2 or lower. Starting in MongoDB 4.4, you can create collections and indexes in transactions unless the transaction is a cross-shard write transaction. For details, see Create Collections and Indexes In a Transaction.
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()
anddb.collection.createIndex()
methods, when using a read concern level other than"local"
.The
listCollections
andlistIndexes
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.Changed in version 3.6: The limit raises from
1,000
to100,000
writes. This limit also applies to legacyOP_INSERT
messages.The
Bulk()
operations inmongosh
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:
- Projection Restrictions
New in version 4.4:
$
-Prefixed Field Path Restriction- Starting in MongoDB 4.4, the
find()
andfindAndModify()
projection cannot project a field that starts with$
with the exception of the DBRef fields.For example, starting in MongoDB 4.4, the following operation is invalid:In earlier version, MongoDB ignores thedb.inventory.find( {}, { "$instock.warehouse": 0, "$item": 0, "detail.$price": 1 } ) // Invalid starting in 4.4 $
-prefixed field projections. $
Positional Operator Placement Restriction- Starting in MongoDB 4.4, the
$
projection operator can only appear at the end of the field path; e.g."field.$"
or"fieldA.fieldB.$"
.For example, starting in MongoDB 4.4, the following operation is invalid:To resolve, remove the component of the field path that follows thedb.inventory.find( { }, { "instock.$.qty": 1 } ) // Invalid starting in 4.4 $
projection operator.In previous versions, MongoDB ignores the part of the path that follows the$
; i.e. the projection is treated as"instock.$"
. - Empty Field Name Projection Restriction
- Starting in MongoDB 4.4,
find()
andfindAndModify()
projection cannot include a projection of an empty field name.For example, starting in MongoDB 4.4, the following operation is invalid:In previous versions, MongoDB treats the inclusion/exclusion of the empty field as it would the projection of non-existing fields.db.inventory.find( { }, { "": 0 } ) // Invalid starting in 4.4 - Path Collision: Embedded Documents and Its Fields
- Starting in MongoDB 4.4, it is illegal to project an embedded
document with any of the embedded document's fields.For example, consider a collection
inventory
with documents that contain asize
field:Starting in MongoDB 4.4, the following operation fails with a{ ..., size: { h: 10, w: 15.25, uom: "cm" }, ... } Path collision
error because it attempts to project bothsize
document and thesize.uom
field:In previous versions, lattermost projection between the embedded documents and its fields determines the projection:db.inventory.find( {}, { size: 1, "size.uom": 1 } ) // Invalid starting in 4.4 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 - Starting in MongoDB 4.4,
find()
andfindAndModify()
projection cannot contain both a$slice
of an array and a field embedded in the array.For example, consider a collectioninventory
that contains an array fieldinstock
:Starting in MongoDB 4.4, the following operation fails with a{ ..., instock: [ { warehouse: "A", qty: 35 }, { warehouse: "B", qty: 15 }, { warehouse: "C", qty: 35 } ], ... } Path collision
error:In previous versions, the projection applies both projections and returns the first element (db.inventory.find( {}, { "instock": { $slice: 1 }, "instock.warehouse": 0 } ) // Invalid starting in 4.4 $slice: 1
) in theinstock
array but suppresses thewarehouse
field in the projected element. Starting in MongoDB 4.4, to achieve the same result, use thedb.collection.aggregate()
method with two separate$project
stages. $
Positional Operator and$slice
Restriction- Starting in MongoDB 4.4,
find()
andfindAndModify()
projection cannot include$slice
projection expression as part of a$
projection expression.For example, starting in MongoDB 4.4, the following operation is invalid:In previous versions, MongoDB returns the first element (db.inventory.find( { "instock.qty": { $gt: 25 } }, { "instock.$": { $slice: 1 } } ) // Invalid starting in 4.4 instock.$
) in theinstock
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![](/docs/v5.3/assets/link.svg)
- Sessions and $external Username Limit
To use Client Sessions and Causal Consistency Guarantees with
$external
authentication users (Kerberos, LDAP, or x.509 users), 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 withnoCursorTimeout()
or amaxTimeMS()
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 thecursor.batchSize()
of thefind()
. 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 therefreshSessions
command. For example:var session = db.getMongo().startSession() var sessionId = session.getSessionId().id 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 withnoCursorTimeout()
to prevent the server from closing the cursor if idle. Thewhile
loop includes a block that usesrefreshSessions
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.