Price Per Core on Budget VPS Plans: A Comparison Methodology That Corrects for Oversubscription

“$5 for 2 cores” and “$12 for 4 cores” look like an easy comparison until you notice that neither plan tells you what a “core” is. Price per core is the most useful normalized metric in budget hosting — and the easiest one to calculate incorrectly. Here is a methodology that gets you a number you can actually compare.

Plan	Price/mo	Advertised cores	Naive $/core	Share ratio	Effective cores	Real $/core
Provider A	$5	2	$2.50	1:1	2.00	$2.50
Provider B	$5	2	$2.50	1:4	0.50	$10.00
Provider C	$12	4	$3.00	1:2	2.00	$6.00
Provider D	$8	3	$2.67	1:1 (burstable)	1.50	$5.33

The naive column says Provider A is the cheapest. The corrected column says Provider C is less than half the price of Provider B for the same advertised core count. That reversal is the entire point of doing this properly.

Step 1: Convert Advertised Cores to Effective Cores

Effective cores = advertised cores × (1 ÷ oversubscription ratio) for shared plans, or × share ratio where the provider publishes one. Common ratios on budget hosts run from 1:1 (dedicated) to 1:8 (heavily shared). A 1:4 host sells four times the threads it physically owns. If the provider doesn’t publish the ratio (most don’t), use these defaults: KVM plans on reputable budget hosts, assume 1:2 to 1:4. OpenVZ/container plans, assume 1:4 to 1:8. Dedicated-vCPU claims, verify with evidence before using 1:1.

Step 2: Add the Cost of the Things Cores Need

Cores are useless without RAM and disk, and providers price those independently. A plan that looks cheap per core may require more core count to unlock the RAM you need. Normalize to a target workload instead: pick the RAM and disk you actually require, then compare price per effective core within that tier only. Comparing a 1 GB plan’s core economics to a 4 GB plan’s is meaningless.

Step 3: Measure, Don’t Trust

• Single-thread speed: run sysbench cpu run --threads=1. Two fast cores often beat four slow ones for web serving.
• Sustained multi-thread: run sysbench cpu run --threads=4 --time=60 and watch for the score degrading after 30 seconds — that’s the burst budget expiring.
• Steal time: check top or vmstat for the st column. Persistent steal above 5% means the host is oversubscribed and your effective cores are fewer than advertised.

Step 4: Weight by Workload Type

For a WordPress site or API, single-thread performance matters more than core count — PHP-FPM and Node.js are largely single-threaded per request. For build servers, encoding, and scraping pools, total effective cores matter. For databases, core count matters less than NVMe random IOPS. A price-per-core comparison is only a starting filter; the workload type decides which column you optimize.

Worked Example

You need 2 GB RAM for a small WordPress site with WooCommerce. Three candidates:

• Plan X — $6/mo, 1 vCPU @ 1:1, 2 GB: $6.00 per effective core. Fewest cores, best single-thread.
• Plan Y — $8/mo, 2 vCPU @ 1:4, 2 GB: $16.00 per effective core. Worst value despite the higher core count.
• Plan Z — $10/mo, 2 vCPU @ 1:2, 2 GB, NVMe: $10.00 per effective core. Best balance for WooCommerce.

The correct pick for this workload is Plan Z — not because it’s cheapest per core, but because it’s the cheapest per effective core that also clears the NVMe and RAM thresholds. To run this comparison on real plans, pull the advertised core counts, RAM, and disk types for each candidate from our budget VPS comparison table, then apply the corrected formula above.

Benchmark Script to Verify Effective Cores

Once you have the corrected price-per-core figure, verify it on the live box before you renew. The commands below take under three minutes and reveal whether the advertised allocation is real:

• nproc — confirms the advertised core count the kernel sees.
• sysbench cpu run --threads=1 --time=10 — records single-thread events per second for comparison across providers.
• sysbench cpu run --threads=$(nproc) --time=60 — measures sustained multi-thread throughput; a score that drops noticeably after 30 seconds indicates a burst budget running out.
• vmstat 5 12 — watch the steal (st) column. Anything sustained above 5% means the host is oversubscribed beyond what your share ratio assumes.
• cat /proc/cpuinfo | grep MHz — reveals the CPU model and shared frequency, useful for comparing across providers.

Common Mistakes in Price-Per-Core Math

• Dividing price by advertised cores. This is the error the whole methodology exists to fix.
• Comparing across RAM tiers. A plan’s core economics only mean something within the resource tier you actually need.
• Ignoring storage type. A plan priced per effective core that ships SATA storage is not a comparable buy to an NVMe plan at the same figure.
• Using promo pricing. First-year discounts expire. Recalculate the metric at the renewal rate, which is what you will actually pay long-term.
• Skipping the benchmark. Published ratios are a planning estimate; steal time and run queues are the ground truth.

Applied to a shortlist of four or five plans, this method typically identifies one or two clear winners and eliminates a plan that looked cheap on the pricing page. The gap between the naive and corrected figures is often large enough to fund an upgrade to the next RAM tier at no additional cost.

The Verdict

Price per advertised core is marketing. Price per effective core is arithmetic. Convert the oversubscription ratio, constrain the comparison to a single RAM/disk tier, verify with a 60-second sustained benchmark, and weight the result by whether your workload is single-threaded or parallel. Buyers who do this consistently land on plans 30–50% cheaper for the same delivered capacity.