How to Size a VPS Plan: RAM, vCPU, and Storage Requirements by Workload

Sizing a VPS comes down to three numbers, and most buyers guess all three wrong. They pick a plan by price, install a stack, and then discover that memory ran out before CPU, or that the disk filled with logs long before traffic grew. This guide breaks the decision into per-workload measurements so the plan you buy matches the load you will actually run. Our VPS hosting overview lists the plan shapes used in the examples below.

The method is the same everywhere: benchmark the workload on any machine, record peak RSS, count CPU-seconds per request, and project disk growth from real file sizes. Once you have those three curves, plan selection stops being guesswork and becomes arithmetic with a safety margin.

Start With a Measured Baseline, Not a Spec Sheet

Run your application on a spare VM or a local container and measure it under representative traffic. For PHP, `ab -n 2000 -c 20` plus `pidstat -r -p ALL 1` gives you peak resident memory per worker. For Node or Python, use `pm2 monit` or `systemd-cgtop` while replaying access logs with `vegeta`. Record the ceiling, not the average, because memory exhaustion is caused by peaks.

CPU is trickier than it looks. A vCPU is a hypervisor time slice, so a process that shows 100% of one core may still be waiting on steal time. Check `vmstat 1` for the `st` column; anything consistently above 5% means the physical host is oversubscribed and your effective core is weaker than advertised.

RAM Is the Constraint That Kills First

Memory is the resource that produces hard failures. When RAM runs out the kernel invokes the OOM killer, which picks a victim by score and kills it without warning. A site that fits comfortably sits at 60% of total; a site that fits badly sits at 95% and lives one traffic spike away from a restart.

Build the memory budget from components: base OS (350–500 MB for a minimal Debian or AlmaLinux install), database buffer pool (MySQL `innodb_buffer_pool_size` typically 25–40% of RAM), application workers, and the web server. Leave 15% unallocated for page cache and kernel structures. A 4 GB plan with 1.5 GB of buffer pool, 1.8 GB of PHP workers, and 300 MB of nginx is realistic; the same workload on 2 GB will swap.

vCPU Count Depends on Concurrency Model

Compare two common stacks. A static nginx site serves tens of thousands of requests per second from one core because the event loop never blocks. A WordPress install with ten PHP-FPM children spends most of its time waiting on MySQL, so adding cores helps until the database becomes the bottleneck. Measure with `mpstat -P ALL 1` to see whether one core absorbs everything or the load spreads evenly.

Practical floors: one vCPU for a low-traffic static site, two for a small CMS with a local database, and four or more for anything doing image processing, video transcoding, or compiling. If the workload is bursty, consider a burstable plan but verify the CPU credit balance in advance; sustained overuse on a credit-based instance silently throttles to a fraction of baseline.

Storage: Size, Type, and IOPS Are Separate Questions

Disk size is the easiest number to project and the easiest to get wrong. Add the OS (8–10 GB), the application (1–3 GB), the database (grows with rows and indexes), logs, and backups. Leave 20% free for filesystem performance; ext4 slows sharply past 85% utilization and XFS fragments indexes when nearly full.

Type matters more than size on a VPS. Network-attached SSD volumes give 3,000–10,000 IOPS depending on plan tier, while local NVMe reaches hundreds of thousands. Database workloads with high random-write rates need the higher tier; a static site that reads from page cache does not. Measure with `fio –randwrite –bs=4k –iodepth=32 –size=1G` and compare the result to the plan’s published limits.

Per-Workload Reference Table

The table below reflects measured baselines from typical deployments, with headroom built in.

Headroom and Burst Factors

Steady-state headroom of 30% is the minimum for a production site; 50% is comfortable. Traffic is not uniform, and a marketing email or a social post can triple request rate for an hour without warning. A plan provisioned at 90% of capacity has no room to absorb that and will either swap or throttle.

Seasonal workloads need a plan with vertical scaling available. Check whether the provider resizes by reboot or live, and how long the resize takes. A 20-minute reboot is acceptable for a scheduled upgrade, painful during an incident. Document the resize path before launch so nobody fumbles it at 2 a.m. The plan comparison page notes which tiers allow upgrades in place.

Benchmark Before and After the Purchase

Once the instance is live, rerun the same tests you ran on the scratch machine and compare. Differences larger than 20% in CPU time or 30% in memory point to noisy neighbors or a plan that is misrepresented. Record the results in a file; future sizing decisions build on them.

Set up monitoring that alerts on the three metrics that matter: memory above 85%, steal time above 5%, and disk above 80%. These thresholds give days of warning before failures, which is enough time to resize during a maintenance window rather than during an outage. Sizing is a process that continues after purchase, not a one-time decision made at checkout.