WordPress VPS sizing is one of those decisions where being wrong in either direction costs money. Buy too much and you are paying for resources sitting idle. Buy too little and your site degrades under real traffic — the exact moment you most need it to perform.
The goal of this guide is to give you a realistic, traffic-based sizing framework — not generic "it depends" advice, but specific starting points that work for most WordPress sites, along with the signals that tell you when to upgrade.
Why WordPress resource usage varies so much
A WordPress site with 5 plugins running static content is fundamentally different from a WooCommerce store with 40 plugins, real-time inventory lookups, and dynamic pricing. Both are "WordPress," but their resource demands are completely different.
The main variables that determine your VPS requirements:
Caching configuration — the single biggest factor. WordPress with a proper page cache (Nginx FastCGI cache, Redis object cache + page caching plugin) can serve thousands of concurrent visitors from a 2GB VPS. Without caching, that same server struggles under a few hundred.
Plugin count and quality — each plugin adds PHP execution overhead. Some popular plugins are extraordinarily resource-intensive (certain page builders, for example). A lean plugin setup changes your resource requirements significantly.
Traffic pattern — steady vs. spike-heavy. A news site that gets a traffic spike when a story goes viral has different needs than a SaaS dashboard with consistent daily active users.
Database size and query complexity — a WooCommerce store with 50,000 orders has more database overhead than a blog with 200 posts.
Keep these variables in mind as you read the baseline recommendations below. They are starting points, not exact prescriptions.
Baseline sizing by traffic level
Low traffic: up to 20,000 visits per month
Recommended: 2 vCPU / 2–4 GB RAM / 40–60 GB NVMe SSD
At this traffic level, a properly cached WordPress site runs comfortably on 2 vCPUs and 2GB of RAM. The 4GB option makes sense if you are running WooCommerce, a page builder like Elementor with many animations, or a plugin stack that is heavier than average.
What "properly cached" means here: a page caching plugin is active, images are optimized (next-gen formats, lazy loading), and you are not running unnecessary background cron jobs.
Common mistake: choosing 1 vCPU / 1 GB RAM to save cost. PHP-FPM, MySQL, and Nginx together at idle consume roughly 500–700MB. That leaves almost nothing for actual requests. Even with caching, 1GB VPS plans for WordPress frequently result in out-of-memory kills during normal operation.
Growing traffic: 20,000 to 100,000 visits per month
Recommended: 4 vCPU / 4–8 GB RAM / 80–120 GB NVMe SSD
This range benefits most from Redis object caching in addition to page caching. WordPress makes many small database queries on each request — WooCommerce sessions, transients, options table lookups. Redis keeps frequently-accessed data in RAM, reducing database load significantly.
At 4GB RAM you can run:
- Nginx + PHP-FPM (10–15 workers at ~50MB each = 500–750MB)
- MySQL (allocate 1–1.5GB)
- Redis (typically 100–300MB)
- OS and system processes (~400MB)
That leaves reasonable headroom for traffic spikes. At 8GB you have substantially more room and can increase PHP-FPM workers for higher concurrency.
High traffic: 100,000+ visits per month
Recommended: 6–8 vCPU / 8–16 GB RAM / 120+ GB NVMe SSD
At this scale, the architecture matters as much as raw resources. Consider:
- Separating the database to a dedicated database server (or managed database service)
- Adding a CDN to offload static assets and absorb traffic spikes
- Using Nginx FastCGI cache or a dedicated caching layer like Varnish
A single 8 vCPU / 16GB VPS with Redis and a CDN in front can handle significant WooCommerce traffic. Above this level, horizontal scaling (multiple application servers) becomes the more efficient path.
Storage planning
Storage requirements for WordPress are often underestimated, especially for sites with media-heavy content.
Estimate your storage needs:
- WordPress core + plugins + themes — typically 500MB to 2GB
- Media uploads — highly variable. A blog posting 3–5 images per article for a year might accumulate 10–30GB. A product catalog with high-resolution images can reach 100GB quickly.
- Database — a blog might be 50–200MB. A WooCommerce store with a year of order history can reach 2–10GB.
- Backup retention — if you are keeping 7 daily backups on the same server (not recommended long-term, but common for starting), multiply your data size by 7.
- Log files — Nginx and PHP-FPM logs can grow substantially on high-traffic sites without log rotation configured.
Rule of thumb: Start with a storage plan that gives you 30–40% headroom above your current usage estimate, accounting for 12 months of content growth.
Always use NVMe SSD for WordPress hosting. HDD storage causes database query latency that no amount of RAM or CPU compensates for, particularly for WooCommerce with complex queries.
Identifying your current bottleneck
If you are already running WordPress on a VPS and performance is degrading, these quick checks identify the constraint:
bash# Memory pressure free -h # If "available" is low or swap is in use, you're memory-constrained # CPU load uptime # Load average above your vCPU count means CPU is the bottleneck # Disk I/O iostat -x 1 5 # await > 10ms on your disk suggests I/O is a constraint # Active PHP workers ps aux | grep php-fpm | wc -l # Compare to pm.max_children in your pool config
High CPU + normal memory, no cache: PHP generating pages dynamically for every request. Enable page caching immediately — this is the highest-impact fix available.
High memory + swap active: Too many PHP-FPM workers configured, or a memory-hungry plugin is leaking. Check individual process sizes with ps -o rss= -C php-fpm8.3 and compare to your pool settings.
Normal CPU + normal memory + slow responses: Database query performance. Enable slow query logging in MySQL and review the output.
When to upgrade
Upgrade when at least two of these conditions are true for 5–7 consecutive days:
- CPU load average stays above your vCPU count during normal (not spike) hours
- RAM usage remains above 85% with swap in use
- Response time degrades noticeably despite caching being active
- Database query times are increasing without query changes
Single-day spikes from traffic events are not a signal to upgrade — they are a signal to investigate caching. Consistent multi-day resource pressure during normal operation is the real upgrade trigger.
Final recommendation
Start conservatively sized with proper caching configured before overprovisioning hardware. A 4 vCPU / 4GB VPS with Redis and Nginx FastCGI cache will outperform an 8 vCPU / 16GB VPS with no caching in almost every real-world scenario.
Monitor weekly. Upgrade based on trend data, not single-day spikes. And keep at least 30% resource headroom at your normal load level so traffic spikes do not immediately saturate your server.
Discussion
Have a question or tip about this topic? Share it below — your comment will appear after review.