# Sharding Triggers > Source-anchored research for Sharding Triggers. Run status: COMPLETED. Parent: [MongoDB Capacity Planning](https://llms-explorer.com/tree/mongodb-capacity-planning/) · 6 facets · 16 facts · page: https://llms-explorer.com/tree/sharding-triggers/ ## How it works - Consider sharding when measured workload growth approaches the practical resources of one server: query CPU, write or disk-I/O throughput, storage capacity, or working-set memory. Vertical scaling feasibility and cost belong in the decision. (high confidence) — [source](https://www.mongodb.com/docs/manual/sharding.md) - Working-set pressure is a more useful memory trigger than total database size alone. MongoDB identifies working sets larger than RAM as an I/O stressor; Percona distinguishes hot working data from rarely accessed historical data. (high confidence) — [source](https://www.mongodb.com/docs/manual/sharding.md) - Percona identifies backup and restore duration as a reason to consider sharding. Treat this as an operational trigger when measured recovery time exceeds the required recovery objective; its proportional restore-speed example is not a general performance guarantee. (low confidence) — [source](https://www.percona.com/blog/when-should-i-enable-mongodb-sharding/) ## How-to and procedures - Use sustained overload as evidence: growing request queues and persistent disk saturation indicate capacity pressure. Correlate these with throughput and latency, then check query, schema, and index efficiency before deciding to add shards. (high confidence) — [source](https://www.datadoghq.com/blog/monitoring-mongodb-performance-metrics-wiredtiger/) ## Measurements and reference values - No universal gigabyte cutoff justifies sharding. Percona explicitly rejects a hard size threshold; its separate 200–500 GB and 1–2 TB suggestions are planning heuristics, while MongoDB describes resource and throughput limits. (high confidence) — [source](https://www.mongodb.com/docs/manual/sharding.md) - In the October 2010 Foursquare incident, uneven growth exhausted RAM on one shard, queries slowed, and requests backed up. Adding a third shard and moving 5% of data did not immediately relieve memory pressure because of fragmentation. The incident predates WiredTiger becoming MongoDB's default storage engine in version 3.2; treat its fragmentation details as historical context, not a current WiredTiger sizing rule. (low confidence) — [source](https://groups.google.com/g/mongodb-user/c/UoqU8ofp134) ## Problems, failure modes and limitations - Adding replica-set secondaries does not increase primary write capacity. If a well-tuned primary cannot sustain writes, distributing the collection and write workload across shards is a relevant scaling option. (high confidence) — [source](https://www.datadoghq.com/blog/monitoring-mongodb-performance-metrics-wiredtiger/) - Converting the cluster topology is insufficient by itself: MongoDB distributes data at collection level, and an unsharded collection cannot span multiple shards. Capacity planning must identify which collections will actually be partitioned. (high confidence) — [source](https://www.mongodb.com/docs/manual/sharding.md) ## Comparisons and alternatives - Use throughput by operation type, operation latency, accumulating requests, and resource pressure to diagnose whether capacity is running out. Treat these as workload evidence for scaling, rather than making a sharding decision from data volume alone. (medium confidence) — [source](https://www.datadoghq.com/blog/monitoring-mongodb-performance-metrics-wiredtiger/) - Queries without a usable shard key can require broadcasting to every shard and merging results. A plan to shard for throughput should assess how common queries will target shards; scattered requests can increase cost rather than provide proportional scaling. (high confidence) — [source](https://www.mongodb.com/docs/manual/sharding.md) - Sharding increases infrastructure and maintenance complexity, and redistribution consumes resources. Include migration headroom and operational cost in the decision rather than assuming added shards immediately provide their full steady-state benefit. (high confidence) — [source](https://www.mongodb.com/docs/manual/sharding.md) ## Facts and statements - Begin sharding design before the cluster reaches its capacity ceiling. Distributing existing data is resource intensive, and Percona warns that late chunk migration can interfere with production workload; allow operational headroom for the transition. (high confidence) — [source](https://www.mongodb.com/docs/manual/sharding.md) - A hot shard or skewed shard key can prevent added shards from delivering useful capacity. Check key cardinality, value frequency, data distribution, and query patterns before assuming another shard will resolve the bottleneck. (high confidence) — [source](https://www.percona.com/blog/mongodb-sharding-replication-101-the-communitys-questions-answered/) - A large total dataset or occasional page faults alone do not establish a sharding requirement. Assess the active working set and observed performance; the sources do not establish a universal database-size cutoff. (high confidence) — [source](https://www.datadoghq.com/blog/monitoring-mongodb-performance-metrics-wiredtiger/) - Evaluate shard-key suitability before expecting capacity gains: uneven key distribution can concentrate load, while queries without the shard-key prefix may broadcast to all shards and take longer. (high confidence) — [source](https://www.mongodb.com/docs/manual/sharding.md) - Geographic data-placement requirements can motivate sharding independently of throughput exhaustion. MongoDB zones associate shard-key ranges with eligible shards; Percona also identifies jurisdictional placement as a reason to shard. (high confidence) — [source](https://www.mongodb.com/docs/manual/sharding.md)