Most VPS spec sheets list a dozen numbers, but only four determine whether your server will handle your workload or fall over under load. I've watched people overpay for eight CPU cores they never touch while their site crawls because disk I/O can't keep up with database writes. The reverse happens too—underspec'd RAM means constant swapping and a server that feels sluggish even when CPU sits idle.
This guide walks through the four specs that actually drive performance: CPU cores, RAM, disk I/O, and network bandwidth. You'll learn how each one maps to real workloads—WordPress sites, API servers, databases, static file hosting—and how to size them without guessing.
CPU cores: how many parallel requests can you handle
CPU cores determine how many operations your server can execute simultaneously. Each core handles one thread of work at a time. More cores let you process more requests in parallel, but only if your application is designed to use them.
A single-core VPS runs one PHP request, one database query, or one background job at a time. Queue up ten simultaneous visitors and nine wait. Two cores let you handle two requests at once. Four cores handle four. The math is linear until you hit other bottlenecks like RAM or disk.
PHP-FPM, Node.js clusters, and Gunicorn workers all spawn multiple processes to use extra cores. A default WordPress install with five concurrent visitors benefits from two cores; twenty concurrent users need four or more. Static site generators and build tools (webpack, npm) parallelize file operations across cores, so builds finish faster on multi-core VPS.
Database servers use cores differently. MySQL dedicates threads to each connection and background task (replication, flushing buffers, query cache maintenance). A single-core database server under moderate load spends time context-switching between threads, which slows everything down. Two cores handle most small sites; four cores support dozens of simultaneous queries.
When you need more cores
You need additional cores when:
- CPU usage stays above 70% during normal traffic (not just spikes)
- Application response time increases during peak hours even though RAM and disk are fine
- You run background jobs (cron scripts, queue workers) alongside web traffic
- You compile code, process images, or run build tools on the same server that handles requests
Check current usage with top or htop. If all cores sit near 100% while your site feels slow, add cores. If one core maxes out while others idle, your application isn't parallelizing work—adding cores won't help.
RAM: what happens when you run out
RAM holds everything your server needs right now: active processes, database buffers, file system cache, application code. When you run out, Linux moves the least-used data to swap (disk storage used as slow RAM). Swapping kills performance because disk is hundreds of times slower than RAM.
Every service you run consumes RAM. Apache prefork mode spawns one process per connection; each process uses 20-50 MB depending on loaded modules. Twenty concurrent connections need 400 MB to 1 GB just for Apache. Nginx uses far less (a few MB per worker), but your application still needs memory.
PHP-FPM pools, Python WSGI workers, and Node.js processes each claim their own memory. A typical PHP-FPM worker uses 30-80 MB. Run ten workers and you've allocated 300-800 MB before counting the database.
MySQL and PostgreSQL cache query results and table indexes in RAM. The buffer pool (InnoDB) or shared buffers (Postgres) should be large enough to hold your most-accessed data. A 2 GB database benefits from at least 512 MB of buffer pool; 1 GB is better. Give the OS another 500 MB for file system cache and you need 2 GB total RAM minimum.
Redis and Memcached store everything in RAM by design. If your cache holds 1 GB of session data, you need 1 GB of RAM just for that service.
Sizing RAM for common workloads
Here's what I see in support tickets:
- Small WordPress site (< 10k visits/month): 1 GB, but 2 GB avoids swapping under traffic spikes
- WooCommerce or membership site: 2-4 GB because plugins and sessions consume more memory
- Laravel or Django app: 2-4 GB depending on worker count and whether you run Redis/Postgres on the same VPS
- Dedicated database server: 4-8 GB lets you cache indexes and query results; less than that and queries hit disk constantly
- Multiple sites on one VPS: add 500 MB per site as a rough estimate, then test
Run free -h to check current usage. If "available" memory drops below 200 MB during normal load, you're too close to swapping. Add RAM.
Disk I/O: the silent performance killer
Disk I/O measures how fast your server reads and writes data. It's not about storage capacity (500 GB vs 1 TB)—it's about how many read/write operations per second the disk can handle and how quickly data transfers.
Two technologies dominate: SSD and NVMe. Traditional spinning drives (HDD) are too slow for production VPS; I won't cover them here. SSD delivers 500-3000 IOPS (input/output operations per second) and 200-550 MB/s transfer speeds. NVMe delivers 10,000-50,000 IOPS and 1,500-3,500 MB/s transfers. The difference matters for database-heavy workloads.
Databases write constantly: query logs, transaction logs, index updates, table data. Every INSERT, UPDATE, or DELETE hits disk. High-traffic WordPress sites write to wp_options and session tables hundreds of times per minute. E-commerce checkouts write order data, inventory updates, and payment logs in rapid bursts.
If disk can't keep up, queries queue. Users see slow page loads even when CPU and RAM look fine. In support tickets I handled, the usual culprit was a full disk or a shared SSD oversold to too many VPS tenants.
How to tell if disk I/O is your bottleneck
Run iostat -x 1 (install with apt install sysstat or yum install sysstat). Watch the %util column. If it stays above 80% during normal traffic, disk is saturated. Check await (average wait time in milliseconds)—anything over 10ms on SSD or 5ms on NVMe signals a problem.
MySQL slow query logs often reveal I/O issues. Queries that should take milliseconds suddenly take seconds. Check your database's buffer pool hit ratio; if it's below 95%, queries are hitting disk too often because the buffer is too small or the disk is too slow.
When NVMe matters
You need NVMe if:
- You run a busy database server (hundreds of writes per second)
- You host multiple WordPress or Magento sites on one VPS
- You process large files (image uploads, video transcoding, log parsing)
- You run Elasticsearch or another search engine that indexes documents continuously
For a static site or a low-traffic blog, SSD is fine. The price difference isn't worth it. For a high-transaction e-commerce site or a SaaS API backend, NVMe pays for itself in reduced response time.
Network bandwidth: are you moving enough data
Bandwidth measures how much data your VPS can transfer in and out per month (the cap) and how fast it can push that data (the rate). Exceeding your cap means overage fees or throttling. A slow transfer rate causes users to wait for pages, images, or downloads even when your server is fast.
Most VPS plans include 1-5 TB of monthly transfer and 100 Mbps to 1 Gbps transfer rates. A 100 Mbps connection moves 12.5 MB per second; 1 Gbps moves 125 MB per second. For context, a typical WordPress page with images is 2-4 MB. Serving that page to one user at 100 Mbps takes a fraction of a second; serving it to 50 simultaneous users at 1 Gbps still feels instant.
Estimating your bandwidth needs
Calculate monthly transfer like this: average page size × pages per visitor × monthly visitors. A blog with 3 MB pages, 3 pages per session, and 20,000 monthly visitors uses roughly 180 GB per month. A video streaming site or software download portal uses far more.
If you serve large files (PDFs, software binaries, videos), put them behind a CDN (Cloudflare, BunnyCDN). The CDN caches files at edge locations, so your VPS only serves each file once. Traffic to your VPS drops by 70-90%, and your bandwidth cap becomes a non-issue.
Transfer rate vs monthly cap
Transfer rate (Mbps or Gbps) affects user experience during high-traffic bursts. If 100 users hit your site simultaneously, a 100 Mbps connection might bottleneck. A 1 Gbps connection handles the burst without slowing down.
Monthly cap affects cost and uptime. If your site gets featured on Hacker News and suddenly serves 10 TB of traffic, you'll hit the cap and face throttling or overage fees. CDNs and image optimization (WebP, lazy loading) reduce transfer volume and keep you under the cap.
Matching specs to workload type
Different workloads stress different resources. Here's how to allocate your VPS budget:
Static sites and JAMstack apps (Gatsby, Hugo, Next.js static export): Low CPU, low RAM, low I/O. A 1-core, 1 GB, SSD VPS handles tens of thousands of visitors if you use a CDN. Network bandwidth matters more than anything else.
WordPress or traditional CMS: Moderate CPU (2 cores), 2-4 GB RAM, good disk I/O (NVMe preferred). Database writes happen on every page load with dynamic content. Caching plugins (WP Super Cache, Redis) reduce I/O load but you still need fast disk.
API backends (Node, Django, Flask, Rails): Moderate to high CPU (2-4 cores), 2-4 GB RAM, moderate I/O. If your API is read-heavy, add Redis and disk I/O matters less. If it writes logs or handles file uploads, NVMe helps.
Database servers (dedicated MySQL, PostgreSQL): High RAM (4-8 GB minimum), NVMe, moderate CPU (2-4 cores). The buffer pool or shared buffers should fit your active dataset. If queries hit disk frequently, performance collapses.
Background job processors (Sidekiq, Celery, Laravel Queue): High CPU (4+ cores), moderate RAM, low I/O unless jobs write files. Each worker consumes a core, so scale cores with queue depth.
E-commerce platforms (WooCommerce, Magento): High everything. Plan for 4 cores, 4-8 GB RAM, NVMe, and 1 Gbps bandwidth. Checkout flows write session data, inventory updates, and payment logs in real time. Traffic spikes during sales crush underpowered VPS.
What to check first
Start by measuring your current resource usage. Don't guess. Run these commands on your existing server:
toporhtop— check CPU usage per core and overall memory consumptionfree -h— see how much RAM is available and how much is in swapiostat -x 1— measure disk I/O wait times and utilization percentagevnstator your provider's bandwidth dashboard — review actual monthly transfer
If you're launching a new project, provision conservatively (2 cores, 2 GB RAM, SSD, 1 TB bandwidth) and scale up after the first week based on real metrics. Providers let you upgrade mid-month; downgrading is harder.
Watch your server during peak traffic hours. If CPU maxes out, add cores. If RAM fills and swap kicks in, add memory. If iostat shows high wait times, upgrade to NVMe or move the database to a separate VPS. If pages load slowly only for distant users, the issue is network latency—use a CDN, not a bigger VPS.
The goal is to pay for what you use, not what sounds impressive on a spec sheet. A well-tuned 2-core VPS with NVMe outperforms a bloated 8-core VPS with slow SSD and misconfigured services.
FAQ
Can I start with 1 GB RAM and upgrade later?
Yes, most providers let you scale RAM and CPU with a reboot. Test your workload on a smaller plan first, then upgrade based on actual usage.
Do I need a managed VPS or can I handle this myself?
If you're comfortable with SSH, package managers, and basic Linux admin, unmanaged is cheaper. Managed plans cost 2-3x more but include security patches, monitoring, and support.
What if my site is slow but all four specs look fine?
Check application-level issues: unoptimized database queries, missing indexes, large images without compression, or external API calls that block page rendering. Server specs aren't always the bottleneck.
Should I split services across multiple VPS?
If your database uses more than half your RAM, move it to a dedicated VPS with high RAM and NVMe. Separating web and database servers improves performance and lets you scale each independently.
How do I know if my provider is overselling resources?
Run I/O benchmarks (dd, fio) and compare results to the provider's advertised speeds. Check if CPU steal time (st in top) stays above 5%—that means the hypervisor is starving your VPS of CPU cycles.