This document provides a collection of hard and soft limitations of the MongoDB system.
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.
Changed in version 2.2.
MongoDB supports no more than 100 levels of nesting for BSON documents.
Each namespace, including database and collection name, must be shorter than 123 bytes.
The limitation on the number of namespaces is the size of the namespace file divided by 628.
A 16 megabyte namespace file can support approximately 24,000 namespaces. Each index also counts as a namespace.
The total size of an indexed value must be less than 1024 bytes. MongoDB will not add that value to an index if it is longer than 1024 bytes.
A single collection can have no more than 64 indexes.
The names of indexes, including their namespace (i.e database and collection name) cannot be longer than 125 characters. The default index name is the concatenation of the field names and index directions.
You can explicitly specify an index name to the ensureIndex() helper if the default index name is too long.
There can be no more than 31 fields in a compound index.
See also
The unique indexes limit in Sharding Operational Restrictions.
Changed in version 2.4.
If you specify a maximum number of documents for a capped collection using the max parameter to create, the limit must be less than 232 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 can have no more than 12 members.
Only 7 members of a replica set can have votes at any given time. See can vote Non-Voting Members for more information
Sharded clusters have the restrictions and thresholds described here.
The group does not work with sharding. Use mapReduce or aggregate instead.
db.eval() is incompatible with sharded collections. You may use db.eval() with un-sharded collections in a shard cluster.
$where does not permit references to the db object from the $where function. This is uncommon in un-sharded collections.
The $isolated update modifier does not work in sharded environments.
$snapshot queries do not work in sharded environments.
For existing collections that hold documents, MongoDB supports enabling sharding on any collections that contains less than 256 gigabytes of data. MongoDB may be able to shard collections with as many as 400 gigabytes depending on the distribution of document sizes. The precise size of the limitation is a function of the chunk size and the data size.
Important
Sharded collections may have any size, after successfully enabling sharding.
All single update() and remove() operations must include the shard key or the _id field in the query specification. update() or remove() operations that affect a single document in a sharded collection without the shard key or the _id field return an error.
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.
See
Enforce Unique Keys for Sharded Collections for an alternate approach.
A shard key cannot exceed 512 bytes.
You cannot change a shard key after sharding the collection. If you must change a shard key:
After you insert a document into a sharded collection, you cannot change the document’s value for the field or fields that comprise the shard key. The update() operation will not modify the value of a shard key in an existing document.
For clusters with high insert volumes, a shard keys with monotonically increasing and decreasing keys can affect insert throughput. If you use the _id field that holds default as the shard key, be aware that the default value of the _id field, ObjectID values, this shard key will be monotonically increasing because ObjectID values increment as time-stamps.
When inserting documents with monotonically increasing shard keys, all inserts belong to the same chunk on a single shard. The system will eventually divide the chunk range that receives all write operations and migrate its contents to distribute data more evenly. However, at any moment the cluster can only direct 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.
Changed in version 2.4: Hashed shard keys and hashed indexes store hashes of keys with ascending values.
MongoDB will only return sorted results on fields without an index if the sort operation uses less than 32 megabytes of memory.
$sort produces an error if the operation consumes 10 percent or more of RAM.
See
$or and 2d Index Internals.
Any geometry specified with GeoJSON to $geoIntersects or $geoWithin queries, must fit within a single hemisphere. MongoDB interprets geometries larger than half of the sphere as queries for the smaller of the complementary geometries.
The dot (i.e. .) character is not permissible in database names.
Database names are case sensitive even if the underlying file system is case insensitive.
Changed in version 2.2: For MongoDB instances running on Windows.
In 2.2 the following characters are not permissible in database names:
/\. "*<>:|?
See Restrictions on Database Names for Windows for more information on this change
New in version 2.2.
Collection names should begin with an underscore or a letter character, and cannot:
In the mongo shell, use db.getCollection() to specify collection names that might interact with the shell or are not valid JavaScript.
Field names cannot contain dots (i.e. .), dollar signs (i.e. $), or null characters. See Dollar Sign Operator Escaping for an alternate approach.