# Standalone mongosync hosting and sizing > Source-anchored research for Standalone mongosync hosting and sizing. Run status: COMPLETED. Parent: [Migration and Cutover Cost (Live Migration, mongosync, Dual-Running, Egress)](https://llms-explorer.com/tree/migration-and-cutover-cost-live-migration-mongosync-dual-running-egress/) · 5 facets · 18 facts · page: https://llms-explorer.com/tree/standalone-mongosync-hosting-and-sizing/ ## How it works - Standalone mongosync is a separately operated migration process. It can run on its own hardware, on an operating system different from the database clusters, provided its host can reach both source and destination clusters. (high confidence) — [source](https://www.mongodb.com/docs/mongosync/current/quickstart.md) - Compare mongosync replication lag with the source oplog window during migration. If lag approaches the window, the oplog-sizing guide recommends extending retention or adding CPU or memory to the mongosync host; the FAQ warns that synchronization fails when required source operations roll off the oplog. (high confidence) — [source](https://www.mongodb.com/docs/mongosync/current/reference/oplog-sizing.md) - The mongosync binary is stateless for synchronization restart metadata, which it stores on the destination cluster. Restart synchronization using the same parameters after the process becomes available; the FAQ says automatic process restart requires an external script or process manager. (high confidence) — [source](https://www.mongodb.com/docs/mongosync/current/faq.md) ## Measurements and reference values - The published minimum of 8 CPUs and 24 GB RAM is explicitly for the Cloud Manager migration host running mongosync for push live migrations. The standalone quickstart requires a reachable host but does not publish that same universal minimum; treating the push requirement as a sufficient standalone sizing guarantee exceeds these sources. (medium confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/cloud-manager/tutorial/provision-migration-host.md) - The embedded-verifier documentation budgets approximately 10 GB RAM plus 500 MB per million documents in the migration. Its example formula implies about 60 GB at 100 million documents, so a fixed 24 GB host is insufficient for that verification estimate. This is an estimate for verification-enabled mongosync, not a complete machine-capacity guarantee. (low confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/mongosync/current/reference/verification/embedded.md) - Scaleway's migration guide, reviewed June 30, 2025, recommends using a Scaleway Instance when the database to synchronize exceeds 100 GB. It does not specify a CPU/RAM configuration or demonstrate a universal 100-GB hosting threshold. (low confidence) (verified as of 2025-06-30) — [source](https://www.scaleway.com/en/docs/managed-mongodb-databases/api-cli/cluster-to-cluster-sync/) ## Problems, failure modes and limitations - RightTouch reports that destination autoscaling during rehearsal triggered rolling restarts that interrupted its verifier; it fixed the destination at a larger tier for production. This is a case-specific operational failure report and does not establish that all rolling restarts always fail mongosync. (low confidence) — [source](https://tech.righttouch.co.jp/entry/2026/10/13/123032) - The embedded-verifier guide estimates mongosync memory needs with verification at approximately 10 GB plus 500 MB per million documents. It says insufficient memory causes /start to return an error; increase host memory, or restart with verification disabled if more memory is unavailable. (low confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/mongosync/current/reference/verification/embedded.md) ## Comparisons and alternatives - Verification state is held in memory. Restarting or pausing and restarting mongosync restarts verification rather than resuming its previous progress, which can make verification lag behind the migration; avoid sizing a migration host around routine process restarts. (high confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/mongosync/current/reference/verification/embedded.md) - loadLevel is a workload throttle rather than a host-size setting. The binary documents levels 1 through 4 with default 3, warns that raising it can hurt destination performance, and notes that lowering it can improve performance when source reads or destination writes bottleneck. (low confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/mongosync/current/reference/mongosync-binary.md) ## Facts and statements - Standalone hosting describes where the mongosync executable runs; it does not imply support for a standalone mongod source. The binary supports replica sets and sharded clusters, and a standalone database must first be converted to a replica set. (medium confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/mongosync/current/reference/mongosync-binary.md) - For large or heavily loaded sharded sources, MongoDB recommends one mongosync instance per source shard. A replica-set source permits only one instance. Multiple instances can share one host, but the topology guide recommends multiple host servers for better performance; each instance needs its own shard identifier and port. (low confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/mongosync/current/topologies/multiple-mongosyncs.md) - Migration throughput depends on the database clusters as well as the worker. MongoDB generally recommends a destination with more CPU, memory and disk-I/O capacity than the source; a community migration discussion separately identifies destination writes as a likely bottleneck and recommends a timed dry run. Buying a larger mongosync host alone does not establish sufficient throughput. (medium confidence) — [source](https://www.mongodb.com/docs/mongosync/current/faq.md) - RightTouch reports deploying mongosync on a temporary Google Cloud VM built with Terraform, running it under systemd, and controlling it through an IAP tunnel. The account supports a separate migration-worker deployment but supplies no worker CPU/RAM sizing measurement. (low confidence) — [source](https://tech.righttouch.co.jp/entry/2026/10/13/123032) - A separate practitioner reports running mongosync in a plain Ubuntu container as a Kubernetes pod, isolated from application pods, with control over binary version and resource limits. The account establishes a deployment pattern but publishes no portable worker CPU/RAM sizing result. (low confidence) — [source](https://harikrishnanjr.com/blog/mongosync) - A MongoDB 6.0 user reported apparent collection-copy stalls while destination mongod consumed CPU on range deletions, even after stopping mongosync. The report supports checking database current operations and query plans before attributing a stalled copy to insufficient worker hardware; it does not establish a current-version defect. (low confidence) — [source](https://www.mongodb.com/community/forums/t/mongosync-stuck-during-collection-copy/293398) - Treat network placement as a performance input: the behavior guide says greater latency between mongosync and destination servers slows synchronization, and the Cloud Manager host guide warns against low-bandwidth host environments. CPU and RAM alone do not establish migration throughput. (medium confidence) — [source](https://www.mongodb.com/docs/mongosync/current/reference/mongosync-behavior.md) - Standalone mongosync supports one-time migrations, not a continuously readable disaster-recovery or analytics copy. Migrated destination collections must wait until commit and canWrite=true before accepting application traffic. (high confidence) — [source](https://www.mongodb.com/docs/mongosync/current/quickstart.md)