Dedicated vs Shared CPU VPS — When You Need Dedicated Cores in 2026

I learned the difference between shared and dedicated CPU at 3am on a Saturday, watching my client's ecommerce site load in 9 seconds during a flash sale. CPU steal was at 38%. Thirty-eight percent of my "guaranteed" CPU was being taken by other tenants on the same host. The sale was supposed to generate $12,000 in revenue. We got maybe $4,000 before people gave up and left. That was an expensive education in what "2 vCPU" actually means on a shared plan.

The term "shared CPU" appears nowhere in most provider marketing. They say "2 vCPU" and leave you to discover the sharing part when your server slows down during someone else's batch job. This page explains what is actually happening under the hood, when it matters, and when you should pay 2-3x more for dedicated cores. I have been on both sides of this — I run shared CPU for half my servers and dedicated for the rest — and the decision framework is more nuanced than "dedicated is always better."

What Shared vCPU Actually Means

Here is what the spec sheet does not tell you. A physical server has, say, a 32-core AMD EPYC. The provider carves 100+ VPS instances out of that machine, each advertised with 1-4 "vCPUs." Those are not real cores. They are time slices. The KVM hypervisor juggles your workload onto physical cores alongside dozens of other tenants, and when everyone wants CPU at the same time, somebody loses. Usually you.

How CPU Sharing Works

• Overcommit ratio: Providers typically overcommit CPU at 4:1 to 10:1. A 32-core server might host 128-320 vCPUs worth of VPS instances
• Burst capability: When other tenants are idle, you can burst above your allocation. A 2 vCPU shared plan might briefly use 4+ physical cores
• Throttling: When the host is busy, the hypervisor throttles your CPU time. Your "2 vCPU" might only get the equivalent of 0.5-1.0 physical cores
• CPU steal: The %st (steal) value in top shows how much CPU time the hypervisor took away from your VPS to give to other tenants

How Burstable Credits Work

Some providers (notably AWS) use an explicit credit system:

• Your VPS earns CPU credits while idle (below baseline)
• Credits are spent when you burst above baseline
• When credits run out, you are capped at baseline (e.g., 20% of a core)
• Credits refill over time when usage drops

Most VPS providers (Vultr, DigitalOcean, Hetzner) use "soft" sharing — no explicit credit system, you can burst freely, but sustained 100% usage on a shared plan quietly gets you deprioritized. Nobody tells you this is happening. Your site just... gets slower. And then you spend two hours debugging your application before checking top and noticing the steal time.

The Overcommit Spectrum

Not all shared CPU is created equal. The overcommit ratio — how many vCPUs the provider sells per physical core — varies enormously. This single number explains most of the performance differences between providers at the same price point:

Overcommit ratios are estimates based on benchmark variability across time of day. Providers do not disclose exact ratios.

The Noisy Neighbor Problem

This is the part that makes shared CPU feel like a betrayal. Your website is fast at midnight. Beautiful 50ms response times. You go to bed happy. You wake up, and at 2pm it is doing 500ms. Nothing changed on your end. Zero deploys, zero traffic increase. What happened? Your neighbor on the same host kicked off a machine learning training job, or a video transcode, or a database migration. Their CPU usage ate into your time slices. You never met this person. You do not know their name. But their batch job just made your customers wait 10x longer.

Real-World Impact

The worst part is not the performance hit. It is the unpredictability. You cannot capacity-plan around a variable you do not control. Monday your server handles 200 requests per second. Thursday it handles 120. Same code, same traffic. Different neighbors. This is why our benchmarks show different results when we test the same provider at different times — shared CPU is not a fixed resource, it is a lottery ticket.

How Providers Handle Noisy Neighbors

Fair scheduling algorithms (CFS in Linux) try to distribute CPU time evenly, but "evenly" still means sharing. Some providers are better at managing this than others:

• Hetzner and Vultr: Aggressive about rebalancing VMs across hosts. If a host gets too loaded, they migrate VMs automatically. This is why their shared CPU performance is more consistent.
• DigitalOcean: Uses CPU monitoring to identify problematic tenants and contacts them about sustained high usage. Good practice, but reactive rather than preventive.
• Contabo: Prioritizes density over quality. More tenants per host means cheaper pricing but more variability. If consistent performance matters to you, Contabo shared CPU is a gamble.
• RackNerd: Similar to Contabo — the low price reflects the density. Works great for light workloads, unreliable for anything CPU-intensive.

