Shared vs Dedicated CPU for VPS: Which Should You Choose?

Choosing between shared CPU and dedicated CPU VPS instances can save you hundreds of dollars per year while ensuring your application performs well. This comprehensive guide explains the technical differences, provides real-world benchmarks, and helps you make the right choice.

What is a Shared CPU VPS?

A shared CPU VPS (also called "burstable" or "shared-core") allocates virtual CPU cores that are shared with other customers on the same physical server.

How It Works

• Physical cores are shared: Multiple VPS instances use the same physical CPU cores
• CPU credits system: You accumulate credits when idle, spend them during bursts
• Baseline performance: Guaranteed minimum CPU usage (e.g., 20% of a core)
• Burst capability: Use 100% of a core temporarily when credits available
• Throttling: Performance reduced when credits depleted

Example: 2 vCPU Shared Instance

# Baseline: 20% of 2 cores = 0.4 cores always available
# Burst: Up to 2 full cores when needed (for minutes, not hours)
# Cost: $6/month

# When you use:
# - Normal traffic: 10-30% CPU → Earning credits
# - Traffic spike: 80% CPU for 5 minutes → Spending credits
# - Sustained load: 80% CPU for hours → Credits depleted, throttled to 20%

What is a Dedicated CPU VPS?

A dedicated CPU VPS allocates full physical CPU cores exclusively to your instance.

How It Works

• Reserved physical cores: CPU cores are not shared with other customers
• Consistent performance: 100% of CPU power always available
• No throttling: No CPU credits or baseline limits
• Predictable: Performance does not vary based on neighbors
• Higher cost: Premium pricing for reserved resources

Example: 2 vCPU Dedicated Instance

# Always available: 100% of 2 cores
# Burst: N/A (no concept of bursting)
# Cost: $18/month

# When you use:
# - Normal traffic: 10-30% CPU → No credits, just available capacity
# - Traffic spike: 80% CPU for hours → Full performance maintained
# - Sustained load: 80% CPU for days → Full performance maintained

Key Differences Comparison

Performance Benchmarks

CPU-Intensive Task (Video Encoding)

Encoding a 1GB video file using FFmpeg:

Web Application (WordPress)

Handling 100 concurrent users with Apache Bench:

Database Queries (PostgreSQL)

Benchmark: 100,000 SELECT queries with JOINs:

The Noisy Neighbor Problem

Shared CPU instances are vulnerable to "noisy neighbors"—other VPS instances on the same physical server consuming excessive resources.

Real-World Example

# Monitor CPU steal time (CPU stolen by hypervisor for other VMs)
top
# Look for "%st" column

# Shared CPU during noisy neighbor:
# %st = 15-30% (significant steal time)
# Your application sees 70-85% of promised CPU

# Dedicated CPU:
# %st = 0-2% (minimal steal time)
# Your application sees 98-100% of promised CPU

Impact on Application Performance

• API latency: Requests that take 50ms can spike to 200-500ms
• Database queries: 10ms queries become 40-100ms
• Background jobs: Tasks take 2-4x longer to complete
• Unpredictability: Performance varies hour-to-hour

When to Use Shared CPU

Ideal Use Cases

• Development and testing environments: Low cost, infrequent usage
• Staging servers: Only active during deployment windows
• Low-traffic websites: Personal blogs, small business sites (< 1,000 daily visitors)
• Scheduled tasks: Cron jobs that run for minutes, then idle
• CI/CD build servers: Burst during builds, idle between commits
• Learning and experimentation: Student projects, tutorials

Traffic Pattern Example

# Shared CPU is perfect when:
# - CPU usage < 30% most of the time
# - Occasional spikes to 80-100% for < 10 minutes
# - Acceptable performance degradation during spikes
# - Cost is primary concern

# Example: Marketing site
# - Normal: 5-10% CPU (serving cached pages)
# - Blog post goes viral: 90% CPU for 20 minutes (acceptable slowdown)
# - Back to normal: 5-10% CPU (credits replenished)

When to Use Dedicated CPU

Ideal Use Cases

• Production applications: Customer-facing services requiring consistent performance
• Databases: PostgreSQL, MySQL, Redis under sustained load
• API servers: RESTful APIs with SLA requirements
• Real-time applications: WebSocket servers, gaming backends
• Background workers: Queue processors running 24/7
• High-traffic websites: E-commerce, SaaS dashboards (> 10,000 daily visitors)
• Video/image processing: Continuous encoding or transcoding
• Machine learning inference: Model serving with consistent latency

Traffic Pattern Example

# Dedicated CPU is required when:
# - CPU usage > 40% sustained (hours/days)
# - Consistent low-latency required (< 100ms p95)
# - Customer SLAs must be met
# - Performance predictability is critical

# Example: SaaS application
# - Normal: 40-60% CPU (serving active users)
# - Peak hours: 70-90% CPU (more concurrent users)
# - Overnight: 30-40% CPU (background jobs, cron tasks)
# - Need: Consistent sub-100ms response times 24/7

Cost Analysis

DanubeData Pricing Comparison

Cost vs Value Analysis

