# Sizing The MongoDB sizing methodology is a step-by-step workflow that helps identify the necessary hardware to run MongoDB effectively. It helps you estimate: * **Storage:** The disk space usage for data and indexes. * **RAM:** Ample memory to hold your [working set](#user-content-fn-1)[^1]. and ensure fast queries. * **CPU:** Sufficient processing power for reads, writes, and aggregation workloads. * **Input/Output Operations Per Second (IOPS):** How fast the storage can read or write data. The sizing methodology takes into account your data size, workload type, and performance goals. It applies to both **MongoDB Community** and **MongoDB Enterprise** editions and represents both the official recommendations and commonly adopted production configurations to ensure reliable performance. For more information, refer to the [MongoDB Documentation](https://www.mongodb.com/docs/manual/tutorial/mongot-sizing/introduction/). ## Sizing workflow {% stepper %} {% step %} #### Quantify the Working Set * Add your [**hot documents**](#user-content-fn-2)[^2] and [**hot indexes**](#user-content-fn-3)[^3]. * Target **RAM** ≥ [**working set**](#user-content-fn-1)[^1] for predictable latency; add **\~30–50%** buffer for growth. MongoDB emphasizes proper memory sizing so hot data is in RAM. For more information, refer to the [MongoDB Documentation](https://www.mongodb.com/resources/products/capabilities/performance-best-practices-mongodb-data-modeling-and-memory-sizing).
Estimation Use `db.collection.totalIndexSize()` and recent traffic analysis to identify the most used collections or indexes. Consider the following actions to detect the appropriate sizing before using it in production: * Execute `db.collection.totalIndexSize()` during the design and staging phases to identify the required sizing early on. * Simulate expected workloads in a non-production environment to estimate growth in collections, index usage, and query volume. * Use early-stage testing with realistic workloads to understand which collections and indexes will receive the most activity.
{% endstep %} {% step %} #### Map RAM to WiredTiger Reality * `WiredTiger` uses the larger of 50% × (RAM − 1 GB) or 256 MB for its internal cache. The rest typically acts as a file system cache. Plan RAM with that split in mind. For more information, refer to the [MongoDB Documentation](https://www.mongodb.com/docs/manual/core/wiredtiger/). {% endstep %} {% step %} #### Choose CPU for Concurrency and Compute * Start balanced unless you know it is an aggregation-heavy workload. For example, approximately one vCPU per 4–8 GB of RAM for a **Business** edition. RAM or IOPS are more common bottlenecks than CPU for CRUD-heavy apps. It is recommended to increase cores as aggregation or compute rises. For more information, refer to the [MongoDB Documentation](https://www.mongodb.com/resources/products/capabilities/performance-best-practices-mongodb-data-modeling-and-memory-sizing). {% endstep %} {% step %} #### Plan Storage Capacity and Performance * Use a Solid-State Drive ([SSD](https://docs.ionos.com/cloud/support/general-information/glossary-of-terms#ssd)) Size for: `data` + `indexes` + `journal` + `Oplog` + `20–30% buffer` + `growth`. * The SSD performance depends on volume size. The MongoDB guide explicitly recommends a minimum of 100 GB for **SSD Standard** or **SSD Premium** for optimal performance, even if the capacity is smaller. For more information on performance classes, see [SSD Storage](https://docs.ionos.com/sections-test/guides/storage-and-backup/block-storage/overview/storage-performance#ssd-storage). {% hint style="info" %} **Note:** * For optimal IOPS performance, use **SSD Premium**. For production environments, we strongly recommend using SSD Premium to meet MongoDB’s high IOPS and low-latency demands. * Use **SSD Standard** only if the workload is strictly for development, testing, or has proven low-throughput requirements. {% endhint %} * Upsizing the SSD can reduce latency by increasing available performance headroom. The maximum storage per cluster data volume is 4 TB. To configure storage when setting up a cluster, see [Set Up a MongoDB Cluster](https://docs.ionos.com/sections-test/guides/databases/mongodb/how-tos/set-up-mongodb-cluster). {% endstep %} {% step %} #### Configure the Oplog Size * The `Oplog` acts as a "history buffer" that allows replica nodes to catch up if they fall behind. If this buffer is too small, a node that goes offline for maintenance may not be able to find the data it needs to resync when it comes back online. * Ensure the [**Oplog window**](#user-content-fn-4)[^4] time span of entries covers [**worst-case lag**](#user-content-fn-5)[^5], such as traffic spikes, batch imports, or maintenance. Many teams start at ≥ 24 hours and verify under peak writes. * We recommend sizing your `Oplog` to hold at least 24 hours of history. It provides a safety margin for traffic spikes or server maintenance. {% hint style="info" %} **Note:** You can resize `Oplog` later without downtime using the `replSetResizeOplog` command. {% endhint %} For more information, refer to the [MongoDB Documentation](https://www.mongodb.com/docs/manual/core/replica-set-oplog/#oplog-size). {% endstep %} {% step %} #### Tune Connections and Pools * Use realistic pool sizes and timeouts. Avoid huge idle pools that burn memory or threads with no benefit. * **Connection Scaling Heuristic:** The heuristics refer to the IONOS Cloud operational guidelines. In practice, every MongoDB connection consumes a measurable amount of RAM for thread stacks, network buffers, and session metadata. * **Platform Enforcement:** To guarantee stability, the platform enforces strict connection limits based on your instance's available RAM. It is a safety mechanism to prevent memory exhaustion and protect your database from being shut down by the Linux Out Of Memory (OOM) killer. * **Client Configuration:** Configure your application’s connection pool sizes to stay within these enforced limits. Avoid defining large idle pools, as the server will reject connections once the limit is reached. {% hint style="info" %} **Note:** (RAM in GB − 2 GB system reserve) / 2 = max connections (in thousands). This implies roughly 1 MB per connection, with 2 GB reserved for the OS, journaling, and filesystem cache. {% endhint %}
Formula for Maximum Connections | **Cluster RAM** | **Calculation** | **Maximum Connections** | **Notes** | | --------------- | :-------------: | :---------------------: | ------------------------------------------------------------------ | | 2 GB | (2 − 2)/2 = 0 | ≈ 500 | Sandbox cluster to test the product. | | 4 GB | (4 − 2)/2 = 1 | 1000 | Small development environment cluster. | | 6 GB | (6 − 2)/2 = 2 | 2000 | Staging cluster. | | 8 GB | (8 − 2)/2 = 3 | 3000 | Small production cluster. | | 12 GB | (12 − 2)/2 = 5 | 5000 | Medium production cluster. | | 16 GB | (16 − 2)/2 = 7 | 7000 | Medium cluster with a higher demand for the number of connections. | | 24 GB | (24 − 2)/2 = 11 | 11000 | Large production. | | 32 GB | (32 − 2)/2 = 15 | 15000 | High concurrency setup. | | 48 GB | (48 − 2)/2 = 23 | 23000 | High concurrency setup. | | 64 GB | (64 − 2)/2 = 31 | 31000 | High concurrency setup. |
{% hint style="info" %} **Note:** * For large-scale deployments (>64 GB) requiring more than 64 GB of RAM for high-performance configurations, the maximum connection limit continues to scale linearly. * **Current Platform Limit:** A single instance can scale up to 230 GB RAM, allowing for significantly higher connection limits tailored to massive workloads. {% endhint %}
Logic for calculating the formula for maximum connections * The 2 GB reserve serves the following purposes: * Operating system and filesystem cache. * To manage MongoDB process overhead, such as journaling, page tables, and logs. * Provides a safety buffer to prevent swapping or OOM. * The logic to divide the value by 2 is: * Empirically, about 1 MB per connection is realistic when using `WiredTiger` with default driver pools. Thus, 2 GB supports approximately 2000 connections. * For very large instances (> 32 GB RAM), monitor `connPoolStats and db.serverStatus().connections`, the linear estimate remains valid but can be relaxed slightly as MongoDB’s thread scheduling overhead becomes proportionally smaller.
{% endstep %} {% step %} #### Reserve Headroom and Growth Path * Typical practice is to maintain \~30% free CPU or RAM under steady load, 20–30% free storage, and an `Oplog window` at least as long as your longest maintenance window. It is ideal to scale before sustained utilization exceeds 70–80%. {% endstep %} {% endstepper %} ## Select starting configuration by edition Use these sizes as starting points. Validate with metrics and scale up as needed. | **Workload Size** | **Business Edition (Shared Hardware)** | **Enterprise Edition (Dedicated Hardware)** | **Storage and Operational Notes** | | ----------------------------------------- | :-------------------------------------------------------------------------------------------------------------: | :-------------------------------------------------------------------------------------------------------------------------------------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Development (Non-critical)** |


