How to size a VPS without guessing

Most people choose a VPS the same way: look at the table, pick something that feels safe, and move on. It works, in the sense that the site loads. It also means a lot of Indian teams are paying for 32 GB of memory to run a workload that peaks at six, and a lot of others are wondering why their ₹149 plan keeps falling over.

There is a better method and it takes one week.

Measure four things, over one ordinary week

Not a launch week, not a sale week. An ordinary one, because the plan has to survive the ordinary weeks and burst through the rest.

1. Peak resident memory, not average

Average memory use is a comforting number that tells you nothing. What matters is the highest point the working set reaches during normal traffic, because that is where swapping starts. Run free -m on a one-minute cron for a week, or read it off your monitoring, and take the peak.

Then add headroom: roughly 25% for the operating system, page cache and the occasional import job. If the peak is 5 GB, you want an 8 GB plan, not a 6 GB one.

2. CPU saturation, not CPU percentage

“CPU at 80%” means very little on its own. What you want is load average against core count. If your one-minute load average sits at or above your vCPU count for sustained periods during business hours, you are saturated. If it spikes there for ninety seconds during a nightly batch and then drops, you are fine — that variability is exactly what a VPS is for.

3. I/O wait

iostat or the wa column in top. On NVMe storage, sustained I/O wait almost never means the disk is slow. It means the application is doing far more I/O than it should — usually an unindexed query, a log file being written synchronously, or a backup running in the foreground. Fix that before you buy a bigger plan, because the bigger plan will have the same problem.

4. Database working-set size

For anything with a database, the question that decides your plan is whether the frequently accessed portion of the data fits in memory. When it does, queries are served from RAM and the machine feels instant. When it stops fitting, every query starts touching disk and the site feels broken even though nothing has changed.

This is the single most common reason a VPS that was fine for a year suddenly is not.

Turning the measurements into a plan

What you measured	What it means	What to do
Peak memory well under plan	Over-provisioned	Move down a tier; save the difference
Peak memory near plan ceiling	One import away from swapping	Move up one memory tier
Load average above vCPU count, sustained	Genuinely CPU bound	More vCPU, or a faster host if the work is single-threaded
Load spikes only	Normal	Nothing. This is what you bought
Sustained I/O wait	Almost always the application	Profile queries and logging before upgrading
Working set exceeding RAM	The real upgrade signal	Move up a memory tier now

The vCPU trap

The most expensive mistake in VPS buying is treating vCPU count as a speed dial. It is a parallelism dial. If your bottleneck is one thread — a game server tick, a PHP request, a single-threaded interpreter, a compiler pass — then doubling vCPU changes very little about how long that thread takes to finish. What changes it is a faster core.

That is the entire argument for a high-frequency range, and it only applies to that shape of workload. If your work spreads naturally across processes — container fleets, queue consumers, CI jobs — then more vCPU at the same price is straightforwardly the better purchase.

Headroom is not the same as waste

None of this is an argument for running at 95% of everything. Buy for the peak plus a margin, because the cost of being one tier too small is an outage and the cost of being one tier too large is a few hundred rupees. Just make the margin a decision rather than an accident.

If you would rather send the numbers than interpret them, the sizing form takes four inputs and gets you a specific plan back.