What Dedicated CPU Gives You

Dedicated CPU is the opposite of everything I just described. Specific physical cores are pinned to your instance. Nobody else can touch them. Zero overcommit, zero sharing, zero steal time. Your benchmark score at 3am is the same as your benchmark score during a Black Friday traffic surge on the host. That consistency is what you are paying 2-3x more for — and for certain workloads, it is the best money you will ever spend.

Dedicated CPU Guarantees

• 0% CPU steal: The hypervisor never takes away your CPU time
• Consistent performance: Your benchmark score at 3pm matches your score at 3am
• Sustained workloads: You can run at 100% CPU utilization for hours without throttling
• Predictable capacity: You can accurately plan how many requests/users your server handles
• Better SLA: Providers typically offer stronger SLAs on dedicated CPU plans

When Dedicated CPU Matters

Workloads That Need Dedicated CPU

• Databases (MySQL, PostgreSQL, MongoDB): Query processing is CPU-intensive and sustained. A noisy neighbor causing 20% CPU steal means 20% fewer queries per second
• CI/CD pipelines: Code compilation, testing, and building Docker images are sustained CPU workloads. Shared CPU turns a 5-minute build into a 15-minute build
• Video/audio encoding: FFmpeg transcoding runs at 100% CPU for the duration. On shared CPU, this might get throttled or even suspended by the provider
• Game servers (Minecraft, Valheim): Game tick processing needs consistent CPU timing. Steal time causes lag spikes
• Forex trading bots: Latency matters. CPU steal adds unpredictable delays to order execution
• Machine learning inference: Model serving with consistent response times requires dedicated resources
• Real-time communication: WebRTC, VoIP, and video conferencing servers need consistent CPU for media processing

When Shared CPU Is Fine

• WordPress / static sites: Requests are short bursts. Even with some CPU steal, page loads stay fast
• Low-traffic APIs: Under 100 req/sec, CPU usage is minimal and bursty
• Email servers: Processing email is lightweight and intermittent
• Development/staging: Performance consistency does not matter for testing
• DNS servers: DNS lookups use negligible CPU
• VPN servers: WireGuard uses minimal CPU even with many connections
• Monitoring and logging: Intermittent data processing
• Cron jobs and scheduled tasks: Short bursts that finish quickly and return to idle

The common thread: workloads that use CPU in short bursts with lots of idle time in between. Shared CPU is designed for exactly this pattern. You burst to 100% for 200 milliseconds to serve a web request, then sit at 2% for the next second. That is the ideal shared CPU workload — you use the burst capability when you need it and do not compete for resources during the 98% of the time you are idle.

Benchmark Differences Under Load

We tested shared and dedicated CPU plans from the same provider under different host load conditions. Tests used 2 vCPU / 4GB RAM configurations.

CPU scores are Geekbench 6 single-core approximations. "Busy host" ranges show worst-to-typical performance. See full benchmarks for detailed data.

Read those "busy host" numbers again. A 20-40% performance cliff. That is not a minor fluctuation — that is the difference between a page loading in 1 second and loading in 1.8 seconds, which is the difference between a 2% bounce rate increase and your boss asking what happened. Dedicated CPU stays within 2% of peak. Always. The 2-3x price premium buys you the right to stop worrying about what your neighbors are doing.

Price Comparison: Shared vs Dedicated at Each Provider

The premium is real. Here is what the same 2 vCPU / 4GB RAM costs in shared vs dedicated, and whether I think it is worth it:

2.5x to 3.2x premium. Worth it? Depends entirely on what happens when your CPU gets stolen. If your blog loads in 2 seconds instead of 1.5 seconds, who cares — save the money. If your database starts dropping queries during peak traffic and you lose paying customers, $16/month on Hetzner dedicated cores is the cheapest insurance policy you will ever buy. Contabo and InterServer do not offer dedicated CPU at all — they compete on shared pricing only, which is fine if you understand the tradeoff.

Provider Offerings Breakdown

Providers With Dedicated CPU Options

• Hostinger: "KVM 2" and above offer dedicated CPU. Starting at $18/mo for 2 dedicated cores. Best performance per dollar in our benchmarks
• Hetzner: "Dedicated vCPU" line with AMD EPYC processors. Starting at $16/mo for 2 dedicated cores. EU-based, excellent performance
• Vultr: "Dedicated Cloud" plans with guaranteed CPU. Hourly billing available. Starting at $30/mo for 2 cores
• DigitalOcean: "Dedicated CPU Droplets" starting at $32/mo. Also offers "CPU-Optimized" for compute-heavy workloads
• Linode: "Dedicated CPU" plans starting at $30/mo. Also offers "High Memory" for RAM-intensive workloads
• Kamatera: Flexible config lets you choose dedicated CPU at checkout. Per-core pricing makes it easy to scale

