Right-Sizing Your VPS: How to Estimate RAM, vCPU, and Disk I/O Before You Migrate from Shared Hosting

Most migration failures are sizing failures, not hosting failures. People move from shared hosting to a VPS, pick a plan based on the provider’s marketing page, and then discover three weeks later that the 1 GB plan is swapping constantly or that the “2 vCPU” tier is slower than the shared account it replaced. Sizing a VPS correctly takes about an hour of measurement and a few simple rules. This guide walks through the RAM, vCPU, and disk I/O estimates that matter, with a checklist you can apply to any workload. Keep our provider comparison table handy so you can match your requirements to actual plan specs.

Start with your current usage, not the marketing page

Before you can size a VPS, you need a baseline of what your application actually consumes. Gather this data over 30 days, capturing both average and peak values:

• free -h sampled every 5 minutes for memory usage and swap activity.
• top or htop for per-process CPU and memory during peak traffic.
• iostat -x 60 for disk utilization and queue depth.
• Access-log analysis (or your analytics platform) to find your real peak request rate.

Size for the 95th percentile of these measurements, not the average. The average hides the spikes that make a site feel slow.

RAM: the first number to get right

RAM is the resource you cannot add after the fact without downtime, so it deserves the most headroom. These baselines assume a single application stack with typical caching enabled:

Workload	RAM baseline	Notes
WordPress + PHP-FPM + MySQL	1–2 GB	Add 512 MB–1 GB for WooCommerce
Node.js or Python app + PostgreSQL	1–4 GB	Depends on worker/thread count
10+ Docker containers	2–4 GB	Containers share the kernel but not memory
Redis or Memcached cache layer	+256–512 MB	Cache should fit in RAM, not swap

If your baseline shows swap activity on the current host, treat that as a hard signal: your next plan needs more RAM than the current one has.

vCPU: count queues, not cores

For web workloads, what matters is how many concurrent processes you can run without queueing. PHP-FPM workers and database connections are the two queues that matter most. A rough formula: one vCPU per 2–4 PHP-FPM workers, and one vCPU for the database on top. A 2 vCPU plan handles a typical WordPress site with a few thousand daily visitors comfortably; you need 4 vCPU when you add heavy cron jobs, video processing, or a busy API. Remember that a vCPU is usually a shared hardware thread, so benchmark the actual plan with sysbench cpu run before committing.

Disk I/O: the most oversold resource

Shared hosting thins out disk I/O more than any other resource, and budget VPS plans can still cap it. If your workload is database-heavy, I/O throughput often matters more than vCPU count. Run fio --name=randread --rw=randread --bs=4k --size=256M --iodepth=1 on any candidate plan and compare random-read IOPS across providers; the differences between NVMe and SATA-backed plans are routinely 3–5x. If you see sustained IOPS below 5,000 on a “high-performance” plan, the provider is throttling you.

A concrete example makes the trade-off clear. A WordPress site with WooCommerce serving 50 concurrent shoppers generates roughly 30–80 queries per second at peak, most of them indexed lookups plus a few table scans during cart updates. On SATA-backed shared storage that workload sits at the edge of the I/O queue and produces 300–800 ms query times; on NVMe with even a modest IOPS cap it drops to 5–30 ms. The same site on the same CPU would feel like two different applications purely because of the storage layer, which is why storage type should be a first-class sizing input, not an afterthought.

Network bandwidth is the fourth, frequently forgotten input. Measure your real monthly transfer from the provider’s usage panel and multiply by 1.5–2x for growth. Plans that advertise “unlimited” bandwidth usually throttle sustained throughput, which shows up as slow uploads, slow backups, and degraded CDN origin pulls.

A 5-step migration sizing checklist

1. Collect 30 days of memory, CPU, and I/O baselines from your current host.
2. Pick RAM first (1–2 GB minimum for typical web apps), then vCPU, then storage type.
3. Add headroom for growth: 20–30% above your 95th-percentile measurements.
4. Choose NVMe storage if your workload has any database component.
5. Benchmark the actual plan (sysbench, fio) during the trial period before migrating data.

Test before you commit

No sizing guide replaces a 7-day trial on the real hardware. Deploy a staging copy of your application, run your benchmark suite, and watch free, vmstat, and iostat under load. Compare the shortlisted plans side by side in our provider comparison table, then run the same tests on the finalists. A plan that survives your own benchmarks will survive your traffic.

If you want predictable pricing while you figure out your sizing, InterServer offers VPS plans from $6/month with NVMe storage options and no long-term contract. See InterServer’s current VPS specs and pricing and run your fio tests on a trial instance before migrating.