How Many vCPUs Does My App Actually Need?

Quick answer
Start from the process model: a single-process app uses roughly one vCPU under load, while a multi-worker app can use one per worker.
A small web app with light traffic usually runs comfortably on one or two vCPUs; the database and memory are more often the constraint.
Use CPU utilisation, load average, and p95 latency under realistic load to decide, rather than a fixed rule.
Leave headroom for deploys, traffic spikes, and background jobs; running at 90 percent CPU continuously makes latency unpredictable.
Scale vertically first for simplicity, and move to multiple instances when a single machine’s memory or availability becomes the limit.

How do you estimate vCPU needs?

Count the processes that will actually run concurrently. A Node.js app with one process is effectively single-threaded for JavaScript execution, so one vCPU handles it. A Python app with four Gunicorn workers can use four. A Java service with a thread pool may use several, and a Postgres instance benefits from additional cores for parallel queries and background work.

Then measure. Generate realistic load against a staging instance, record CPU utilisation and p95 latency, and find the point where latency starts to climb. That knee is the capacity limit for your workload, and it is usually lower than the raw vCPU count suggests because of garbage collection, locking, or I/O waits.

# What is actually running, and how much CPU is it using?
nproc
ps -eo pid,comm,%cpu --sort=-%cpu | head
uptime                       # load average vs vCPU count
vmstat 1 5                   # r = runnable, wa = waiting on I/O
pidstat -u 1 5               # per-process CPU over time

What does a realistic starting point look like?

For a small web app with a separate managed database, one or two vCPUs and 1-2 GB of RAM is a common starting point. For an app and database on the same box, two to four vCPUs and 4 GB is more realistic, because the database needs memory for caching and some CPU for background work.

For a container platform running several services, size by the sum of requests plus headroom, not by peak usage. Kubernetes requests are the scheduler’s promise, and limits are the ceiling. A node that is 90 percent requested has little room to reschedule a pod during a rollout.

Which signals tell you to add or remove a vCPU?

Add capacity when p95 latency rises with load while CPU utilisation is saturated, when the run queue is consistently longer than the vCPU count, or when steal time is significant on a shared host. Remove capacity when utilisation stays below roughly 20 percent for weeks and memory is not the constraint.

Do not add vCPUs to fix a problem that is not CPU. High load with low CPU utilisation usually means I/O wait or a lock. Rising memory with stable CPU means a leak. A slow query with idle CPU needs an index, not a bigger machine.

When should you scale out instead?

Scale out when a single machine cannot hold the memory, when you need availability across failures, or when traffic is bursty and you want to add capacity temporarily. Scale up when the workload is stateful, single-threaded, or simpler to operate on one machine.

For an AI-built app, vertical scaling is usually the right first move because it requires no application changes. Move to multiple instances when you have a stateless app, sessions outside the process, and a load balancer. The migration is easier before traffic arrives than during an incident.

Where this bites vibecoders
Generated deployment advice often recommends four vCPUs and 8 GB for a small app, which is more than the app needs and hides how little CPU it actually uses. Deploying on two vCPUs, watching real utilisation for a week, and resizing from that data usually costs less and teaches more than picking a bigger plan up front.

Where AI coding assistants get this wrong

Buying four vCPUs for a single-process app that can use one.
Ignoring memory and disk when the bottleneck is not CPU.
Sizing for peak traffic that lasts minutes instead of the steady state.
Running at 90 percent CPU with no headroom for deploys.
Adding vCPUs to fix I/O wait or lock contention.
Sizing a Kubernetes node by peak usage instead of requests plus headroom.

Checklist

Count concurrent worker processes.
Measure CPU and p95 latency under realistic load.
Compare load average to the vCPU count.
Check I/O wait and memory before adding CPU.
Leave 30-50 percent headroom for deploys and spikes.
Revisit the size after two weeks of real traffic.

FAQ

Is 2 vCPU enough for a web app?

For a small app with light traffic and a managed database, usually yes. A single-process app handles requests on one vCPU and uses the second for the OS and background work. If the app spawns multiple workers or runs the database locally, two may be tight under load.

For a prototype, it is convenient and cheap. For anything with real users, separate them: the database needs memory for caching and disk throughput, and sharing means a traffic spike in the app starves the database. Managed databases remove the operational burden at a cost.

How much CPU headroom should I leave?

Enough that a deploy, a traffic spike, or a background job does not saturate the machine. A common target is sustained utilisation below 60-70 percent at peak. The exact number depends on how bursty the workload is and how quickly you can resizing.

Does a bigger vCPU count help a slow database?

Only if the database is CPU-bound and can use parallel workers. Slow queries are usually missing indexes, lock contention, or I/O. Check the query plan and disk latency first; adding cores to a query waiting on disk changes little.