Most small businesses run great on a 2 vCPU / 4 GB RAM VPS for dynamic sites and light apps; go 4 vCPU / 8 GB if you have WooCommerce, CRM/ERP, or steady 100+ concurrent users; reserve 8 vCPU / 16 GB for heavier workloads (busy ecommerce, multi-app stacks, analytics). Start small if instant upgrades are available, and budget for NVMe SSD, backups, and a firewall.
Quiet plug: Need fast scaling with NVMe, snapshots, and 24/7 help? Check Tremhost VPS (instant resize, free OS templates, optional cPanel/DirectAdmin). If you resell or host clients, see Reseller Hosting and performance stack pages for LiteSpeed and CloudLinux.
How to think about VPS sizing (without guesswork)
- Workload type: static site, WordPress, WooCommerce, SaaS, API, DB, mail, control panel?
- Concurrency: how many simultaneous active users or requests at peak?
- Stack efficiency: web server (LiteSpeed/NGINX vs Apache), PHP opcache, object caching (Redis).
- Overheads: panel (cPanel/DA), security tools, backup agents.
- Headroom: 20–30% buffer so spikes don’t tip you into swap/502s.
vCPU reality check: On quality hosts, 1 vCPU is a fair slice of a modern core. For PHP/WordPress, each busy request can occupy ~1 thread briefly—so vCPUs map loosely to how many dynamic requests you can serve in parallel (with caching).
Quick picker: common SME scenarios
| Scenario (peak) | Traffic pattern | Sensible minimum | Comfortable sweet spot | Notes |
|---|---|---|---|---|
| Company site + blog | <20 concurrent users, cached | 1 vCPU / 2 GB | 2 vCPU / 4 GB | Turn on full-page cache (LSCache). NVMe > SATA. |
| Standard WordPress | 20–60 concurrent | 2 vCPU / 4 GB | 3–4 vCPU / 6–8 GB | Add Redis object cache; PHP 8.x + opcache. |
| WooCommerce (light) | 10–40 concurrent, bursts at checkout | 2 vCPU / 4 GB | 4 vCPU / 8 GB | Don’t cache cart/checkout; optimize DB. |
| Busy WooCommerce | 60–150 concurrent, promos | 4 vCPU / 8 GB | 8 vCPU / 16 GB | Dedicated Redis + tuned MySQL; queue emails. |
| Laravel/Node API | Burst-y API calls | 2 vCPU / 4 GB | 4 vCPU / 8 GB | Run workers/queues; cap node processes. |
| CRM/ERP (Odoo/ERPNext) | 20–60 internal users | 4 vCPU / 8 GB | 8 vCPU / 16 GB | Separate DB if heavy reports. |
| Multi-site (5–10 WP) | Mixed loads | 4 vCPU / 8 GB | 6–8 vCPU / 12–16 GB | Isolate via containers or CloudLinux. |
| Email + small web | Mailboxes + brochure site | 2 vCPU / 4 GB | 3 vCPU / 6 GB | Watch I/O; set sane rate limits. |
| Control panel (cPanel/DA) | Hosting several sites | 4 vCPU / 8 GB | 6–8 vCPU / 12–16 GB | Panels add RAM; backups need I/O. |
If you’re unsure between two sizes, start at the lower one only if your provider supports instant upgrades with zero data loss. Tremhost does.
WordPress/WooCommerce: map concurrency to size
- ≤20 concurrent (mostly cached): 2 vCPU / 4 GB with LiteSpeed/LSCache.
- ~50 concurrent: 4 vCPU / 6–8 GB + Redis object cache, optimized MySQL.
- 100+ concurrent or flash sales: 8 vCPU / 16 GB, separate DB/Redis, queue emails/webhooks.
Must-haves: NVMe, HTTP/3, PHP 8.x with opcache, image/WebP optimization, and transaction-safe email (SMTP API).
SaaS/API/Laravel/Node: think in workers
- Count your worker processes (PHP-FPM pm.max_children, Node clusters) + background jobs.
- Ensure 1–2 vCPUs per busy worker group, with 20–30% CPU buffer.
- Memory: 300–600 MB per PHP-FPM pool under load; Node processes vary (track RSS).
- Add Redis/RabbitMQ memory budget (256–1024 MB) if used.
Database sizing (MySQL/MariaDB/Postgres)
- RAM buys you cache: a bigger innodb_buffer_pool_size often matters more than extra vCPUs.
- Light DB usage (blogs, small catalogs): 1–2 GB earmarked for DB caches.
- Heavier catalogs/analytics: 4–8 GB dedicated; consider separating DB to its own VPS at 4 vCPU / 8 GB+.
Storage, I/O, and why NVMe matters
- NVMe SSD drastically reduces latency for PHP, DB, and mail.
- Provision 20–30% free disk for snapshots and log spikes.
- Backups are I/O hungry—schedule them off-peak; consider incremental backups.
Control panels & overhead
- cPanel/DirectAdmin add ~1–2 GB baseline RAM plus daemons (Exim, Dovecot, ClamAV if enabled).
- If you’re consolidating multiple client sites, don’t skimp: start 4 vCPU / 8 GB.
Hosting client sites? Consider Reseller Hosting with CloudLinux isolation—often simpler than rolling your own panel on a small VPS.
“Right-size” your stack: practical tuning tips
- Use LiteSpeed + LSCache (or NGINX FastCGI cache) for massive PHP offload.
- Turn on PHP opcache (validate timestamps off in stable deployments).
- Add Redis for object sessions/caching; keep it off the default DB.
- HTTP/3 + TLS 1.3 for faster handshakes.
- Swap: 1–2 GB swap is fine for bursts, but constant swapping = undersized.
- Security: fail2ban/modsec rules, WAF, auto-patch; enable 2FA to panels/SSH.
See Tremhost’s LiteSpeed page for performance notes you can reuse in proposals.
When to scale up (and when to split roles)
Scale up if you see:
- CPU >70% sustained or steal time >5–10%
- RAM constantly >85%, swap use rising
- Disk I/O waits (iowait) during traffic peaks
Split roles (web vs DB vs cache/queue) if:
- DB latency drives slow pages despite spare CPU on the web tier
- Background jobs impact request latency
- You need independent maintenance windows
A common step-up path: 4 vCPU / 8 GB → 8 vCPU / 16 GB → split DB to 4 vCPU / 8 GB.
Cost-control recipe (SME edition)
- Start with 2 vCPU / 4 GB + NVMe for most WordPress/LPs.
- Add Redis + LSCache before you add more vCPUs.
- Keep backups incremental, retention sane (7–14 daily + weeklies).
- Use a staging subdomain for updates; avoid live thrash.
- Upgrade when metrics, not fear, say so—ideally with one-click resize.
Example bundles (copy/paste for proposals)
Web-Only (WordPress/SMB)
- 2 vCPU / 4 GB NVMe, LiteSpeed/LSCache, AutoSSL, daily backups, Redis
- Add-ons: managed updates, premium backups, CDN setup
Commerce (Woo)
- 4 vCPU / 8 GB, Redis, tuned MySQL, HTTP/3, transactional email path
- Add-ons: uptime monitoring, monthly performance tune, staging workflow
App + DB (Laravel/Node + MySQL)
- Web: 4 vCPU / 8 GB; DB: 4 vCPU / 8 GB (separate VPS)
- Redis/RabbitMQ on web or third node if heavy queues
FAQs (People Also Ask)
Is 1 vCPU / 2 GB enough for WordPress?
For a simple brochure site with caching, yes. For regular blogging or plugins, 2 vCPU / 4 GB feels smoother and future-proof.
How much RAM for WooCommerce?
Start 4 GB (with 2–4 vCPUs). Busy stores do best at 8 GB and a tuned DB/Redis.
What matters more—CPU or RAM?
For PHP/DB apps, both. RAM prevents swapping; CPU clears bursts. If you must choose, add RAM until swapping stops, then add vCPU.
When should I separate my database?
When DB waits dominate slow pages or reports, or you need independent scaling/maintenance—commonly around 4 vCPU / 8 GB on the web tier.
Do I need NVMe?
If you care about responsiveness under load, yes. NVMe is a noticeable real-world upgrade over SATA SSD.
Want a VPS you can size sanely today and scale in seconds tomorrow? Check Tremhost VPS (NVMe, instant resize, snapshots, 24/7 support). If you host client sites, pair it with Reseller Hosting and performance extras like LiteSpeed and CloudLinux.