Is dedicated CPU worth 2.5-3x the cost?

# Scenario 1: Low-traffic blog (1,000 visitors/day)
# Shared CPU: $3.99/mo
# CPU usage: 5-15% average
# Verdict: Shared CPU is perfect. Save $6/mo ($72/year)

# Scenario 2: API server (50 req/s sustained)
# Shared CPU: $6.99/mo → Performance degrades after 30min → Lost revenue
# Dedicated CPU: $17.99/mo → Consistent performance → Happy customers
# Verdict: Dedicated CPU worth it. Extra $11/mo prevents downtime

# Scenario 3: Background job processor
# Shared CPU: $12.99/mo → Jobs take 3x longer → Queue backs up
# Dedicated CPU: $35.99/mo → Jobs complete on time → Queue stays healthy
# Verdict: Dedicated CPU worth it. Extra $23/mo ensures reliability

Monitoring CPU Performance

Check CPU Credits (AWS-style)

# Many providers show CPU credit balance
# Example: DigitalOcean Droplets dashboard

# If credits approach zero:
# - Reduce CPU usage (optimize code)
# - Upgrade to larger shared instance (more baseline)
# - Switch to dedicated CPU

Monitor CPU Steal Time

# Install monitoring tools
sudo apt install sysstat

# Check CPU steal percentage
mpstat 1 10

# Output:
# %steal > 10% = Significant noisy neighbor impact
# %steal 5-10% = Moderate impact
# %steal < 5% = Minimal impact (acceptable)

# If steal is high, contact support or switch to dedicated CPU

Application Performance Monitoring

# Monitor application response times
# If p95 latency increases during peak hours:
# - Check CPU usage (might be throttled)
# - Check steal time (noisy neighbors)
# - Consider dedicated CPU upgrade

Migration: Shared to Dedicated CPU

Switching from shared to dedicated CPU is straightforward:

On DanubeData

# Option 1: Resize in dashboard (5 minutes downtime)
# 1. Navigate to VPS → Settings → Resize
# 2. Select same vCPU/RAM but "Dedicated CPU" option
# 3. Confirm resize
# 4. VPS reboots with dedicated CPU cores

# Option 2: Create new VPS and migrate
# 1. Create new dedicated CPU VPS
# 2. rsync data from old to new VPS
# 3. Update DNS to point to new IP
# 4. Delete old shared CPU VPS

Zero-Downtime Migration

# For production apps requiring zero downtime:

# 1. Create dedicated CPU VPS
# 2. Set up load balancer pointing to both VPS
# 3. Sync data from shared to dedicated
# 4. Remove shared VPS from load balancer
# 5. Delete shared VPS when no longer needed

# Example with Nginx load balancer:
upstream backend {
    server shared-vps-ip:80 weight=1;
    server dedicated-vps-ip:80 weight=3;
}

# Gradually shift traffic to dedicated VPS

Provider Comparison

Frequently Asked Questions

Can I run a database on shared CPU?

Yes, but only for development/testing. Production databases should use dedicated CPU for consistent query performance.

How do I know if I am being throttled?

Check CPU steal time with mpstat. High steal (> 10%) or degraded performance after sustained load indicates throttling.

Do dedicated CPU instances have better network performance?

Usually yes. Dedicated instances often come with higher network bandwidth and better I/O performance.

Can I switch between shared and dedicated CPU?

Yes. Most providers allow resizing with minimal downtime (5-10 minutes).

Is shared CPU good for Docker containers?

Shared CPU works for development containers. Production container orchestration (Kubernetes) should use dedicated CPU nodes.

Decision Framework

Use this simple decision tree:

Start
  |
  ├─ Is this production?
  |   ├─ Yes → Dedicated CPU
  |   └─ No → Shared CPU (dev/test/staging)
  |
  ├─ CPU usage > 40% sustained?
  |   ├─ Yes → Dedicated CPU
  |   └─ No → Shared CPU
  |
  ├─ Strict SLA requirements (p95 < 100ms)?
  |   ├─ Yes → Dedicated CPU
  |   └─ No → Shared CPU
  |
  └─ Budget extremely limited?
      ├─ Yes → Shared CPU (monitor performance)
      └─ No → Dedicated CPU (peace of mind)

Get Started with DanubeData VPS

Deploy your VPS in under 60 seconds with transparent shared vs dedicated CPU pricing:

1. Create your free account
2. Navigate to VPS → Create Instance
3. Choose between Shared CPU (starts at $3.99/mo) or Dedicated CPU (starts at $9.99/mo)
4. Select your OS (Ubuntu, Debian, CentOS, Rocky Linux)
5. Deploy and SSH in within 60 seconds

DanubeData VPS Features:

• Transparent pricing (no hidden fees)
• NVMe SSD storage included
• Automated daily backups
• Firewall rules and security groups
• Monitoring dashboard with CPU metrics
• 1-click OS reinstall and snapshots
• IPv4 and IPv6 included
• Resize anytime (shared ↔ dedicated)

Need help choosing? Contact our team or check our VPS documentation for sizing recommendations.