Skip to main content

VPS Sizing Calculator — How Much vCPU & RAM Do You Need?

A WooCommerce store at 100,000 monthly visits with 200 peak concurrent users on Linux needs at minimum 2 vCPU / 4 GB RAM — that is Hostinger KVM 2 (2 vCPU / 8 GB, ≈$7-10/mo). The math: ⌈100,000 ÷ 50,000⌉ = 2 blocks → 2 vCPU; RAM 2 × 1 × 1.75 + 0.5 = 4 GB; 50 GB NVMe disk and ≈300 GB/mo of bandwidth. With a +30% growth buffer the recommendation becomes 3 vCPU / 6 GBKVM 4 (≈$13-18/mo). The rule: start at the tier that fits the minimum — KVM upgrades are vertical, minutes, no reinstall — and never buy a bigger tier "just in case": unused RAM does not make WordPress faster.

Your workload minimum (no buffer)2 vCPU / 4 GB
Recommended with +30% headroom → KVM 43 vCPU / 6 GB
NVMe disk50 GB
Bandwidth — Moderate (100-500 GB/mo)300 GB/mo
WorkloadVisits/movCPU / RAMTier
Static site100,0001 vCPU / 2 GBKVM 1
WordPress50,0001 vCPU / 2 GBKVM 1
WordPress200,0004 vCPU / 5 GBKVM 4
WooCommerce100,0002 vCPU / 4 GBKVM 2
WooCommerce300,0006 vCPU / 11 GBKVM 8
Node.js app100,0002 vCPU / 3 GBKVM 2
VerdictSize for the minimum, buffer for growth: start at the KVM tier that fits your stack today — vertical upgrades take minutes with no reinstall — and never pre-pay for traffic you don't have (nor oversell into a tier your load can't justify).

VPS Sizing Calculator — How Much vCPU & RAM Do You Need?

Inputs

What is your stack?

WooCommerce: WordPress blocks with ×1.75 RAM — carts, checkout queries and sessions are memory-hungry.

Monthly visits: 100,000

about 3,333 visits/day

Peak concurrent users: 200

web-stack burst: +0 GB beyond the first 200 concurrent

Database size? (drives the database workload)

Rule: RAM = 3× data size.

Operating system?

Linux idles at 0.5 GB — Windows adds 2 GB and a bigger disk.

Planning for growth?

+30% buffer for expected growth — recommended for young projects.

Default scenario: WooCommerce · 100,000 visits · 200 concurrent · Linux — edit inputs
Recommended VPS size for your stack · 2026 model
2 vCPU / 4 GB RAM
your workload minimum → KVM 2
30 SAR (pegged rate)
⌈100,000 ÷ 50,000⌉ = 2 block(s) → 2 vCPU; RAM = 2 × 1 × 1.75 + burst 0 + 0.5 GB OS; disk 50 GB; bandwidth ≈ 300 GB/mo.
Your workload minimum (no buffer)2 vCPU / 4 GB
Recommended with +30% headroom3 vCPU / 6 GB
NVMe disk (OS + project data)50 GB
Expected monthly bandwidthModerate (100-500 GB/mo) · ≈300 GB
Matching Hostinger KVM tiers
KVM 1 — 1 vCPU / 4 GB≈$5-7/mo
KVM 2 — 2 vCPU / 8 GB≈$7-10/mo
KVM 4 — 4 vCPU / 16 GB≈$13-18/mo
KVM 8 — 8 vCPU / 32 GB≈$25-35/mo
Beyond KVM 8 — 8+ vCPU / 32+ GB≈$60+/mo or dedicated
Verdict: minimum vs recommended

Your minimum is 2 vCPU / 4 GB → KVM 2 (≈$7-10/mo); with +30% headroom it becomes 3 vCPU / 6 GB → KVM 4 (≈$13-18/mo). Start at the tier that fits the minimum: KVM upgrades are vertical from the control panel — minutes, no reinstall — so don't pre-pay for traffic that hasn't arrived. But don't oversell either: buying KVM 8 for a small blog "just in case" burns about ≈$25-35/mo — unused RAM doesn't make WordPress faster, and the honest upgrade signal is sustained CPU above 80% or any swap usage.

Size for the minimum, buffer for growth: start at the KVM tier that fits your stack today — vertical upgrades take minutes with no reinstall — and never pre-pay for traffic you don't have (nor oversell into a tier your load can't justify).

The sizing model is a 2026 planning heuristic (50k-visit blocks, 200 concurrent per unit, RAM = 3× data) and published KVM tier bands — not live prices and not a guarantee: measure real CPU/RAM after launch and size again.

Common cases (Linux, no buffer, ≤200 concurrent)
WorkloadVisits/movCPU / RAMTier
Static site100,0001 vCPU / 2 GBKVM 1
WordPress50,0001 vCPU / 2 GBKVM 1
WordPress200,0004 vCPU / 5 GBKVM 4
WooCommerce100,0002 vCPU / 4 GBKVM 2
WooCommerce300,0006 vCPU / 11 GBKVM 8
Node.js app100,0002 vCPU / 3 GBKVM 2
Node.js app100,0005 vCPU / 6 GBKVM 8
Database server100,0004 vCPU / 31 GBKVM 8

Results

Embed This Calculator

Share this tool with your audience. 100% free and fully responsive.

How the VPS sizing calculator works

