Working Set Sizing
Parent: MongoDB Capacity Planning · Published reference · snapshot 2026-10-23 · skill mongodb-cohort-321ef5e25160
↓ Facts as markdownall context files
Source-anchored research for Working Set Sizing. 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
- MongoDB's working set for sizing is the indexes and documents an application accesses frequently during normal operation; it can be a subset of the total stored data. (high confidence) [source]
How it works
- The working set can be smaller than the full database because normal workloads often access only a portion of stored data. Percona describes estimating the frequently requested data, and Atlas says it may be impractical or unnecessary to keep a complete database and all indexes in memory when the workload does not require it. (high confidence) [source]
Measurements and reference values
- Do not treat a fixed RAM-to-dataset percentage as a universal sizing formula. Percona presents a 20% hot-set figure as an example and says workloads differ; Atlas recommends estimating index size and the workload's frequently accessed data. (high confidence) [source]
Comparisons and alternatives
- Atlas estimates working-set size from total index space plus an assumed share of data accessed frequently, then compares the estimate with physical RAM on each data-bearing node when considering cluster tiers. The documentation offers workload assumptions or educated estimates rather than a universal data-size percentage. (medium confidence) [source]
- Keeping the full working set in memory is a performance objective, not a correctness prerequisite. MongoDB's diagnostics FAQ says the working set need not fit in RAM, while its performance guidance allows faster SSDs to complement less RAM when price-performance and workload SLAs justify that trade-off. (high confidence) [source]
- Uniform-random benchmark results are not a universal working-set proxy. Localytics described its benchmark as querying randomly across the full database and unusually unforgiving; real applications may concentrate reads on newer records. Size from representative access patterns and service-level goals instead of applying benchmark throughput or total-dataset ratios to every workload. (medium confidence) [source]
- If large documents contain a small frequently accessed subset, MongoDB's subset pattern stores common data separately from less-used data to reduce the working-set size. This can lower memory needs, with the tradeoff that queries needing complete records may have to read multiple collections. (medium confidence) [source]
Facts and statements
- MongoDB Atlas defines the working set as all indexes plus the documents accessed frequently. Its sizing method adds total index space from db.stats() to an estimate of the data share accessed often, so total stored bytes alone do not determine RAM need. (high confidence) [source]
- Map a working-set estimate to RAM on each data-bearing node. Atlas describes memory per node, and IBM Cloud documents that its MongoDB service allocates memory across members; summing member RAM does not mean one node can use that total. (high confidence) [source]
- For IBM Cloud Databases for MongoDB, billing is based on allocated resources and the service distributes memory across members. Memory sizing is therefore a direct cost decision for this managed service. (medium confidence) (verified as of 2026-10-23) [source]
Children
- No children recorded.