VPSTabEvidence-first VPS decisions
Search2026.10.25-v7
Menu
Find a VPSProvidersPlansReviewsCompareUse casesGuidesMethodology
English
English简体中文日本語한국어DeutschFrançaisРусский
Guides

vCPU, CPU architecture and virtualization: what the numbers mean

Understand shared versus dedicated vCPUs, KVM versus container virtualization, x86 versus arm64, and why a plan's CPU line is often the least comparable number on the page.

Last reviewedOct 24, 2026 · 1021 words

A vCPU is a scheduling promise, not a core

Cloud plans describe CPU in vCPUs, and a vCPU is a unit of scheduling rather than a physical core. On a shared plan, the provider gives your instance a slice of a physical core's time; the host may oversubscribe, and your throughput depends on what neighbours do. On a dedicated plan, the provider promises a core or a thread that is not shared with another customer. Two plans with '2 vCPU' can therefore have very different sustained performance, and price per vCPU is only meaningful after you know which kind you are buying.

This catalog records vCPU counts from provider sources and, where the provider publishes it, the distinction between shared and dedicated families. Hetzner's CPX line is explicitly shared AMD, for example, while its CCX line is dedicated. A recommendation that weights CPU must not treat a shared 2 vCPU plan and a dedicated 2 vCPU plan as equivalent; the plan family and the provider's wording matter.

KVM versus container virtualization

KVM is full virtualization: each VPS runs its own kernel, which means you can load modules, run Docker, and configure networking as on a physical machine. Container-based virtualization shares the host kernel, which is cheaper but constrains what you can run and how you isolate workloads. Most plans in this dataset are KVM, and the ones that document it say so; where a provider does not state the virtualization type, VPSTab leaves the field unknown rather than guessing.

Why it matters for a buyer: a container VPS may not support custom kernels, certain VPN protocols, or nested virtualization, and a kernel panic can affect the host. If your workload depends on kernel features or on running other operating systems, verify KVM explicitly before buying. The virtualization field in a plan page is a verification status, not decoration.

x86 versus arm64

Almost every cheap VPS is x86-64, but arm64 instances now appear at competitive prices. Scaleway's BASIC2 line in this dataset is Ampere arm64, which is a different instruction set: binaries built for x86 will not run, containers must use multi-arch images, and some commercial software has no arm64 build. In exchange, arm64 plans often provide more cores per euro for workloads that compile from source or run modern language runtimes.

Check three things before choosing arm64: does your software ship arm64 binaries or build cleanly, do your container images publish arm64 variants, and does your deployment tooling assume x86. If any answer is no, an x86 plan at a slightly higher price is the cheaper decision. VPSTab records the architecture when the provider states it; a plan whose architecture is unknown is not a safe arm64 bet. Also confirm that the provider's rescue images, monitoring agents and backup tooling support the architecture, because a host that boots fine can still leave you without a recovery path.

Frequency, burst and steal

Providers rarely guarantee a clock speed, and 'up to' figures describe burst behaviour rather than sustained performance. Shared plans often allow short bursts above the baseline, which helps interactive workloads and hides little for long compilations. If your workload is CPU-bound for minutes at a time, sustained allocation matters more than the peak number on the marketing page.

CPU steal is the time your virtual CPU waits while the host serves other tenants. It is the practical signal of noisy neighbours, and no pricing page reports it. The only honest approach is to measure on the plan you actually buy: run your own workload for a representative period and record the results with the date and configuration. This dataset does not publish independent CPU measurements, so its reviews do not claim performance scores.

Sizing for real workloads

For a small web service, one shared vCPU with enough memory is usually fine; the bottleneck is more often RAM or disk latency than raw CPU. For a CI runner, compilation is bursty and parallel, so four to eight vCPUs with fast NVMe storage matter more than a high clock. For a game server, single-thread performance and network latency dominate, and a dedicated or high-frequency plan is often worth the premium. For a Docker host running several services, count the memory each container needs and add headroom; the vCPU line is the least reliable predictor.

Use the scenario profiles in VPSTab as a starting point, then adjust for your own measurements. A recommendation based on specs is a hypothesis about fit; it becomes a decision only after the workload runs on the actual plan.

What the catalog can and cannot tell you

The catalog records vCPU counts, plan family, architecture where stated, and virtualization where stated. It does not contain independent CPU benchmarks, and it should not: a synthetic score from a different plan, region or time is not evidence for the plan you are buying. Reviews in this dataset withhold overall performance scores when no independent measurement exists, and the recommendation engine applies an explicit uncertainty penalty instead of inventing a number.

That is a deliberate product decision. If you need a performance guarantee, buy a short trial on the candidate plan, run your workload, and compare the results. The catalog helps you narrow the shortlist and avoid impossible combinations; it does not replace the measurement.

Keep the measurement honest when you compare: record the plan, region, image, kernel and load pattern, and run the same workload on every candidate for the same duration. A short benchmark that only measures startup feels reassuring and predicts very little about sustained compilation, database writes or concurrent connections. If you cannot test before buying, choose the plan whose family and provider documentation make the weakest claim you actually depend on, and budget for a resize after the first week of real traffic.

Verification checklist

  • Check whether the plan is shared or dedicated, not only the vCPU count.
  • Verify KVM if you need custom kernels, VPNs or nested virtualization.
  • Confirm your software and container images support arm64 before choosing it.
  • Prefer sustained allocation over burst figures for long CPU work.
  • Measure your own workload on the candidate plan before committing.
  • Treat missing architecture or virtualization data as unknown.

Sources