Providers Without Dedicated CPU

• Contabo: All plans are shared CPU but priced aggressively low. Heavy overcommit — expect variable performance (CPU score: 3,200)
• RackNerd: Shared CPU only, very budget pricing (CPU score: 2,800). Good for web hosting, not for sustained workloads
• BuyVM: Shared CPU (score: 3,100) with generous burst allowance. Known for fair resource allocation despite being shared

How to Check if Your CPU Is Being Throttled

Think your shared box is underperforming? Do not guess. Measure. These commands will tell you exactly how much CPU you are actually losing to neighbors:

Check CPU Steal Time

# Show CPU steal in real-time (look at %st column)
top -bn1 | head -5
# Or use vmstat (look at 'st' column)
vmstat 1 10

# Healthy: st = 0-2%
# Concerning: st = 5-10%
# Problem: st > 10% (you're losing significant CPU to neighbors)

Run a Quick CPU Benchmark

# Install sysbench
apt install sysbench -y

# CPU benchmark (single-thread)
sysbench cpu --threads=1 --time=30 run

# CPU benchmark (all threads)
sysbench cpu --threads=$(nproc) --time=30 run

# Compare the "events per second" against expected values
# Run this at different times of day to see variance

Monitor Over Time

# Log CPU steal every minute for 24 hours
while true; do
  echo "$(date): $(vmstat 1 2 | tail -1 | awk '{print $16}')% steal"
  sleep 60
done >> /var/log/cpu-steal.log

# Check average CPU usage over last 15 minutes
uptime

Consistent steal above 5-10%? You have noisy neighbors. Three options, in order of escalation: contact support and ask for a host migration, destroy and recreate your VPS (sometimes this lands you on a quieter host), or upgrade to dedicated CPU and never think about it again. I have done all three. The third one is the only one that permanently solved the problem.

Optimizing Shared CPU Performance

If you are staying on shared CPU — which is the right call for most workloads — there are practical steps to minimize the impact of sharing:

Application-Level Optimizations

• Cache aggressively: Redis or Memcached reduces the number of CPU-intensive operations. A cached page serves in 5ms regardless of steal time. An uncached page hitting PHP and MySQL is where steal hurts
• Use a CDN: Cloudflare (free tier) serves your static assets from edge servers, reducing load on your VPS CPU entirely
• Optimize database queries: A poorly-indexed query that scans 100K rows burns CPU that you cannot afford to lose to steal. Add indexes. Analyze slow queries
• Choose efficient software: Nginx over Apache. PHP 8.3 over PHP 7.4 (40% faster). Static site generators over WordPress where possible

Server-Level Optimizations

• Use OPcache for PHP: Eliminates the CPU cost of recompiling PHP scripts on every request
• Enable HTTP/2: Multiplexed connections reduce connection overhead and CPU usage
• Tune worker processes: Set Nginx workers to match your vCPU count, not higher. More workers on shared CPU increases context-switch overhead
• Offload work: Use external services for heavy processing — image optimization APIs, managed databases, external email delivery (SMTP relay)

Provider-Level Strategies

• Choose low-overcommit providers: Hetzner and Vultr share CPU more conservatively than Contabo and RackNerd. The price is higher but performance is more predictable
• Test at different times: Deploy, run benchmarks at 3am and 3pm. If the numbers differ by more than 20%, the host is oversold
• Recreate to rotate hosts: On hourly-billed providers, destroying and recreating your VPS sometimes lands you on a less loaded host. Free to try
• Monitor and escalate: If steal consistently exceeds 10%, open a support ticket. Good providers will migrate you to a quieter host

Decision Guide: Should You Pay for Dedicated CPU?

After years of dealing with this exact question for clients, here is the framework I use:

Stay on Shared CPU If:

• Your average CPU usage is under 20%
• Your workload is bursty (web requests, API calls) not sustained
• You are running a development or staging environment
• Budget is the primary constraint
• You can tolerate occasional performance variability

Upgrade to Dedicated CPU If:

