# moveCollection and collection isolation on dedicated shards > Source-anchored research for moveCollection and collection isolation on dedicated shards. Run status: COMPLETED. Parent: [Independent shard scaling and per-shard tiering](https://llms-explorer.com/tree/independent-shard-scaling-and-per-shard-tiering/) · 6 facets · 18 facts · page: https://llms-explorer.com/tree/movecollection-and-collection-isolation-on-dedicated-shards/ ## How it works - Isolating collections on dedicated shards can reduce resource contention. MongoDB recommends pairing placement with asymmetric shard hardware when collections differ in CPU, RAM, disk throughput, or growth requirements, while preserving one application connection point. (low confidence) — [source](https://www.mongodb.com/docs/manual/core/sharding-manage-unsharded-collections.md) - For its documented ApsaraDB for MongoDB-to-RDS for MySQL DTS workflow, Alibaba Cloud instructs users not to run moveCollection or other data-distribution commands against migration objects in a source sharded cluster while the migration instance is running, because data inconsistency may result. This is a DTS workflow constraint, not a general MongoDB prohibition. (low confidence) (verified as of 2026-09-30) — [source](https://www.alibabacloud.com/help/en/dts/user-guide/migrate-data-from-an-apsaradb-for-mongodb-instance-to-an-apsaradb-rds-for-mysql-instance) - Atlas Core evaluates eligible shards independently when independent shard scaling is enabled, but the smallest shard must stay within two cluster tiers of the largest; scaling the largest shard can therefore require scaling smaller shards too. Collection isolation does not imply unlimited tier differences. (low confidence) (verified as of 2026-10-30) — [source](https://www.mongodb.com/docs/atlas/cluster-autoscaling-compute-core.md) ## How-to and procedures - Avoid concurrent index builds during moveCollection. MongoDB warns of silent failures; SERVER-132822 describes a queued createIndexes returning ok: 1 after a concurrent move replaces the collection UUID, although the requested index was never created. (medium confidence) (verified as of 2026-08-17) — [source](https://www.mongodb.com/docs/manual/reference/command/moveCollection.md) - Run db.adminCommand({moveCollection: "app.inventory", toShard: "shard02"}) through mongos against the admin database, or use sh.moveCollection("app.inventory", "shard02"). The target is a shard ID, and the deployment must be a sharded cluster. (medium confidence) (verified as of 2026-10-30) — [source](https://www.mongodb.com/docs/manual/reference/command/moveCollection.md) ## Measurements and reference values - Before moving, MongoDB specifies destination free space of at least twice the collection storage size plus index size, expressed as (collection storage size + index size) * 2; I/O utilization below 50%; and CPU load below 80%. These requirements are not database-enforced, and insufficient resources can cause shutdown, degraded performance or longer migration. (low confidence) (verified as of 2026-10-30) — [source](https://www.mongodb.com/docs/manual/reference/command/moveCollection.md) ## Problems, failure modes and limitations - moveCollection retains the single-shard capacity limit of the unsharded collection. MongoDB advises against using it when the collection is too large for one shard and suggests considering sharding as a collection approaches 3 TB; this is guidance, not a stated hard collection-size limit. (low confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/manual/core/sharding-manage-unsharded-collections.md) - Run db.adminCommand({moveCollection: 'database.collection', toShard: 'recipientShardID'}) through mongos against admin. The command applies to unsharded collections in a sharded cluster; it cannot move Queryable Encryption collections. (low confidence) (verified as of 2026-10-30) — [source](https://www.mongodb.com/docs/manual/reference/command/moveCollection.md) - Coordinate moveCollection with DDL and topology changes: the command documentation prohibits add/remove-shard operations, collection creation and certain collection DDL while a move is running. It warns that concurrent index builds can silently fail and advises against starting either operation while the other is active. (low confidence) (verified as of 2026-10-30) — [source](https://www.mongodb.com/docs/manual/reference/command/moveCollection.md) - An August 2026 ArchTenet field report identifies unsharded collections placed in a distant primary-shard region as a latency risk and explicitly identifies moveCollection as a way to select a different hosting shard. This supports auditing placement before automatically deciding to shard a latency-sensitive collection; it does not establish a universal latency saving or cost reduction. (low confidence) (verified as of 2026-08-03) — [source](https://archtenet.dev/blog/mongodb-geosharding-hidden-cost/) ## Comparisons and alternatives - Isolation has a co-location tradeoff: MongoDB recommends keeping frequently joined collections and collections used together in transactions on the same shard to reduce distributed-operation network overhead. (low confidence) — [source](https://www.mongodb.com/docs/manual/core/sharding-manage-unsharded-collections.md) - The command documentation specifies a five-minute minimum move duration and requires the application to tolerate approximately two seconds of blocked writes on the affected collection. Treat online relocation as a latency-sensitive operation rather than a guarantee of uninterrupted writes. (medium confidence) (verified as of 2026-10-30) — [source](https://www.mongodb.com/docs/manual/reference/command/moveCollection.md) ## Facts and statements - Introduced in MongoDB 8.0, moveCollection relocates one unsharded collection to a chosen shard independently of the database primary shard; it does not distribute that collection across multiple shards. (medium confidence) — [source](https://www.mongodb.com/docs/manual/reference/command/moveCollection.md) - Moving a collection with MongoDB Search makes its Search indexes unavailable until they are manually rebuilt. Collection availability during movement therefore does not imply uninterrupted Search availability. (medium confidence) (verified as of 2026-10-30) — [source](https://www.mongodb.com/docs/manual/core/sharding-manage-unsharded-collections.md) - Placing resource-intensive unsharded collections on dedicated shards can reduce competition for CPU, RAM and disk resources while preserving a single application connection point. MongoDB recommends this for collections with different access patterns and resource requirements. (low confidence) — [source](https://www.mongodb.com/docs/manual/core/sharding-manage-unsharded-collections.md) - Collection placement and hardware scaling are separate controls: moveCollection chooses the hosting shard, while Atlas independent shard scaling can size that shard for its workload. Their combination supports collection-specific hardware allocation without sharding each collection. (medium confidence) (verified as of 2026-10-30) — [source](https://www.mongodb.com/docs/manual/core/sharding-manage-unsharded-collections.md) - MongoDB Search indexes become unavailable after moveCollection and require manual rebuilding. Moving a collection with an Atlas Online Archive also marks the archive files Orphaned; archive continuity therefore requires separate planning. (low confidence) (verified as of 2026-10-30) — [source](https://www.mongodb.com/docs/manual/reference/command/moveCollection.md) - The command requires writeConcernMajorityJournalDefault=true, does not support Queryable Encryption collections, and is unavailable on Atlas M0 and Flex clusters. (low confidence) (verified as of 2026-10-30) — [source](https://www.mongodb.com/docs/manual/reference/command/moveCollection.md)