Architecture: 1 Node (Standalone)

2 vCPU

4-8 GB RAM

|


Architecture: 3 Nodes (Replica Set)

2 Dedicated Cores

4-8 GB RAM

|


Business Warning: 1 node does not provide high availability.

Availability: For use strictly in development or testing purposes.

Enterprise: Starts as a 3-node replica set for accurate production simulation.

| | **Standard Production (Read-mostly API)** |


Architecture: 3 Nodes (Fixed replica set)

4-8 vCPU

16-32 GB RAM

|


Architecture: 3, 5, 7 Nodes (Configurable replica set)

4-6 Dedicated Cores

16-32 GB RAM

|


Production Rule: Do not use one node for production workload.

Enterprise Choice: Choose 5 or 7 nodes primarily for resilience, such as tolerating multiple simultaneous failures, rather than focusing on performance.

| | **High Performance (Write Heavy)** |


Architecture: 3 Nodes (Fixed replica set)

8-16 vCPU

64-128 GB RAM

|


Architecture: 3, 5, 7 Nodes (Configurable replica set)

8-12 Dedicated Cores

64-128 GB RAM

|


Scaling Decision: If you need to scale read or write operations while maintaining data consistency, do not only secondary nodes. Transition to Sharding to multiply your primary nodes.

| | **Massive Scale (Extreme Throughput)** |


