VPS Overselling: Reading RAM-to-vCPU Ratios Before You Buy

A plan advertised as “4 vCPU, 8GB RAM” can deliver anywhere from a genuinely reserved quarter of a node to a heavily contended share of one, depending on how many tenants the provider packs onto the host. The ratio between RAM and vCPU is one of the few public signals of that packing, and it is worth learning to read before you buy. It will not tell you everything, but it filters out plans that cannot possibly deliver what the spec sheet implies.

What RAM-to-vCPU ratios tell you about the host node

A physical server has a fixed number of cores and a fixed amount of RAM. If a provider sells 2GB per vCPU on average, it is planning to host workloads that are memory-light relative to CPU, or it is packing many small instances. If it sells 8GB per vCPU, it expects memory-heavy workloads and may oversubscribe CPU more aggressively because the tenants are unlikely to use it all at once. Neither ratio is wrong; each implies a different contention profile.

The useful check is whether the plan’s own ratio is internally consistent with the host’s likely capacity. A node with 64 cores and 256GB RAM offers 4GB per core at full allocation. A plan with 2 vCPU and 16GB implies 8GB per core, which means either the node has unusually large memory for its core count or the provider is oversubscribing CPU by roughly 2x on memory-heavy tenants. That is a reasonable trade for a database box and a poor one for a build server.

Common plan shapes and what they imply

Budget listings cluster into recognisable shapes. The “web starter” at 1 vCPU and 1GB, the “small business” at 2 vCPU and 4GB, the “developer” at 4 vCPU and 8GB, and the “database” at 4 vCPU and 16GB. The first three are reasonable for their stated purpose and the last is usually oversold on CPU. When a provider sells a 2 vCPU / 16GB plan at $9, the RAM is the selling point and the CPU is likely to be contended, which matters if your database is CPU-bound on write-heavy queries.

Watch for plans where the RAM jumps without the CPU, or the reverse. A 1 vCPU / 8GB plan is a red flag for general use because a single core cannot feed 8GB of application work, so the extra memory is mostly a marketing number. A 8 vCPU / 2GB plan is the opposite problem: lots of CPU, not enough memory for a real workload, useful only for very short burst jobs.

Overselling vs oversubscription: the distinction that matters

Oversubscription is normal and necessary. No provider runs one tenant per node at budget prices; the economics only work if resources are shared and statistical multiplexing does its job. Overselling is the problematic version, where the provider commits more total RAM than the node physically has, relying on swap and ballooning to absorb the gap. The first is a business model; the second is a bet that your workload stays small.

You cannot see the provider’s internal accounting, but you can infer it. Very low prices for generous RAM, no published node specifications, no mention of dedicated or reserved resources, and a “fair use” CPU clause rather than a stated vCPU reservation all point toward aggressive overselling. Providers confident in their packing usually publish the node spec and the oversubscription ratio, because it is a selling point.

How to test a plan before you commit

Buy the smallest term available and run a week of measurements before prepaying. Check CPU steal in top or vmstat during your peak hour, run a memory pressure test with a simple allocation script to see whether the host reclaims or OOM-kills, and benchmark random disk IOPS. If steal stays under 5%, memory pressure does not trigger swapping, and IOPS hold steady, the plan is being packed sensibly regardless of the advertised ratio.

Run the tests at two times of day and on a weekday and weekend, because neighbours’ behaviour varies with their own traffic. Keep the readings in a file and repeat them after any plan change or migration. A short log of steal, IOPS, and latency over a month is the most useful document you can have when a provider proposes a renewal increase and you want to argue from evidence.

Matching the ratio to your workload

CPU-bound work such as builds, encoding, and compilation wants a low RAM-per-vCPU ratio, closer to 2:1, because it needs cores and does not need much memory. Memory-bound work such as caching layers, in-memory databases, and Java applications wants the opposite, closer to 4:1 or 8:1. A general web application sits in the middle at roughly 2:1 to 4:1. If the plan you are considering sits far from your workload’s natural ratio, you are buying capacity you will not use or short on capacity you will.

Translate that into a purchase rule. Pick the ratio first, then the size, then the price. Most buyers do it backwards: they pick the cheapest plan in a size bracket and then discover the ratio is wrong for the workload. Choosing ratio-first narrows the field to plans that can actually serve the job, and the price comparison becomes meaningful. You can filter plans by resource shape on our budget VPS comparison page.

Signals in the terms of service worth reading

Look for a stated CPU allocation model: “fair share”, “100% of one core”, “2 dedicated cores”, or “burst up to”. Fair-share language means the provider can throttle you when the node is busy, which is legitimate but means your peak performance is not guaranteed. Look also for restrictions on sustained CPU usage, crypto-mining prohibitions (which are also an anti-abuse measure), and any clause allowing the provider to migrate your instance to different hardware without notice.

Check the acceptable use policy for anything that limits your ability to run the workload you planned. A budget plan that prohibits sustained high CPU is unsuitable for a build server even if the specs suggest otherwise. Read the SLA if there is one, and note whether it covers performance or only uptime, because a node can be “up” while being unusable. These clauses are short and they decide more disputes than the spec sheet does.

A ratio-first buying checklist

Before buying, note the plan’s RAM-to-vCPU ratio and compare it with your workload’s natural ratio; check whether the provider publishes node specs and an oversubscription ratio; confirm the CPU allocation model in the terms; buy the shortest term and measure steal, memory pressure, and IOPS at two times of day; and only prepay once the measurements are stable. If the provider will not state the allocation model, assume fair-share and price accordingly.

The ratio is a proxy, not a guarantee, and a good provider with an average ratio will beat a bad provider with a perfect one. But it is the fastest public filter available, and it is enough to rule out plans that are structurally unable to deliver their advertised specs. Use it to shorten the list, then verify with measurements. Compare current budget VPS plans with resource shapes listed explicitly, and let the ratio do the first round of elimination.