Common Sizing Mistakes
Parent: MongoDB Capacity Planning · Published reference · snapshot 2026-10-24 · skill mongodb-cohort-047d3a5eff67
↓ Facts as markdownall context files
Source-anchored research for Common Sizing Mistakes. 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
- Compressed on-disk collection size is not a direct estimate of WiredTiger cache demand: collection pages are uncompressed in the internal cache, while filesystem caching retains the on-disk representation. Indexes have their own representation and may retain prefix-compression benefits. (high confidence) [source]
How it works
- Increasing WiredTiger cache simply because operating-system memory appears available can reduce filesystem caching and worsen disk access. MongoDB advises avoiding increases above the default; Percona describes why starving file buffering can hurt performance. This concerns cache allocation within a fixed RAM budget, not a claim that adding physical RAM is harmful. (high confidence) [source]
- Connection capacity is a separate sizing constraint. Atlas tiers impose connection limits, and per-process application pools can multiply connection demand. A deployment can therefore exhaust connection capacity even when most established connections do little work. (high confidence) [source]
- Sizing only for steady-state application topology misses deployment and recovery load. Coinbase reported doubled connections during blue-green deployments; CircleCI reported scaling services during database degradation. Inference: include overlapping deployments and backlog recovery when assessing capacity headroom. (medium confidence) [source]
- Dropping an index merely because one node reports zero accesses can make a capacity reduction unsafe. MongoDB documents node-local usage counters and testing with hidden indexes; Percona also warns to check application hints before removing indexes. (high confidence) [source]
- Connection capacity planning should include application process count, independent pools, and deployment overlap. Coinbase documented per-process pools and blue-green deployment connection storms; Atlas documentation separately identifies tier-dependent connection limits. Larger database tiers are therefore not the only possible response to excessive connection demand. (medium confidence) [source]
Problems, failure modes and limitations
- Hardware upgrades do not repair every apparent capacity problem. In CircleCI’s 2019 incident, switching to local SSD storage did not resolve saturation; repeated index declarations, lock contention, and memory-management behavior also contributed. This is historical failure evidence, not a claim about current MongoDB internals. (low confidence) [source]
- Self-managed container sizing must respect the container memory limit and leave room beyond WiredTiger cache. Qubership’s operator troubleshooting warns that setting cache at or above the pod limit causes OOM kills. This is a container-budgeting pitfall, not an Atlas configuration recipe. (high confidence) [source]
Comparisons and alternatives
- Sizing RAM to hold the entire database can overprovision workloads that repeatedly access only a subset of documents; conversely, sizing only for document bytes omits indexes. MongoDB and Percona base memory planning on the frequently accessed working set, including relevant indexes, rather than total stored data alone. (high confidence) [source]
- Ignoring bandwidth can leave a RAM-based tier choice inadequate. Atlas sizing guidance says to consider the maximum traffic borne by an individual node and the nodes that actually serve reads, rather than assuming cluster traffic is evenly distributed. (low confidence) [source]
Facts and statements
- Treating advertised Atlas RAM as available cache overstates capacity: the advertised memory is physical RAM per data-bearing node, and memory must also support operations and system services. Replica-set node RAM is not one pooled cache. (high confidence) [source]
- Adding indexes indiscriminately can manufacture a need for larger hardware: extra indexes increase storage, write-maintenance work, and cache pressure. Review redundant and unused indexes before treating every slowdown as insufficient cluster capacity. (high confidence) [source]
- Allocating all node RAM to the database cache understates total memory needs. Filesystem caching, the operating system, client connections, sorts, and aggregation work also consume memory. (high confidence) [source]
- A connection bottleneck need not mean useful database work requires more compute. In its June 18, 2020 engineering account, Coinbase found many connections mostly unused and reduced connection demand through multiplexing. MongoDB also documents memory overhead for connections. This historical case does not establish current driver defaults or a general savings factor. (medium confidence) [source]
Children
- No children recorded.