Two virtual servers can both advertise four vCPUs and 8 GB of RAM, yet behave differently under load. The difference can come from how the provider allocates CPU time—and whether your workload needs short bursts of processing or sustained access.
When comparing VPS plans, the number of vCPUs is only part of the specification. You also need to understand whether CPU resources are shared, what access the provider guarantees, and whether your application needs that guarantee.
What is a vCPU?
A vCPU is a processor unit presented to a virtual machine. It is not a universal measure of computing power.
Providers define how virtual CPUs map to physical hardware. For example, Hetzner states that one vCPU corresponds to one thread of a physical CPU core. That does not make a thread equivalent to an entire physical core, nor does it make vCPUs on different processor generations equally fast. See Hetzner’s server FAQ.
When comparing plans, check both the CPU allocation model and the underlying hardware information the provider makes available.
Shared vCPU: suitable for intermittent demand
On a shared CPU plan, processing resources are shared with other virtual machines. Your server can have enough capacity for short bursts while offering less predictable performance when demand remains high.
DigitalOcean positions its shared CPU plans for workloads that do not consistently need full CPU access. Its dedicated CPU plans provide guaranteed access to the allocated CPU hyperthreads. These are provider-specific definitions, so check the equivalent terms wherever you buy hosting. See DigitalOcean’s CPU plan guide.
A shared plan is worth testing for:
- A small website with effective page caching.
- A development or staging environment.
- An internal tool used intermittently.
- A scheduled task whose completion time is flexible.
The deciding factor is the workload’s behavior. A small application can still be CPU-intensive, while a popular cached website may spend relatively little time executing application code.
Dedicated vCPU: predictable access for sustained work
A dedicated CPU allocation is useful when an application needs processing capacity consistently, or when variation in processing time creates operational problems.
Potential candidates include build workers, sustained data processing, busy application backends, and other services that repeatedly keep their CPUs occupied.
Dedicated vCPU does not necessarily mean dedicated physical hardware for the entire server. Hetzner, for example, describes its dedicated-resource instances as having dedicated CPU resources. Read the plan specification separately for storage, networking, and other limits. See Hetzner’s cloud overview.
Predictable CPU access also does not guarantee a fast application. A slow database query, insufficient memory, or a delayed external API can remain the limiting factor.
Which option fits your workload?
| Workload pattern | Starting point | What to verify |
|---|---|---|
| Occasional requests with long idle periods | Shared vCPU | Response times during expected bursts |
| Development or staging | Shared vCPU | Whether slower builds affect the team |
| Continuous CPU processing | Dedicated vCPU | Sustained throughput and completion time |
| Strict response-time target | Compare both under realistic load | Slowest requests, errors, and consistency |
| Waiting mainly on disk or external APIs | Investigate the bottleneck first | Whether CPU allocation changes the result |
These are starting points for testing, rather than guarantees about a particular server size.
Why average CPU usage is not enough
An average can hide the periods that matter most. A server may look lightly loaded over an hour while experiencing short intervals in which requests queue up.
Conversely, a batch worker may use substantial CPU without causing a problem because it completes within its required window.
Measure the outcome that matters to the application:
- Website: response times and failed requests.
- Worker: jobs completed and queue growth.
- Build server: build duration.
- Scheduled process: completion before its deadline.
Test before paying for an upgrade
Use a representative workload to compare plans. Keep the application version, dataset, caching configuration, and test conditions as consistent as possible.
- Define your target. Choose an acceptable response time, job completion window, or processing rate.
- Test ordinary and busy periods. Include the busiest conditions you reasonably expect.
- Repeat the comparison. A single short benchmark cannot establish how reliably a plan will handle production demand.
- Record application results alongside resource usage. Track errors, latency, throughput, or queue growth as appropriate.
- Account for other hardware differences. Changes in processor generation, memory, or storage affect the comparison.
If a dedicated CPU plan improves processing time but leaves user-facing response times unchanged, CPU access may not be the main constraint.
When the hardware differs between plans, your test compares the complete offerings rather than isolating CPU allocation alone. That can still answer the practical question: which plan meets your requirements?
When should you upgrade?
Consider moving to dedicated vCPU when repeated tests show that CPU-related limits prevent your application from meeting its target.
Examples include a processing queue that grows during sustained demand, builds that consistently miss a required completion window, or response times that improve meaningfully on a dedicated CPU plan under equivalent conditions.
Before upgrading, check whether the application is doing avoidable work. Repeated database queries, missing caches, and unnecessarily expensive background tasks can consume capacity on either plan.
The right choice is the plan that meets your workload’s performance target consistently at an acceptable total cost. Start with measurable requirements, test realistic demand, and let the results determine whether dedicated CPU access is worth paying for.
