TL;DR / Summary: Start with one vCPU and 2 GB RAM for low-traffic WordPress or static stacks; scale when swap thrash or queue latency appears. Compare plans and specs on virtualserversvps.com using workload notes, not headline discounts alone.
What actually consumes VPS resources
Static HTML barely touches CPU. WordPress with plugins, cron, and admin sessions eats RAM first. Docker on the same box adds daemon overhead. MySQL or MariaDB wants buffer pool memory; starving it pushes disk I/O spikes that feel like “slow CPU.”
Measure before upsizing. htop, free -h, and slow query logs tell truth; marketing “unlimited” does not.
Baseline tiers that usually work
- Brochure site + blog: 1 vCPU, 2 GB RAM, NVMe storage
- WooCommerce light: 2 vCPU, 4 GB RAM, tuned PHP-FPM pool
- Multiple small sites: 2–4 vCPU, 4–8 GB RAM, separate PHP pools per domain
Burst-friendly hosts tolerate short spikes; sustained 100% CPU means upgrade or optimize images and queries.
vCPU count vs clock
Two slow cores lose to one fast core for single-threaded WordPress admin. Background jobs (backup plugins, search indexers) benefit from a second core so admin UI stays responsive. Match core count to concurrent workers you configure—not to visitor count alone.
RAM formula for PHP-heavy stacks
Estimate: (max PHP-FPM children × average PHP process MB) + 512 MB for OS + database cache target. If product is 80 MB and you allow twenty children, you need far more than 2 GB unless you cap children aggressively.
Object caching (Redis) adds maybe 100–300 MB but saves repeated DB hits—often cheaper than doubling RAM without cache.
When to add a second VPS
Split database and web when nightly backups overlap peak traffic, or when one rogue plugin crashes PHP pools for every domain on shared hosting. A tiny DB-only VPS with 2 GB dedicated to InnoDB can stabilize a busy storefront still on single-core web tier.
Monitoring triggers for upsize
Sustained swap use, PHP max children reached messages, MariaDB “cannot allocate buffer pool” warnings, or mail queue backlog during campaigns—all signal right-size plan change. Capture a week of graphs before paying for idle cores.
Cost discipline
Annual prepay saves money only if the size fits six months of growth. Right-size monthly first quarter, then commit. Document chosen specs in runbooks so teammates do not reboot into wrong instance types after provider maintenance.
Compare with intent
Open Virtual Servers VPS with your stack written down—CMS, plugins, expected concurrent admins, backup window—and pick the smallest tier that leaves 20% RAM headroom at peak, not at idle.
Storage and IOPS matter too
RAM fixes many WordPress woes, but cheap spinning disks choke on plugin updates. NVMe or SSD tiers often beat adding a second vCPU for admin UX. Monitor iowait alongside memory pressure.
Network egress surprises
Media-heavy sites hit bandwidth caps before CPU limits. Include CDN or object storage in architecture instead of endlessly upsizing VPS network packages.
Managed vs unmanaged tradeoff
Unmanaged VPS assumes you patch OS kernels. Managed tiers cost more but shrink time-to-recovery after CVE drops. Size RAM for workload plus patch reboot headroom.
Snapshot before resize
Providers allow vertical scale with reboot. Snapshot or backup immediately before change so rollback beats frantic support tickets if database service fails to start on new tier.
Security baseline RAM
Fail2ban, ModSecurity, and ClamAV scans consume cycles and memory. Budget 256–512 MB above pure app estimate if running full stack on one VPS. Undersized security tooling gets disabled “temporarily” and forgotten.
Automated backup agents streaming to object storage spike RAM during compression—schedule backups off peak or accept larger tier.
Staging parity rule
Staging VPS should match production RAM within one tier, not one-sixteenth size—bugs that appear only under load waste Friday nights. Clone production plugin set, not just theme.
Log rotation disk
Verbose debug logs fill disks before RAM maxes. Size storage and logrotate policy alongside memory; runaway logs mimic “mystery slowdowns” misdiagnosed as CPU.
Support escalation data
When opening provider ticket, attach htop screenshot, free output, and PHP pool config. Right-size requests get faster answers than “server feels slow.”
Database on same box
Small teams run MySQL on web VPS for cost. Separate innodb_buffer_pool_size from PHP memory in spreadsheet—both compete for same RAM bar. If pool starved, add RAM before second vCPU.
Future microservice split
Even if monolith today, size VPS allowing one extra service container later—API worker or Redis—without immediate second machine. Headroom avoids emergency 2 a.m. migration when feature flag flips.
Upgrade drill quarterly
Every ninety days replay load test against staging at production tier. Traffic grows gradually; scheduled review catches need before Black Friday panic upsize with untested tier.
Revisit sizing after major plugin installs—backup plugins and search indexers often arrive quietly and consume RAM you did not budget on launch day.
Right-sized VPS feels boring until the night you are not awake fixing a down site—that is the goal.