MongoDB VPS Requirements: WiredTiger Cache, RAM, NVMe & Production Sizing

MongoDB VPS requirements are dominated by memory and storage behaviour. MongoDB’s WiredTiger engine uses an internal cache plus the operating system filesystem cache, so giving the database enough RAM can reduce disk pressure and improve latency. MongoDB’s production notes recommend sufficient RAM/CPU and explain that the default WiredTiger cache is derived from available memory.

WiredTiger memory model

MongoDB documents the default WiredTiger internal cache as the larger of 50% of (RAM minus 1 GB) or 0.256 GB, with additional free memory left for the filesystem cache and other processes. That design assumes one MongoDB instance per machine.

If the VPS also runs an application server, Redis or other services, you may need to reduce database cache or choose a larger VPS so the whole system remains stable.

Do not size from database size alone

A 100 GB database does not need 100 GB RAM if only a smaller working set is active. Conversely, a 10 GB database can need significant RAM when traffic is high and indexes/queries touch most of it.

Measure:

• working set;
• WiredTiger cache usage/eviction;
• filesystem cache pressure;
• query latency;
• active operations;
• page faults/swap;
• disk latency.

CPU requirements

WiredTiger is multithreaded and can use multiple cores. MongoDB notes that throughput can increase with concurrent operations up to the useful CPU capacity, then decline when too many operations compete. More vCPU is useful only when the workload can use it.

NVMe and storage

MongoDB performs many random I/O operations. Low-latency NVMe helps when the working set exceeds memory, during checkpoints and for write-heavy workloads. MongoDB’s production guidance also discusses storage configuration and recommends tuning readahead for its access pattern.

Keep the database path on reliable persistent storage. Do not treat temporary/ephemeral local storage as the only copy of production data.

Swap

MongoDB performs best when swapping is avoided or minimised because accessing swap is slower than RAM. MongoDB’s production notes describe swap strategies depending on whether the host runs only MongoDB or also runs other software. The practical goal is to avoid sustained swap pressure while retaining a sensible host failure policy.

4 GB, 8 GB, 16 GB or 32 GB?

These are planning directions, not MongoDB guarantees. Measure serverStatus and real query latency.

Replica sets and high availability

A single MongoDB VPS is one failure domain. Production systems that require database HA commonly use replica sets across separate nodes. That requires additional infrastructure and network planning; do not put all replica-set members on one physical host if the purpose is resilience.

Backups

Replica sets are not backups. A bad delete can replicate just as efficiently as a good write. Keep independent point-in-time/snapshot/logical backups according to the application’s RPO, and test restoration.

Security

• Do not expose the database port openly to the internet.
• Use authentication and least-privilege database users.
• Restrict firewall/security-group sources.
• Keep MongoDB and the OS updated.
• Synchronise time across replica-set members.
• Monitor failed authentication and unusual query patterns.

When to move to dedicated hardware

Dedicated hardware becomes attractive when memory requirements become large, CPU stays saturated, storage latency is business-critical or you want stronger single-tenant performance boundaries. First verify that indexing/query design is not the main bottleneck.

VPSWala sizing path

VPSWala’s KVM catalogue scales through 8, 16, 32, 64, 96 and 128 GB classes, giving MongoDB room to grow before bare metal. Choose the tier from the working set and observed cache/disk behaviour.

Bottom line

MongoDB VPS sizing is a memory-and-I/O problem. Give WiredTiger enough RAM while preserving filesystem/OS headroom, use reliable NVMe, avoid sustained swap, monitor the real working set and add replica/backup architecture when the database becomes business-critical.

Next step: compare VPSWala VPS plans using peak cache usage, active dataset size, write rate and backup requirements.

Frequently asked questions about MongoDB VPS hosting

Should MongoDB share a VPS with the application?

It can for smaller deployments, but shared hosting means the application and WiredTiger compete for CPU and memory. Separate the database when its working set becomes large, independent scaling is useful or application bursts cause database latency.

Does NVMe eliminate the need for RAM?

No. NVMe reduces storage latency, but RAM remains important because WiredTiger and the filesystem cache avoid many disk reads. A working set that repeatedly falls out of memory will still show higher latency than one that fits comfortably.

Is a replica set a backup?

No. Replica sets improve availability and copy current state. They can also replicate an accidental deletion. Keep independent recovery points according to RPO/RTO and test restoration.

Sources

• MongoDB production notes
• MongoDB WiredTiger documentation
• VPSWala KVM VPS catalogue