Sharding Limits

Sharding Release 1 (MongoDB v1.6.0)

Differences from Unsharded Configurations

Sharding must be ran in trusted security mode, without explicit security.
Shard keys are immutable in the current version.
All (non-multi)updates, upserts, and inserts must include the current shard key. This may cause issues for anyone using a mapping library since you don't have full control of updates.

$where

$where works with sharding. However do not reference the db object from the $where function (one normally does not do this anyway).

db.eval() may not be used with sharded collections. However, you may use db.eval() if the evaluation function accesses unsharded collections within your database. Use map/reduce in sharded environments.

getPrevError

getPrevError is unsupported for sharded databases, and may remain so in future releases (TBD). Let us know if this causes a problem for you.

Unique Indexes

For a sharded collection, you may only (optionally) specify a unique constraint on the shard key. Other secondary indexes work (via a global operation) as long as no unique constraint is specified.

Counts

Count is supported with sharding; however, a "count all in collection" will not be instantaneous for a sharded collection as it is for an unsharded collection.

Scale Limits

Goal is support of systems of up to 1,000 shards. Testing so far has been limited to clusters with a modest number of shards (e.g., 20). More information will be reported here later on any scaling limitations which are encountered.

MongoDB sharding supports two styles of operations -- targeted and global. On giant systems, global operations will be of less applicability.