vCPU is the unit every cloud platform prices compute in, and it is the number people compare when they compare accounts. It is also the number most often misread. A vCPU is not a processor, and two instances advertising the same count can differ in real throughput by a factor of several.
What the number describes
A physical server has processors; each processor has cores; on most modern server chips each core presents two hardware threads. A vCPU is, in the overwhelmingly common case, one of those hardware threads, scheduled onto your virtual machine by the host’s hypervisor.
Two consequences follow immediately, and both matter:
- 2 vCPU usually means one physical core. Two threads on one core do not do twice the work of one thread; on typical server workloads the second thread adds somewhere in the region of 20-30 %, not 100 %.
- The vCPU is a scheduling entitlement, not a reservation — unless the plan explicitly says dedicated. On a shared plan, other tenants are scheduled onto the same physical core, and your throughput varies with what they are doing.
Shared, burstable, dedicated
Three plan families exist across essentially every provider, under different names:
- Shared. Cheapest. You get a fair share of a core that other tenants also use. Excellent for anything that is idle most of the time — staging, small sites, build agents, cron jobs.
- Burstable. A baseline percentage of a core plus a credit balance you accumulate while idle and spend while busy. Superb for spiky low-average workloads, and genuinely dangerous for sustained ones: when the credits run out, performance drops to the baseline, which may be a fraction of what you benchmarked on day one.
- Dedicated. The core is yours. Predictable, and the right choice for anything where consistent latency is part of the product — databases, real-time APIs, video encoding, CI that people wait on.
Most “the server got slow and nothing changed” reports are burstable credit exhaustion. If throughput is stable for days and then degrades and stays degraded, that is the first thing to check.
Why the same count performs differently
Beyond the plan family, three things move real performance at a fixed vCPU count:
- The underlying chip generation. A vCPU on a current-generation instance can be meaningfully faster than one on hardware from several years earlier — same number, different machine.
- Memory per vCPU. Compute-optimised, general-purpose and memory-optimised families differ mostly in this ratio, and for most real applications memory pressure limits throughput long before the CPU does.
- Storage and network. Both are frequently tied to instance size. Choosing a bigger instance often buys IOPS and bandwidth you needed rather than CPU you did not — which is the whole premise behind storage-differentiated providers like UpCloud.
On this site, vCPU means account quota
An important distinction. On a product page here, a figure like “32 vCPU” describes the quota the account can run up to across the instances you launch — not a single machine you are handed. Higher-quota accounts exist because providers limit new accounts by default and raising a limit takes time you may not have.
So read it as headroom, not as a machine spec. If you plan to run a dozen small instances, a high quota matters. If you plan to run one, it does not.
Sizing without guessing
A method that works better than picking a number:
- Start smaller than you think. Scaling up is a reboot; over-provisioning from day one is a bill you keep paying.
- Measure for a week under real traffic. Watch CPU steal time (contention on shared plans), memory pressure and disk wait — not just CPU utilisation.
- Resize against what you measured. Utilisation sitting under 20 % at peak is money going nowhere.
- Only then buy headroom, and buy it where the measurement pointed — often memory or IOPS rather than vCPU.
Every product page in the catalog lists the vCPU figure for each configuration, so you can size against a number rather than a marketing tier. If two options are close, put them side by side.