Not Available (Limit reached)

|


Architecture: Sharded cluster(Multiple replica sets)

16-31 Dedicated Cores

128-230 GB RAM

|


Scaling Strategy: Transition to Sharding (Horizontal scaling) if you encounter any of the following vertical limit of a single replication set:

  1. RAM: Working set > 230 GB.
  2. IOPS: Write intensity exceeds SSD Premium limits.
  3. CPU: Primary node saturated by locking or compression.
  4. Capacity: The disk size exceeds single-volume limits.
| {% hint style="warning" %} **Warning:** The selected RAM determines the hard limit for concurrent connections. If your application requires more connections than the RAM tier allows, the server will reject new connections to protect itself. Ensure you size the RAM to accommodate your peak connection count to avoid application-side bottlenecks. It applies to both **MongoDB Business** vCPU and **MongoDB Enterprise** dedicated core resources. {% endhint %} ## Configuration guidance * **SSD Sizing:** Increasing the SSD size can improve IOPS per throughput headroom, even when the capacity is sufficient. * **Storage:** Up to 4 TB of data volume is possible per cluster. You can plan the capacity and performance together within this limit. * **Sharding and BI Connector:** It is available only in the **Enterprise** edition. You can [Create a Sharded Database Cluster](https://docs.ionos.com/sections-test/guides/databases/mongodb/api/v1-api/create-a-sharded-cluster) and [Enable the BI Connector](https://docs.ionos.com/sections-test/guides/databases/mongodb/api/v1-api/enable-the-biconnector). * **Partnership:** The service is offered in partnership with [MongoDB](https://www.mongodb.com/company/partners/ionos), Inc. (certified). * **Performance:** If you observe storage latency during peaks, increase the SSD volume size, especially on **SSD Standard** or **SSD Premium**, to unlock higher performance headroom—no app change required. Start at ≥ 100 GB, as per the IONOS Cloud setup guidance to [Set Up a MongoDB Cluster](https://docs.ionos.com/sections-test/guides/databases/mongodb/how-tos/set-up-mongodb-cluster). ## Sizing worksheet This worksheet helps you estimate the resources needed for your MongoDB deployment on IONOS Cloud. | **Criteria** | **Description** | | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Hot Documents** | The documents that are accessed frequently and repeatedly during typical database operations. It is part of the "working set". | | **Hot Index Size** | The total size (in bytes) of the indexes that are actively used by your queries. You can find this by summing `totalIndexSize()` for your collections. | | **Hot Data Bytes** |

The portion of your data and indexes that is actively and frequently accessed by your application.
The working set comprises hot documents, hot index entries, and frequently accessed metadata.

