A practical framework based on workload, performance objectives, and operational risk. No guesswork, no overprovisioning.
- Benchmarks collected on real customer workloads between November 2025 and February 2026.
- Plans compared using sustained CPU usage, p95 response time, and memory pressure under peak traffic.
- Cost analysis includes migration effort, backup storage, and downtime risk mitigation.
Start from peak concurrency, not monthly traffic averages.
RAM limits break stability before CPU in most CMS and ecommerce stacks.
A clear backup and restore target matters as much as compute sizing.
1. Define your real workload profile
Most sizing errors happen when teams choose a VPS from marketing labels instead of measured demand. Begin with three metrics: peak concurrent users, average request complexity, and your largest daily traffic spike.
If your traffic is bursty, design for peaks plus a safety margin. If you run predictable workloads (B2B dashboards, intranet apps), optimize for steady-state efficiency and reserve burst capacity only where needed.
- Track peak concurrent users over at least 30 days.
- Measure p95 response time, not only average latency.
- List background jobs: cron, queues, image processing, backups.
2. Size RAM first, then CPU
For WordPress, WooCommerce, Node.js APIs, and game panels, memory pressure is usually the first bottleneck. Once swap usage starts climbing, user experience degrades rapidly and unpredictably.
CPU scaling helps throughput, but insufficient RAM causes instability. A conservative RAM baseline is often cheaper than diagnosing intermittent production incidents later.
- Keep average RAM usage below 70% under normal load.
- Reserve memory headroom for deployments and cache warmups.
- Use alerts at 80% RAM and 90% disk utilization.
3. Choose storage and I/O for your application pattern
NVMe is not just about speed benchmarks. It directly impacts database query latency, cache churn, media processing, and backup windows.
When data durability and recovery speed are business-critical, prioritize IOPS consistency and snapshot performance over raw capacity.
- Database-heavy stacks need stable random I/O.
- Content-heavy websites need capacity plus CDN strategy.
- Validate snapshot restore duration against your RTO target.
4. Align VPS plan with risk and compliance constraints
Plan selection is not only technical. Your operational risk profile matters: public ecommerce, client data, regulated records, or internal systems all imply different controls.
For EU-facing businesses, make sure hosting location, backup region, and processor contracts are coherent with GDPR obligations and your own retention policy.
- Define RPO/RTO before selecting the final plan.
- Use multi-region backups for business-critical workloads.
- Document incident response and maintenance procedures.
Reference sizing matrix
Use this table as a starting point. Final sizing should always be validated with staging load tests and production observability data.
| Profile | vCPU | RAM | Storage | Bandwidth | Note |
|---|---|---|---|---|---|
| Business brochure site / low traffic blog | 2 vCPU | 4 GB | 50-80 GB NVMe | 1-2 TB | Good baseline for stable growth and caching. |
| Growing WooCommerce / API app | 4 vCPU | 8-12 GB | 100-160 GB NVMe | 3-5 TB | Balance for checkout, search, and background jobs. |
| High-traffic marketplace / SaaS backend | 6-8 vCPU | 16-24 GB | 200+ GB NVMe | 5+ TB | Supports high concurrency and failover operations. |
Production migration checklist
This checklist is the minimum baseline we use before any managed migration cutover.
- Baseline current CPU, RAM, disk, and p95 latency before migration.
- Clone production to staging and run load tests with real-like traffic.
- Validate rollback plan and DNS TTL strategy.
- Test full backup restore to a clean instance (not just snapshot creation).
- Schedule cutover during low-traffic window and monitor 24h post-migration.
FAQ
How much RAM should I allocate for WordPress + WooCommerce?
For active stores, 8 GB is a practical starting point. 4 GB can work for small catalogs, but headroom is usually limited during spikes, updates, and plugin-heavy workloads.
Is 2 vCPU enough for production?
Yes for small and medium websites with good caching and limited background jobs. For dynamic APIs or ecommerce under regular peaks, 4 vCPU is typically safer.
When should I scale vertically vs optimize first?
Optimize first when you have obvious bottlenecks (no cache, slow queries, oversized plugins). Scale when demand remains high after optimization or when risk tolerance is low.
Sources and references
Topics
Back to blog