Per-shard disk IOPS and storage constraints
Parent: Independent shard scaling and per-shard tiering · Published reference · snapshot 2026-10-31
↓ Facts as markdownall context files
Source-anchored research for Per-shard disk IOPS and storage constraints. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
Definitions
- A disk IOPS budget is not a database operations-per-second guarantee: physical reads depend on cache misses, while request size determines byte throughput. (medium confidence) [source]
How it works
- MongoDB queries for data absent from RAM trigger disk reads. Its hardware guidance recommends sizing RAM for frequently accessed data and indexes and considering SSDs for I/O-intensive workloads; this makes each shard’s working set relevant to its storage demand. (low confidence) [source]
- MongoDB’s documented balancer monitors collection data amounts and uses data-size differences to trigger migrations. Inference: equal data placement alone does not demonstrate equal IOPS demand, so per-shard performance needs separate measurement. (low confidence) [source]
Measurements and reference values
- MongoDB’s resharding guidance calls for I/O utilization below 50% and CPU load below 80%; Percona’s MongoDB 5.0 guidance also states these thresholds and says to evaluate resources on each shard. These are operation-planning thresholds, not a general steady-state utilization target. (medium confidence) (verified as of 2026-10-14) [source]
- In Percona’s 2021 MongoDB 5.0 demonstration, two single-member shards on dedicated EC2 virtual hosts resharded a small collection without application workload. Shard IOPS rose and disk latency exceeded 20 ms at the start and end. This experiment does not establish a production latency bound or a current-version benchmark. (low confidence) [source]
Problems, failure modes and limitations
- For Azure VM-backed storage, both the VM and each attached disk impose IOPS and throughput limits; increasing disk performance alone cannot bypass a VM limit. (low confidence) [source]
- MongoDB read performance depends on both the working set and storage speed. Cache-resident reads can mask slow disks, so capacity planning should exercise disk misses. (medium confidence) [source]
- Azure applies both VM-level and managed-disk IOPS and throughput limits. Exceeding either applicable limit can cap application I/O and increase latency; provisioning a faster disk alone cannot remove a VM-level cap. Cached and uncached I/O paths have different limits. (low confidence) [source]
Comparisons and alternatives
- MongoDB warns that growing datasets can consume available disk space on every shard. Monitor per-shard capacity alongside performance rather than treating more IOPS as protection from disk exhaustion. (medium confidence) [source]
Facts and statements
- Sharding can aggregate disk I/O capacity by distributing work across servers, but a shard-key hotspot can leave one shard overloaded while others have spare capacity. (medium confidence) [source]
- The reviewed Atlas Terraform advanced_cluster documentation says disk_size_gb must be equal across all shards and node types. Independent compute sizing therefore does not by itself establish independent disk-capacity sizing. (low confidence) (verified as of 2026-10-30) [source]
- Validate the actual bottleneck before buying storage performance: Percona measured CPU saturation in its benchmark, and MongoDB cautions that synthetic benchmark numbers do not map directly to production workloads. (medium confidence) [source]
- Sizing inference: before increasing a shard’s disk IOPS, identify whether its constraint is disk provisioning, VM I/O capacity, or memory-driven reads. These sources support the underlying constraints, but do not supply a universal per-shard sizing formula. (medium confidence) [source]
- Redistribution consumes resources while applications are running: MongoDB documents migration bandwidth and workload overhead, and Percona observed extra shard disk I/O during resharding. Plan performance headroom for the redistribution operation itself. (medium confidence) [source]
- The MongoDB resharding documentation specifies available storage on each recipient shard of at least 2 * (collection_storage_size + index_size) / shard_count. Its example needs 1.2 TB free on each of four shards for 2 TB of collection storage plus 0.4 TB of indexes. (low confidence) (verified as of 2026-10-14) [source]
- MongoDB states that its documented resharding resource requirements are not enforced by the database. Insufficient resources can exhaust disk space and shut down the database, reduce performance, or prolong the operation. Operators must check headroom before starting. (low confidence) (verified as of 2026-10-14) [source]
Children
- No children recorded.