| | **Working Set** | The total size (in bytes) of the actual documents that are frequently accessed or modified. It is the sum of your "hot index size" and "hot data bytes". | | **RAM Target** |

A recommended amount of RAM for your MongoDB instance.
It is calculated by multiplying your "working se"t" by a factor of 1.3 to 1.5. It accounts for WiredTiger memory usage and overhead. For more information, refer to the MongoDB Documentation.

| | **vCPU Target** | The recommended number of [vCPU Servers](https://docs.ionos.com/sections-test/guides/compute-services/compute-engine/vcpu-server) needed to handle your application's concurrency and the complexity of your aggregations (data processing tasks). | | **SSD Capacity** |

The total storage space you need on your SSD.
It includes your data, indexes, journal files (for recovery), Oplog (for replication), and an additional 30% for future growth and overhead. Calculate the value as follows: data + indexes + journal + Oplog + 30% = ≥ value.

| | **SSD Performance** |

To ensure optimal performance, start with an SSD of at least 100 GB, such as the SSD Standard or SSD Premium.
Choose a value of ≥ 100 GB; you can opt to upgrade if latency issues occur.

| | **Oplog Window** |

The time duration between the oldest and newest Oplog entries. It is also known as the Oplog retention window.
The value must be greater than or equal to your most extended maintenance period. It starts at ≥ 24 hours.

| | **Alerts** |

To set alerts when resources, such as CPU, RAM, or storage, reach their limit.
Set at 70% CPU, RAM, or storage capacity; You can plan to scale resources before sustained usage reaches 85%.

| ### Example worksheet for sizing
Goal * The API must handle 500 requests per second, with a mix of read and write operations. * The system’s hot data set is approximately 30 GB, and the hot indexes are approximately 12 GB. * Workload includes moderate aggregation queries. * The `Oplog` window should be 24 to 48 hours in duration.
Solution * **Working Set:** The working set is 42 GB (30 GB of data and 12 GB of indexes), aiming for approximately 55–65 GB of RAM to ensure the WiredTiger and filesystem cache have sufficient headroom. * **Start shape (per node):** Each node begins with 8 vCPUs and 64 GB of RAM in a 3-node replica set configuration. * **Storage:** The logical size is \~80–120 GB, so provision must be at least 300 GB of SSD to ensure capacity, performance headroom, and compliance with the ≥100 GB recommendation. * **Oplog:** Start with the default `Oplog` size, monitor the actual window during peak write load, and resize later using `replSetResizeOplog` if needed. * **Watch:** Monitor cache hit rate and page faults, disk latency and queue depth, replication lag, and slow queries. Scale up—or add shards if using Enterprise—when approaching resource limits.
## Technical reference for SSD Premium sizing **SSD Premium** performance increases linearly with the volume size until it reaches the platform threshold. You may need to provision a larger disk than your data requires to achieve your desired IOPS, a strategy known as "Oversizing". The formula to scale sizing based on performance: * **Read Performance:** 75 IOPS × Volume Size (GB) * **Write Performance:** 50 IOPS × Volume Size (GB)
Sizing Lookup | **Volume Size** | **Write IOPS (Approximately)** | **Read IOPS (Approximately)** | **Notes** | | --------------- | :----------------------------: | :---------------------------: | --------------------------------------------- | | 100 GB | 5,000 | 7,500 | Low performance. | | 200 GB | 10,000 | 15,000 | | | 400 GB | 20,000 | 30,000 | | | 600 GB | 30,000 maximum | 45,000 maximum | Platform threshold reached. | | 1,000 GB | 30,000 | 45,000 | Adding more GB only adds capacity, not speed. | {% hint style="info" %} **Note:** If you need 20,000 Write IOPS, but only have 100 GB of data, you must provision a 400 GB volume to get the required speed. If you need more than 30,000 Write IOPS, you must use **Sharding**. {% endhint %}
[^1]: The total size (in bytes) of the actual documents that are frequently accessed or modified. [^2]: The documents that are accessed frequently and repeatedly during typical database operations. They are part of what MongoDB refers to as the "working set". [^3]: Index keys that are commonly used in queries. Indexes often take more RAM than data. [^4]: The time duration between the oldest and newest `Oplog` entries. It is also known as the **Oplog retention window**. [^5]: The maximum replication delay a secondary node can experience compared to the primary node.