How much CPU and RAM does a VPS need?

Practical starting configurations

These are starting points, not traffic guarantees. Application design, data size, processor generation and provider allocation can change requirements substantially.

Interpret virtual CPU correctly

vCPU count shows available processing threads, not model or guaranteed speed. Two modern cores can outperform four older ones. Websites often value single-core performance; queues and builds can use more parallelism. Sustained CPU above 70–80% alongside rising response time is a signal to investigate, not an automatic instruction to buy cores.

Find an expensive process or query first. More cores help only when the workload can run in parallel and the provider allows the required sustained use.

Allow memory for every component

Application, database, cache, control panel and OS all share RAM. Add peak use rather than averages and keep 20–30% available under normal load. Active swap and out-of-memory kills indicate pressure; swap can soften a short peak but is much slower than RAM.

• 1 GB: only a lightweight service without a heavy panel
• 2 GB: practical minimum for a small site or bot
• 4–8 GB: applications with a database or several services
• 8+ GB: busy databases, builds and specialised workloads

Storage and network can be the bottleneck

If CPU is idle while requests are slow, inspect storage latency, database queries and network calls. NVMe often matters more than extra capacity for small random operations, but the label alone is not a performance guarantee. The NVMe vs SSD guide explains what to test.

Metrics to collect

• Average and peak CPU, process queue and throttling
• Available RAM, swap activity and OOM events
• Free disk, I/O latency and queue depth
• Application response time and error rate
• Database connections, slow queries and cache behaviour
• Transfer rate, packet loss and current port use

Collect at least a week including peak hours, updates and backups. Daily averages hide a short bottleneck that affects users every morning. Keep history to compare releases and seasonal changes.

Scale the constrained resource

1. Correlate CPU, RAM, storage and response time with the incident.
2. Fix an obvious query, leak or broken retry loop.
3. Increase only the limiting resource.
4. Run the same measurement again.

Vertical scaling is simplest for a small service. Horizontal scaling adds instances but also load balancing, shared state and operational complexity. Before purchase, confirm whether CPU and RAM can grow without changing IP, how long a restart takes and whether the disk can ever shrink.

Common sizing mistakes

Do not copy requirements from another stack without measuring: changing a database, runtime or container layout changes the profile. Do not add daily averages and ignore peaks caused by backups, updates or scheduled jobs. Finally, do not treat a larger plan as the only fix; a missing database index, unbounded retry loop or memory leak will eventually consume the new capacity too.

When several components share one VPS, add their peak memory plus operating-system headroom, but validate the result under realistic concurrency. Component limits are useful safety rails; they are not a substitute for system-wide monitoring.

Frequently asked questions

More cores or higher clock speed?

Single-threaded workloads favour fast cores; parallel workers can use more cores. Profile the real application.

Can swap replace RAM?

No. It may survive a short peak, but persistent swap activity calls for optimisation or more memory.

How much headroom is sensible?

Often 20–30% memory and CPU below sustained saturation, adjusted for peak size, upgrade speed and acceptable downtime.