Understanding VPS Specs: vCPU, RAM, NVMe, and What Actually Matters

Why This Guide Exists

VPS providers love to throw numbers at you. "4 vCPU," "8GB RAM," "NVMe storage," "1Gbps network." These specs mean something specific, and understanding them prevents two common mistakes: paying for resources you don't need, or skimping on resources that will cause problems.

This guide explains each spec, how it translates to real-world performance, and how to size a VPS for different workloads.

vCPU: What It Actually Means

A "vCPU" (virtual CPU) is not the same as a physical CPU core. It's a slice of a physical CPU, allocated to your virtual machine.

How Virtualisation Works

A physical server might have two AMD EPYC 9654 processors, each with 96 physical cores (192 threads). That server runs 50 VPS instances. Each VPS gets a portion of those cores — typically 1-4 vCPU per instance.

The allocation model matters:

Most budget VPS (sub-$10/month) use shared vCPU. Premium VPS (>$20/month) typically offer dedicated or prioritised CPU allocation.

What vCPU Count Means for Your Workload

The catch: More vCPU doesn't mean faster. A single-threaded task uses one core. If your application isn't parallelised, 8 vCPU provides no benefit over 2. Apache, PHP-FPM, and Node.js applications often run single-threaded per request.

RAM: The Most Important Spec

RAM is typically the bottleneck for web applications. More RAM means:

• More requests served simultaneously without swapping
• Larger database query caches (MySQL/PostgreSQL)
• More application objects held in memory (WordPress object cache, etc.)
• Fewer disk reads (which are orders of magnitude slower than RAM reads)

How Much RAM Do You Actually Need?

The Swap Problem

When a VPS runs out of RAM, it starts using disk space as "swap." This is called "swapping" and it's catastrophically slow — disk I/O is 100-1000x slower than RAM.

# Check if your VPS is swapping
free -h
# If the "Swap" row shows used space > 0, you're swapping

Never let a production system swap. It will feel slow and unresponsive, and the disk thrashing can cause crashes. If you're consistently above 80% RAM utilisation, upgrade.

Storage: NVMe vs SSD vs SATA

Storage technology has a massive impact on perceived performance.

The Hierarchy

NVMe (Non-Volatile Memory Express) is a protocol designed for flash storage that minimises latency. A "good" NVMe drive in a VPS reaches 1,000-3,000 MB/s. Enterprise-grade NVMe (Intel Optane, Samsung PM9A1) reaches 7,000 MB/s.

Real-World Impact

For a typical web server, disk I/O matters most for:

1. Database queries — Reading from disk vs RAM cache is the difference between 1ms and 100ms query times 2. File operations — Upload handling, log writing, caching 3. Application startup — PHP opcode cache loading, framework initialisation

# Measure your disk read speed
dd if=/dev/zero of=/tmp/test bs=1M count=1024 oflag=direct
# Result in MB/s tells you what you're working with
# More thorough test with fio (if available)
fio --name=seq-read --filename=/tmp/test --ioengine=libaio --rw=read --bs=1m --size=1G --runtime=30

Storage Size

Modern SSD/NVMe storage is cheap enough that "running out of disk" is usually a management problem, not a capacity problem. Budget 10-20GB for the OS and base packages, then add:

• WordPress (with media): 5-50GB depending on content
• Database: 1-10GB for most applications
• Logs: 1-5GB (rotate these, don't let them grow indefinitely)
• Backups: Plan for 2x your data size for staging/restoration space

A 40GB NVMe partition handles most small-to-medium web applications comfortably.

Network: Speed and Bandwidth

Network Speed vs Bandwidth

These are different things:

• Speed (throughput) — How fast data moves in a single connection, measured in Mbps or Gbps. "1Gbps" means the pipe is 1 gigabit per second.
• Bandwidth (data transfer) — How much total data you can move per month, measured in TB. "2TB bandwidth" means 2 terabytes of outbound transfer included.

What Network Speed Means

A 100Mbps network vs 1Gbps network matters for:

For most web applications serving standard pages (under 1MB per request), network speed rarely saturates. For file hosting, video streaming, or large API responses, it matters significantly.

Bandwidth Limits

Most VPS plans include a monthly bandwidth allowance. Exceeding it incurs overage charges (typically $0.50-2/GB).

Use a CDN to reduce origin bandwidth consumption by 80-95% for cacheable content.

Reading the Marketing

Here's how to decode common marketing claims:

"Unlimited Bandwidth"

There is no such thing as unlimited bandwidth. Hosts offering "unlimited" either:

• Have a fair use policy they'll enforce when you use too much
• Throttle your speed significantly after a threshold
• Are losing money and will raise prices or shut down

Always check the actual included bandwidth and overage rates.

"Blazing Fast NVMe"

NVMe is faster than SSD, but "NVMe" doesn't tell you which drive or what performance ceiling. Ask for or test the actual throughput.

"100% CPU Allocation"

Marketing. Without dedicated resources, "100% of your allocated CPU" might mean "100% of a shared core that you're sharing with 10 other VMs." Test under load to see actual performance.

"Enterprise Grade Hardware"

Meaningless. Get the specific specs: CPU model, generation, RAM type, SSD/NVMe model. Then you can compare meaningfully.

How to Size Your First VPS

A practical framework:

Step 1: Estimate your concurrent users

• If you don't know, assume 10% of your monthly unique visitors are concurrent at peak

Step 2: Estimate RAM per user

• Static HTML: ~10MB per user
• WordPress (no caching): ~50-100MB per user
• WordPress (with object cache): ~20-30MB per user
• API/Web app: ~10-50MB per user

Step 3: Calculate minimum RAM

• Concurrent users × RAM per user = minimum RAM needed
• Add 50% headroom for spikes

Step 4: Pick vCPU

• If your application can parallelise (Node.js, Go, async Python): 2-4 vCPU
• If your application is single-threaded (PHP without Swoole): 2 vCPU is usually enough
• More vCPU rarely hurts but is wasted if your app can't use it

Step 5: Test and iterate

• Start with modest specs
• Monitor actual utilisation with htop, free -h, iostat
• Upgrade when consistently above 80% on any resource

The Specs That Matter for Common Workloads

Bottom Line

• RAM is usually the bottleneck — monitor it first
• NVMe vs SSD matters for I/O-heavy apps — database, file processing
• vCPU count doesn't equal speed — unless your app parallelises
• Network speed matters for large files — CDN covers most web app needs
• Test under real load — specs don't tell the whole story
• Start small, monitor, upgrade — cheaper to add resources than overbuy