• Your average CPU usage exceeds 30% for extended periods
• You run databases serving production traffic
• You run CI/CD pipelines or batch processing jobs
• Your application's SLA requires consistent response times
• You are seeing CPU steal above 5% in top
• You host game servers or real-time applications

Consider Bare Metal Instead If:

• You need 8+ dedicated cores consistently
• Your workload is I/O bound and needs direct NVMe access
• You want guaranteed performance without any virtualization overhead
• See our VPS vs dedicated server comparison

The Cost-Benefit Calculation

Here is how I frame the decision for clients who are on the fence. Estimate the revenue impact of a 30% performance drop during your peak traffic hours. If that number exceeds the difference between shared and dedicated pricing ($10-20/mo), dedicated CPU pays for itself. For a personal blog? Shared is fine. For an ecommerce store doing $5,000/month in sales? The $12/mo premium for dedicated CPU is the best money you will spend on infrastructure. Use our VPS size calculator to get a personalized recommendation based on your specific workload.

Frequently Asked Questions

Is "vCPU" the same as a physical CPU core?

Not always. On shared CPU plans, a vCPU is a time-sliced share of a physical core — you might get 25-50% of an actual core depending on host load. On dedicated CPU plans, a vCPU is typically a hyper-thread (not a full core), which provides about 70-80% of a full physical core's performance. Some providers (like Hetzner) explicitly state whether you get threads or full cores. Always check our benchmarks for real-world performance rather than relying on vCPU counts.

Can a shared CPU VPS run a database?

Yes, for low-traffic applications. A shared 2 vCPU VPS can handle a PostgreSQL or MySQL database serving a few hundred queries per second. But for production databases serving thousands of queries/sec or requiring consistent latency, dedicated CPU is strongly recommended. CPU steal directly translates to slower queries and unpredictable response times. See our WordPress VPS guide for database configuration tips.

Why is Contabo so cheap without dedicated CPU?

Contabo achieves its low pricing through aggressive CPU overcommit (selling more vCPUs than physical cores exist) and using older hardware. Their 4 vCPU plan at $7/mo might share a physical core with 8-12 other vCPUs. This works for light workloads but means performance is the most variable among providers we test. Contabo scores 3,200 in our benchmarks during optimal times but can drop significantly under heavy host load.

Does more RAM help if my CPU is throttled?

No. RAM and CPU are independent resources. If your CPU is being throttled due to noisy neighbors, adding RAM will not help. The solution is to either move to a dedicated CPU plan or migrate to a different host. However, if your application is swapping (using disk as RAM), that does create CPU overhead — in that case, more RAM would help indirectly by eliminating swap I/O. Use the VPS calculator to size your server correctly.

Can I start shared and upgrade to dedicated later?

Yes, at most providers. Vultr, DigitalOcean, Linode, and Hetzner all allow you to resize or switch plan types. Some providers require a brief downtime (reboot) for the migration. Start with shared CPU to validate your workload, monitor CPU usage and steal time for a week, and upgrade to dedicated only when the numbers justify it. This is the most cost-effective approach for new projects.

What is a normal CPU steal percentage on a shared VPS?

On a well-managed host, CPU steal should be 0-3% most of the time. Occasional spikes to 5-8% during peak hours are normal and usually not noticeable. Sustained steal above 10% indicates the host is oversold — your performance is being meaningfully impacted. Above 20% is a serious problem that warrants contacting support or migrating. Run vmstat 1 60 to measure steal over a minute and check at different times of day for an accurate picture.

Do dedicated CPU plans guarantee consistent network and disk performance too?

Not necessarily. Dedicated CPU guarantees CPU isolation, but disk I/O and network bandwidth are typically still shared resources even on dedicated CPU plans. A neighbor running heavy disk writes can still affect your disk latency. Some providers offer dedicated disk IOPS (DigitalOcean Premium Droplets, AWS EBS Provisioned IOPS) at additional cost. For fully isolated performance across CPU, disk, and network, you need bare metal — but dedicated CPU eliminates the biggest variable for most workloads.

Is dedicated CPU worth the 3x price premium?

It depends entirely on your workload's sensitivity to CPU variability. For a WordPress blog with 10K monthly visitors, the answer is no — shared CPU handles bursty web traffic fine. For a production database, game server, or CI/CD pipeline where performance consistency directly affects revenue or user experience, the 3x premium is cheap insurance. Calculate it this way: if a 30% performance drop during peak hours costs you more than the price difference per month, dedicated CPU pays for itself.