- Reference >
- MongoDB Limits and Thresholds
MongoDB Limits and Thresholds¶
On this page
This document provides a collection of hard and soft limitations of the MongoDB system.
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
¶ Changed in version 2.2.
MongoDB supports no more than 100 levels of nesting for BSON documents.
Namespaces¶
-
Namespace Length
¶ Each namespace, including database and collection name, must be shorter than 123 bytes.
-
Number of Namespaces
¶ 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 collection and index is a namespace.
Indexes¶
-
Index Key
¶ 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.
-
Number of Indexes per Collection
¶ A single collection can have no more than 64 indexes.
-
Index Name Length
¶ 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.
-
Number of Indexed Fields in a Compound Index
¶ There can be no more than 31 fields in a compound index.
-
Queries cannot use both text and Geospatial Indexes
¶ You cannot combine the
text
command, which requires a special text index, with a query operator that requires a different type of special index. For example you cannot combinetext
with the$near
operator.
See also
The unique indexes limit in Sharding Operational Restrictions.
Data¶
-
Maximum Number of Documents in a Capped Collection
¶ Changed in version 2.4.
If you specify a maximum number of documents for a capped collection using the
max
parameter tocreate
, 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.
-
Data Size
¶ A single
mongod
instance cannot manage a data set that exceeds maximum virtual memory address space provided by the underlying operating system.¶ Operating System Journaled Not Journaled Linux 64 terabytes 128 terabytes Windows 4 terabytes 8 terabytes
-
Number of Collections in a Database
¶ The maximum number of collections in a database is a function of the size of the namespace file and the number of indexes of collections in the database.
See
Number of Namespaces
for more information.
Replica Sets¶
-
Number of Members of a Replica Set
¶ Replica sets can have no more than 12 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.
Sharded Clusters¶
Sharded clusters have the restrictions and thresholds described here.
Sharding Operational Restrictions¶
The
group
does not work with sharding. UsemapReduce
oraggregate
instead.db.eval()
is incompatible with sharded collections. You may usedb.eval()
with un-sharded collections in a shard cluster.$where
does not permit references to thedb
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.The
geoSearch
command is not supported in sharded environments.
-
Covered Queries in Sharded Clusters
¶ MongoDB does not support covered queries for sharded collections.
-
Sharding Existing Collection Data Size
¶ 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.
-
Single Document Modification Operations in Sharded Collections
¶ All single
update()
andremove()
operations must include the shard key or the_id
field in the query specification.update()
orremove()
operations that affect a single document in a sharded collection without 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.
See
Enforce Unique Keys for Sharded Collections for an alternate approach.
Shard Key Limitations¶
-
Shard Key Size
¶ A shard key cannot exceed 512 bytes.
-
Shard Key is Immutable
¶ You cannot change a shard key after sharding the collection. If you must 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.
-
Shard Key Value in a Document is Immutable
¶ 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.
-
Monotonically Increasing Shard Keys Can Limit Insert Throughput
¶ For clusters with high insert volumes, a shard keys with monotonically increasing and decreasing keys can affect insert throughput. If your shard key is the
_id
field, be aware that the default value of the_id
field are ObjectIds. ObjectIds are monotonically increasing, 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 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.
Operations¶
-
Sorted Documents
¶ MongoDB will only return sorted results on fields without an index if the combined size of all documents in the sort operation, plus a small overhead, is less than 32 megabytes.
-
Aggregation Sort Operation
¶ $sort
produces an error if the operation consumes 10 percent or more of RAM.
-
2d Geospatial queries cannot use the $or operator
¶ See
$or
and 2d Index Internals.
-
Spherical Polygons must fit within a hemisphere.
¶
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.
-
Combination Limit with Multiple $in Expressions
¶ Querying with two or more
$in
expressions (e.g.{ a: { $in: [ "a", "b", "c" ] }, b: { $in: [ "b", "c" ] } }
) can hit a combinatorial limit if the query uses a compound index on these fields (e.g.{ a: 1, b: 1 }
). Specifically, if the number of combinations (i.e. the product of the number of distinct elements in the respective arrays) is equal to or greater than 4000000, MongoDB will throw an exception of"combinatorial limit of $in partitioning of result set exceeded"
.
Naming Restrictions¶
-
Database Name Case Sensitivity
¶ MongoDB does not permit database names that differ only by the case of the characters.
-
Restrictions on Database Names for Windows
¶ Changed in version 2.2: Restrictions on Database Names for Windows.
For MongoDB deployments running on Windows, MongoDB will not permit database names that include 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, MongoDB will not permit database names that include 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
¶ New in version 2.2.
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.)
In the
mongo
shell, usedb.getCollection()
to specify collection names that might interact with the shell or are not valid JavaScript.- contain the
-
Restrictions on Field Names
¶ Field names cannot contain dots (i.e.
.
) or null characters, and they must not start with a dollar sign (i.e.$
). See Dollar Sign Operator Escaping for an alternate approach.