VPS sizing is not guesswork, it is a load table: each project type is measured in its own unit — a 50k-visit block for WordPress and WooCommerce, a 200-concurrent unit for Node.js, three times data size for databases, a 10-player block for game servers — then fixed, known overheads are added (OS, peak concurrency, optional growth buffer). The result maps onto real KVM tiers so you know which plan absorbs the minimum and which absorbs the recommendation, then you decide by budget: start at the floor and climb vertically in minutes when the numbers grow.

  1. 1

    Step 1

    Pick your workload (static site / WordPress / WooCommerce / Node.js / database / game server) and set the monthly-visits slider (10k-2M) and concurrent-users slider (10-2,000) — the calculator derives base load blocks: 1 vCPU + 1 GB per 50k visits for WordPress (WooCommerce ×1.75 RAM), 1 GB per 200 concurrent for Node, RAM = 3× data for databases, one block per 10 players for games.

  2. 2

    Step 2

    Add OS overhead (0.5 GB Linux or 2 GB Windows) and the peak-hour burst for web stacks (concurrent ÷ 200), then flip the +30% growth buffer if you are planning for the climb — the spec appears: vCPU, RAM, NVMe disk and the monthly bandwidth band.

  3. 3

    Step 3

    Read the verdict: the minimum your stack needs versus the recommended size with buffer, and the smallest KVM tier that fits each (KVM 1 at 1 vCPU/4 GB up to KVM 8 at 8/32) — with the common-case reference table and the current-pricing link for the matching plan.

Use Cases

Before buying your first VPS: know exactly whether your project is a KVM 1 or something bigger — no months on a starving plan, no money burned on an oversized one.

When a WordPress or WooCommerce site slows down: compare your current plan against the calculator output — if your RAM is under the minimum, a vertical upgrade beats any optimization plugin.

When migrating off shared hosting: feed current and expected traffic into the sliders and learn which KVM tier receives the migration with no surprises.

Tips

  • 1

    Re-check the output every 3-6 months: 50% traffic growth changes your block count, and upgrading before saturation is cheaper than firefighting.

  • 2

    Watch real metrics after launch: sustained CPU above 80% or any swap usage means you are at the edge — that is the upgrade signal, not a vague feeling of slowness.

  • 3

    Caching changes the answer: full-page caching can drop you a whole KVM tier — try the cache before paying for the bigger plan.

Common Mistakes

  • Buying the biggest plan "just in case": unused RAM does not make WordPress faster — and the KVM 2-to-KVM 8 gap compounds into hundreds of dollars a year for nothing.

  • Forgetting the OS and the database share the box: a "theoretical" 1 GB evaporates once Linux, MySQL and PHP load — the calculator adds overheads for a reason.

  • Sizing on monthly visits alone: peak concurrency is what drops a server at launch or during a campaign — that is why it has its own slider.

FAQs

How much RAM does WordPress need on a VPS in 2026?

The planning model: one block per 50,000 monthly visits = 1 vCPU + 1 GB RAM, plus 0.5 GB for the OS — so 50k visits ≈ 2 GB and 100k ≈ 4 GB. In practice 2 GB is the sane floor for WordPress with MySQL on the same box (set PHP memory_limit around 256M), and a full-page cache like LiteSpeed can drop you a whole tier because cached hits never touch PHP at all.

vCPU vs RAM — which should I prioritize?

For typical stacks (WordPress, databases, PHP apps) start with RAM: running out means swap on disk and a site that collapses, while a CPU shortage degrades gracefully. Computationally heavy moments — WooCommerce checkout, imports, cron bursts — are what eat vCPU. That is why the model pairs 1 vCPU with every 1 GB as a starting ratio, then you steer with your real metrics after launch.

When is 1 GB of RAM actually enough?

For a narrow set: static sites (nginx), reverse proxies, or a small Node API with no database on the same box. WordPress plus MySQL together on 1 GB is not realistic in 2026 — Linux alone takes ~0.5 GB, MySQL wants buffer pool, and you will live on swap. If you insist on the smallest plan, make it KVM 1 with its 4 GB, not a legacy 1 GB droplet.

What is the database sizing rule?

RAM ≈ 3× your data size keeps the hot set in memory instead of on disk: a 10 GB database → ~30 GB RAM → KVM 8 (8 vCPU / 32 GB). Under 1 GB of data fits a KVM 1; at 50 GB+ you are past the KVM ceiling — time for a dedicated server or a managed database, or indexing/partitioning that shrinks the working set for real.

Does Windows really need +2 GB of RAM?

Yes: Windows Server idles at roughly 2 GB versus ~0.5 GB for Linux, and wants a bigger disk (~45 GB base vs 20). Budget the +2 GB only if your app is legacy .NET/ASP — most 2026 stacks (PHP, Node, Python, MySQL, PostgreSQL) run better and cheaper on Linux, and you skip the license cost too.

Vertical vs horizontal scaling — which one do I want?

Vertical: a bigger plan on the same machine — zero code or deploy changes, and the right answer for 95% of small projects. Horizontal: several machines behind a load balancer — real added complexity (shared sessions, multi-node deploys, a central database) that is not worth it until you saturate the largest plan or need geographic redundancy. Start vertical: KVM 1 → KVM 2 → KVM 4 are all minutes-long plan changes.

Managed vs unmanaged VPS — which should I pay for?

Unmanaged (like KVM plans) is cheaper but you handle OS updates, certificates, firewall and backups. Managed costs multiples and takes those chores. The rule: pay for managed when the alternative is hiring a sysadmin for more, or when the site is direct revenue that cannot tolerate downtime. A developer comfortable with servers gets unbeatable value from unmanaged.

Can I upgrade later without reinstalling?

Yes on KVM plans: the upgrade is vertical from the control panel — a plan change with a short minutes-long reboot, and your files, database and config stay untouched, no reinstall, no migration. That is exactly why "start at the tier that fits the minimum" is safe: do not pre-pay for traffic that has not arrived. Still keep weekly off-box backups — an upgrade is not a backup, and disks do not schedule their failures.