Divide gigabytes by price and you get a number that looks objective and predicts almost nothing. Two $10 plans advertising 4 GB can differ by 40% in the memory actually available to your application once overcommit, ballooning, swap behaviour and page cache accounting are applied. RAM per dollar measures a sales figure, not a resource.<\/p>\n\n\n\n
The metric persists because it is easy to compute and because most comparison sites reward it, since it lets a table rank ten providers on a single column. The correction is to measure effective RAM instead: the amount a workload can touch repeatedly without triggering reclamation or swap. That number is what determines whether your PHP-FPM pool, Postgres instance or JVM holds up under load.<\/p>\n\n\n\n
It also ignores the direction of travel. Hosts that raise RAM per dollar usually do it by squeezing the overcommit ratio or the IOPS ceiling, so the metric can improve while the experience gets worse. A column that rewards cost-cutting tends to produce cost-cutting.<\/p>\n\n\n\n
On KVM, the hypervisor hands the guest a balloon driver and can reclaim pages when the host is under memory pressure. The guest sees 4 GB of address space and a Memory overcommit ratios of 1.2–1.5 are normal and not dishonest — most workloads never touch their full allocation, and passing the savings on is how $5 plans exist. The problem is that the ratio is invisible. A host at 1.5 will give you roughly 2.7 GB of reliably usable memory on a 4 GB plan; a host at 1.1 gives you about 3.6 GB for the same sticker price.<\/p>\n\n\n\n Burstable versus guaranteed is the distinction most worth asking about. Some hosts sell burstable memory: you can use the full 4 GB briefly, and the host expects you to average less. Others guarantee the allocation outright. Both can be legitimate products, but only one is suitable for a database with a fixed buffer pool. For Postgres, a guaranteed 2 GB beats a burstable 4 GB every time, because the burstable figure is a ceiling that pressure can remove.<\/p>\n\n\n\n Ask the provider directly which model it sells, then verify with a sustained allocation test: hold Swap does not create memory; it buys time at the cost of I\/O. A 1 GB swap file on NVMe with a 1,500 IOPS budget can absorb a few hundred megabytes of cold pages before latency visible to your application climbs. Enable it, but count it as 0 GB in any comparison — and never let a swap-backed figure appear in a RAM-per-dollar calculation.<\/p>\n\n\n\n Check Page cache is the RAM you already paid for. Linux uses spare memory for page cache, and on a 2 GB box serving a WordPress site that cache may hold 800 MB of hot file data. Buyers who measure free memory see 300 MB available and panic; the kernel is using the rest efficiently and will release it under pressure. This cuts both ways. A provider with faster storage needs less page cache to hit the same latency, so a 2 GB plan on NVMe with a good IOPS ceiling can outperform a 4 GB plan on saturated SATA for read-heavy work. RAM per dollar misses the substitution entirely.<\/p>\n\n\n\n In the table the usable range is wide on purpose. It describes hosts at 1.05 and 1.2 overcommit; at 1.4 the $10 tier drops to roughly 2.9 GB, which changes the answer for a Postgres instance tuned to a 2 GB shared_buffers. That is the whole problem with a single ratio: the same $10 buys meaningfully different capacity at different hosts.<\/p>\n\n\n\n Note also what does not scale. Doubling the RAM tier usually doubles storage and transfer but does not double single-core throughput, so a workload limited by CPU steal or IOPS latency sees no benefit from the larger plan. Measure first to find which resource is actually binding, then buy the tier that fixes it and nothing more.<\/p>\n\n\n\n Use three figures instead of one: Test it yourself before committing: deploy, run the workload, and record the three figures. Twenty minutes of measurement beats every comparison table on the internet, including ours. That is why we publish full specs per tier on the budget VPS comparison<\/a> page — the numbers are only useful if you can check them against a running instance.<\/p>\n\n\n\nfree -m<\/code> total of 4 GB, but MemAvailable<\/code> can sit at 3.2 GB before you have run anything. Under sustained allocation the balloon inflates and the OOM killer arrives earlier than the plan suggests.<\/p>\n\n\n\nBurstable versus guaranteed allocation<\/h2>\n\n\n\n
stress-ng --vm 1 --vm-bytes 3G --timeout 1800s<\/code> for thirty minutes and record whether swap grows. A guaranteed plan will not swap at 75% utilisation; a burstable one usually will.<\/p>\n\n\n\nSwap, zram and the cost of pretending<\/h2>\n\n\n\n
vmstat 1<\/code> under load. Sustained si<\/code>\/so<\/code> above a few hundred KB\/s means the plan is relying on swap to meet its advertised footprint. That is a signal to resize upward, not a tuning problem to chase.<\/p>\n\n\n\nPage cache: the RAM you already paid for<\/h2>\n\n\n\n
MemAvailable<\/code> accounts for this correctly and free<\/code> alone does not, which is why every recommendation in this article uses the former.<\/p>\n\n\n\nWhat the three common tiers actually buy<\/h2>\n\n\n\n
Tier<\/th> Advertised<\/th> Typically usable<\/th> Comfortable workload<\/th><\/tr><\/thead> $5\/mo<\/td> 2 GB \/ 1 vCPU<\/td> 1.6–1.8 GB<\/td> Static site, small WP, a few containers<\/td><\/tr>\n $10\/mo<\/td> 4 GB \/ 2 vCPU<\/td> 3.3–3.7 GB<\/td> WP with caching, Postgres up to ~2 GB cache, small API<\/td><\/tr>\n $20\/mo<\/td> 8 GB \/ 4 vCPU<\/td> 6.8–7.4 GB<\/td> Mid-size database, JVM service, Docker stack<\/td><\/tr>\n<\/tbody><\/table><\/figure>\n\n\n\n A better metric to compare on<\/h2>\n\n\n\n
MemAvailable<\/code> after ten minutes of your real workload, 95th-percentile swap-in rate over 24 hours, and the billed cost of the plan including required add-ons. Effective RAM per dollar is then available memory divided by the twelve-month total cost, which is a number that reflects what the host charges you rather than what the order form prints.<\/p>\n\n\n\n