Most people buy a VPS tier based on price, then wonder why their app crawls or why they're burning cash on idle cores. The trick is matching specs to your actual workload patterns—not the traffic you hope for or the cheapest monthly bill.
I've migrated enough sites to know the pain of undersized plans and oversized budgets. This guide walks you through CPU, RAM, disk I/O, and bandwidth so you land on the right tier the first time.
Start with your current resource usage
Before comparing plans, measure what you already consume. SSH into your existing server or shared host and check baseline metrics.
For CPU and memory:
top -bn1 | head -20
free -h
Look at load average over fifteen minutes and memory committed. If load consistently hits your core count or RAM sits above eighty percent, you're already constrained.
For disk I/O:
iostat -x 5 3
Watch the %util column. Anything above seventy percent under normal traffic means storage is a bottleneck.
Network throughput is harder to profile unless you log bandwidth over weeks, but your current host's panel usually shows monthly transfer. Divide by thirty for a daily average, then multiply by peak-day ratios if you have them.
Write these numbers down. They're your baseline.
CPU cores: match concurrency, not page views
Page views don't map directly to CPU needs. A static blog pulling two million views a month can run on a single core if it's cached. A SaaS dashboard with five thousand users hammering API endpoints needs multiple cores because every request fires database queries, session checks, and third-party calls in parallel.
Single-core VPS plans work for:
- Static sites with CDN caching
- Low-traffic WordPress (under five thousand visits per day, aggressive caching enabled)
- Personal projects, staging environments
- Simple cron jobs or monitoring agents
Two to four cores handle:
- WordPress sites hitting twenty to fifty thousand daily visitors without page builder bloat
- Small e-commerce (WooCommerce, Magento Community with fewer than two hundred SKUs)
- Node.js or Python apps serving a few concurrent requests per second
- Moderate MySQL or PostgreSQL query load
Four to eight cores suit:
- High-traffic WordPress (fifty thousand plus daily, multiple plugins, real-time analytics)
- E-commerce during flash sales or seasonal spikes
- Application servers running background workers alongside web traffic
- Self-hosted CI/CD pipelines compiling code
Beyond eight cores you're into dedicated CPU or bare metal territory, unless you're running containerized microservices or heavy batch processing.
One trap: some budget VPS providers share CPU time heavily. A "four-core" plan might only guarantee fifty percent of those cycles. Check whether cores are dedicated or shared, and read reviews for steal time complaints.
RAM: the hard floor for your stack
RAM is less negotiable than CPU. You either have enough or your kernel starts killing processes.
Here's a rough budget for common stacks:
- 1 GB: bare Linux, static web server (nginx), maybe a tiny Node app. WordPress will swap and crawl.
- 2 GB: minimal WordPress with caching plugins, lightweight databases, small Python/Node APIs.
- 4 GB: comfortable for WordPress with Redis or Memcached, multiple PHP-FPM pools, MySQL handling moderate queries.
- 8 GB: busy WordPress multisites, Magento, Drupal, or any app needing large in-memory datasets. Room for Elasticsearch or background job queues.
- 16 GB+: high-traffic e-commerce, dedicated database servers, analytics stacks, or running a dozen containerized services.
Add overhead for your OS and monitoring agents—usually five hundred megabytes. MySQL or MariaDB can eat gigabytes if you tune InnoDB buffer pools aggressively. Redis or Memcached sit in RAM by design.
If your app touches a database per request and you're not caching query results, you need extra RAM for the database layer or you'll bottleneck there instead.
Bandwidth: transfer caps and burst speeds
Most VPS plans advertise "unmetered" bandwidth on a gigabit port, but they still shape or throttle after you cross a threshold. Read the fine print.
Estimate monthly transfer:
- Average page weight (HTML, CSS, JS, images before CDN).
- Monthly page views.
- Multiply, then add API responses, media uploads, backup transfers.
A WordPress site with two-megabyte pages and one hundred thousand monthly views burns roughly two hundred gigabytes. If you serve video or large PDFs directly, that number explodes.
CDN offloading changes the math. Cloudflare or BunnyCDN cache static assets, so your VPS only serves dynamic HTML and API calls. That can cut origin bandwidth by seventy to ninety percent.
Port speed matters for burst traffic. If your site hits the front page of a news aggregator, a hundred-megabit port will queue requests while a gigabit port sails through. Cheap plans sometimes cap ports at ten or one hundred megabits, which is fine until it's not.
Storage: IOPS matter more than gigabytes
Disk space is cheap. Disk speed is not.
SSD is table stakes now, but not all SSDs perform equally. NVMe drives deliver ten times the IOPS of SATA SSDs. If your app writes logs heavily, handles file uploads, or runs a busy database, IOPS is your real limit.
Database servers especially punish slow disks. MySQL doing random reads on spinning rust will bottleneck at a few hundred queries per second. Same workload on NVMe can handle thousands.
For sizing:
- 20-40 GB: small sites, single WordPress install, minimal logs.
- 60-100 GB: multiple sites, moderate databases, a few weeks of logs before rotation.
- 200 GB+: large media libraries, analytics databases, containerized stacks with image layers.
Keep thirty percent free for filesystem overhead and snapshot space. Drives slow down when nearly full.
When to scale vertically vs horizontally
Vertical scaling—jumping to a bigger VPS—is simpler. Horizontal scaling—adding more VPS instances behind a load balancer—costs more upfront but handles growth better.
Stick with vertical scaling when:
- Traffic grows predictably and you can schedule upgrades during maintenance windows.
- Your app isn't designed for clustering (legacy monoliths, stateful sessions without shared storage).
- You're a solo operator without time to manage multi-server setups.
Go horizontal when:
- Traffic spikes unpredictably and you need auto-scaling.
- Downtime for upgrades isn't acceptable.
- You've already maxed vertical tiers or hit diminishing returns (a thirty-two core VPS costs more than four eight-core instances).
Most hosting starts vertical and shifts horizontal as revenue justifies the complexity.
Real workload examples
Let's map specs to actual use cases.
Personal WordPress blog, ten thousand monthly visitors, all posts cached:
- 1-2 CPU cores
- 2 GB RAM
- 25 GB SSD
- 500 GB bandwidth (or unmetered with CDN)
WooCommerce store, five hundred orders per month, twenty thousand visitors:
- 2-4 cores
- 4-6 GB RAM (WooCommerce is memory-hungry)
- 60 GB SSD
- 1 TB bandwidth if you host product images locally, 300 GB with CDN
SaaS app, Node.js + PostgreSQL, five hundred concurrent users, API-heavy:
- 4 cores minimum (consider dedicated CPU)
- 8 GB RAM (split between app and database)
- 80 GB NVMe
- 2 TB bandwidth
WordPress multisite network, fifty sites, shared hosting refugees:
- 6-8 cores
- 16 GB RAM
- 150 GB SSD
- 3 TB bandwidth
Media streaming or large file delivery:
Don't serve this from a VPS. Use object storage and a CDN. Your VPS handles metadata and control plane only.
Red flags in VPS marketing
Watch for these tricks:
- "Unlimited" anything. It's always throttled or terms-of-service limited.
- Suspiciously cheap prices with no CPU spec detail—probably heavily shared cores.
- Bandwidth measured in megabits per second instead of monthly gigabytes (they're hoping you won't do the math).
- Storage listed without mentioning SSD vs HDD.
- Free trials requiring credit cards with auto-renew at the full rate after seven days.
Read the acceptable use policy. Some hosts ban certain apps, restrict outbound email, or count backups against your storage quota.
How to test before committing
Most providers offer hourly billing or monthly plans with pro-rated refunds. Spin up a mid-tier VPS, migrate a copy of your site, and hammer it with a load test.
For synthetic load:
ab -n 10000 -c 100 https://yoursite.test/
That sends ten thousand requests with one hundred concurrent connections. Watch CPU with htop and memory with free -h during the test. If load average climbs above core count or you see swap activity, the tier is too small.
For real traffic, route a percentage through the test VPS using DNS weighting or Cloudflare Workers and monitor for a week.
What about burstable vs dedicated resources?
Burstable plans let you borrow unused CPU from the host when available. Fine for bursty workloads—a blog that's quiet all day then gets hammered for an hour. Terrible for sustained load, because the host will throttle you once burst credits run out.
Dedicated resources cost more but guarantee performance. If uptime and speed matter—production sites, customer-facing apps—pay for dedicated.
Check the provider's definition. "Dedicated" sometimes just means "not oversold as badly," not true core isolation.
Checklist before you buy
Run through this:
- Measured your current CPU load average, RAM usage, disk I/O, and bandwidth over at least a week.
- Calculated headroom—pick a plan with thirty to fifty percent unused capacity for growth and spikes.
- Confirmed SSD or NVMe storage if you run databases or handle uploads.
- Checked whether CPU cores are dedicated or shared.
- Verified bandwidth is truly unmetered or well above your monthly transfer.
- Read refund and upgrade policies—can you scale without migrating?
- Tested the VPS with your actual workload before going live.
Skip the tier that "should be enough." You'll outgrow it in three months and waste migration time.
FAQ
How much RAM does WordPress really need?
A default WordPress install with a simple theme runs in under 512 MB, but plugins add overhead fast. WooCommerce, Yoast, caching plugins, and security scanners each claim memory. Budget 2 GB minimum for a production site, 4 GB if you're running more than a handful of plugins or expect traffic spikes.
Can I run multiple sites on one VPS?
Yes, using virtual hosts in Apache or server blocks in nginx. Just add the RAM and storage each site needs. Five small WordPress sites might share a 4 GB VPS comfortably; five WooCommerce stores won't.
What's the difference between shared CPU and dedicated CPU plans?
Shared CPU plans divide physical cores among multiple VPS instances. Your slice of time varies with your neighbors' load. Dedicated CPU gives you full, isolated cores. Shared is cheaper and fine for bursty workloads; dedicated is necessary when you need consistent performance.
Should I pay extra for managed VPS?
Managed plans handle OS updates, security patches, and basic troubleshooting. Worth it if server admin isn't your job. Unmanaged is cheaper but you're responsible for everything—updates, firewall rules, service restarts, backups.
How do I know when to upgrade tiers?
Watch load average (consistently above your core count), memory usage (above eighty percent with swap active), and disk I/O wait (high %iowait in top). If you're hitting any of those ceilings during normal traffic, upgrade before the next spike.
Start with measurement, not guesses
The right VPS tier matches your actual workload, not a marketing checklist. Measure your resource consumption first, add headroom for growth, then pick the plan that fits both without paying for cores and RAM you'll never touch.
Most mistakes happen when people guess traffic needs or blindly follow "recommended specs" written for different use cases. Your app's behavior—database queries per request, caching strategy, background jobs—drives resource needs more than raw visitor counts.
Test on the tier you think you need. If metrics stay green under load, you nailed it. If not, the next tier up is a click away.