The right VPS size is the smallest configuration that can run your real workload through normal demand and expected peaks without sustained CPU, memory, storage or network pressure. You cannot calculate that from monthly visitors alone.
A cached brochure site, a WooCommerce store, an API and a server running dozens of client sites can receive the same number of visits and need very different resources. The difference is how many requests arrive together, how much work happens at the origin, what the database must do, which jobs run in the background and how much headroom the business needs.
If you are still deciding whether to move off shared hosting, settle the shared hosting versus VPS question first. Once VPS is the right tier, use this method to choose a sensible starting point and a safer upgrade path.
Start with the workload, not the plan card
“A WordPress site” is not a sizing description. A mostly cached five-page company site and an uncached membership site with logged-in users are both WordPress, but they place different pressure on PHP workers, the database, memory and storage.
Write down everything the VPS will run:
- web server, runtime and database;
- control panel and management agents;
- websites, applications, APIs and admin dashboards;
- search, cache and queue services;
- email, DNS or other services if they will share the server;
- backups, malware scans, imports, reports and scheduled jobs;
- staging sites, development containers and anything people forget is still running.
Then describe the busiest realistic period, not the monthly average. A South African store may be quiet most of the week and busy after payday, during Black Friday or when a promotion lands. An application portal may peak just before a deadline. An agency server may have many low-traffic sites but still launch backups, updates and scans at the same time.
Use this VPS sizing worksheet
Complete the worksheet before comparing providers. If the workload already exists, attach measurements. If it is new, label estimates as assumptions and plan a staging load test.
| Question | What to record | Why it changes the size |
|---|---|---|
| What runs on the VPS? | Operating system, panel, web stack, database, sites, apps, containers and scheduled services | Every resident service consumes baseline memory, CPU time, storage and operational attention |
| What does one busy request do? | Cached file, PHP/runtime work, database reads/writes, search, API calls, image processing or report generation | Dynamic and personalised requests cost more than cache hits or static files |
| How much arrives together? | Normal and peak concurrent requests, sessions, workers, admin users or jobs | Concurrency creates simultaneous demand; monthly visitor totals hide it |
| How does caching behave? | Page/object cache coverage, cache hit rate, bypass rules and logged-in traffic | Cache hits can avoid origin work; misses and bypassed pages still reach the application and database |
| What does the database do? | Database size, active data, slow queries, connection count, write volume and peak query latency | Database pressure can appear as CPU, memory or storage latency depending on the query and data path |
| What happens in the background? | Backups, imports, exports, scans, cron tasks, queues, image work, reports and deployment jobs | Background jobs can collide with customer traffic even when visitor numbers do not change |
| How much data is stored? | Files, databases, logs, mail, local backups, temporary files and expected growth | Capacity must include growth and working space, not just today's visible website files |
| How demanding is storage? | Read/write latency, IOPS, throughput, queueing and whether access is random or sequential | A disk can have free space and still be the performance bottleneck |
| How much data moves? | Origin requests, average response size, downloads, uploads, backups and monthly transfer | Transfer allowance and port speed answer different questions from CPU and RAM |
| What change is coming? | Campaigns, new sites, product imports, more staff, software changes, data growth and seasonal peaks | Headroom should cover a known next step, not an undefined fear of growth |
| How can the VPS be upgraded? | Resource options, lead time, reboot or downtime, storage constraints, rollback and support owner | A modest starting size is safer when expansion is understood and tested before a peak |
What each VPS resource actually solves
vCPU: processing and parallel work
Virtual CPUs handle application code, database work, encryption, compression, image processing and every other compute task on the server. More vCPUs can help when useful work is waiting for CPU and the software can run tasks in parallel.
They do not guarantee a faster site. One slow database query, a blocked external API call, lock contention or a saturated disk can leave extra CPU capacity idle. Compare CPU pressure with request latency, runnable work and the process or service consuming time before buying more cores.
RAM: active working space
RAM holds the operating system, control panel, web workers, database buffers, caches and active application data. Too little memory can force the server to reclaim cache, swap or terminate processes. Too much does not automatically improve an application that has no useful data to keep in memory.
List each resident service, watch memory pressure during a peak and find out whether usage is stable, workload-driven or leaking over time. “Free RAM” on its own is a weak signal because operating systems also use available memory for cache.
Storage capacity: files plus working room
Add databases, media, application files, logs, mail if hosted locally, temporary files and any backups stored on the VPS. Then include known growth and enough working room for updates, exports and maintenance. Do not count an off-server backup as live disk capacity, and do not treat a local copy as an independent recovery plan.
Storage performance: IOPS, throughput and latency
Capacity tells you how much fits. Performance tells you how quickly the storage completes work. Small database reads and writes, large sequential backups and many queued operations stress storage differently. Watch latency and queueing alongside IOPS and throughput; “NVMe” on a feature list is not a measurement of your application's experience.
A database-heavy workload may feel slow while CPU remains available because requests are waiting on storage. In that case, extra vCPUs can leave the real bottleneck untouched.
Transfer and bandwidth: total data versus delivery rate
Monthly transfer is the amount of data moved over the billing period. Bandwidth or port speed describes how quickly data can move at a moment in time. Estimate origin transfer from uncached requests and response sizes, then add uploads, downloads, remote backups, software updates and replication where relevant.
A CDN or well-configured cache can serve eligible content without sending every request to the origin, but personalised pages, checkout, admin traffic and cache misses still need server work. Measure origin traffic after caching instead of assuming every page view has the same cost.
Match the VPS to the workload shape
Use these patterns to decide what deserves attention. They are not plan recommendations.
| Workload shape | Likely pressure points | Questions that matter |
|---|---|---|
| Cached company or content site | Origin cache misses, admin work, media storage and scheduled maintenance | How much traffic bypasses cache? Do backups, scans or imports cause the slow period? |
| WooCommerce or member site | Concurrent dynamic requests, PHP/runtime workers, database latency and third-party calls | What happens at checkout or login peaks? Which pages cannot be shared-cache hits? |
| Agency or multi-site server | Aggregate baseline RAM, noisy sites, control-panel services, backups, updates and storage growth | What is the combined peak? Can one site or maintenance job affect every client? |
| Application or API with a database | Request concurrency, connection pools, query work, cache behaviour, queue workers and external dependencies | Where does request time go? Which work is synchronous and which can move to a queue? |
| Automation, import or reporting server | Short CPU bursts, memory held by workers, disk throughput and overlapping schedules | Can jobs be staggered or limited? Must they finish during customer-facing peaks? |
| Media or download workload | Storage growth, outbound transfer, port speed and origin offload | Should large files live on the VPS? What can a CDN or object-storage design serve separately? |
Buy for the combined workload, not the most flattering description of one site. If you are comparing shared, WordPress and VPS options for several business workloads, the South African business hosting guide keeps that broader tier decision separate from this sizing method.
Measure before you move when data exists
If the site or application already runs somewhere, collect a representative history that includes ordinary days and known peaks. Record CPU utilisation and pressure, memory pressure and swap, disk use and growth, read/write latency, I/O queueing, network transfer, request rate, concurrent work, application response time, error rate and database health.
Do not read each graph alone. Correlate them:
- Did customer-facing latency rise at the same time as CPU pressure?
- Did memory pressure or swapping appear before processes failed?
- Did database latency rise while storage requests queued?
- Did a backup, scan, import or report overlap the incident?
- Did the origin slow down, or was the wait inside a payment, email or other external service?
For a new workload, build a staging environment that resembles production and test realistic user journeys. Increase concurrent work gradually, watch the whole stack and note the first constraint. A synthetic test is evidence for that tested build and scenario, not a promise that every future plugin, query, campaign or content mix will behave the same way.
Diagnose the constraint before upgrading
| What you observe | What it may mean | Check before buying more resources |
|---|---|---|
| Repeated CPU pressure during slow requests | Useful compute is saturated, too much work runs together, or code/queries are inefficient | Top processes, request traces, slow queries, worker limits, cache misses and background jobs |
| Memory pressure, swap activity or killed processes | The active working set is too large, a service is mis-sized or memory is leaking | Per-service use, database buffers, worker counts, cache size and whether usage grows without falling |
| High storage latency or persistent I/O queueing | The workload is waiting on disk performance rather than capacity | Read/write pattern, IOPS, throughput, backup overlap, database queries and storage limits |
| Disk almost full | Capacity or retention is the immediate risk | Logs, local backups, temporary files, mail, database growth and safe cleanup/retention rules |
| Transfer allowance or link saturation becomes the limit | Too much data is moving, or too much must move at once | Origin versus cached traffic, large files, backup transfers, response sizes and delivery design |
| Application is slow while server resources remain comfortable | The bottleneck may be code, a query, lock, remote API, DNS or another dependency | Application traces, database plan, external-service timing, errors and recent releases |
A larger VPS can buy headroom. It cannot repair an unindexed database query, a broken cache policy, plugin bloat, a stalled payment gateway or a job that should not run during the traffic peak. Fix obvious inefficiency, then size the remaining useful workload.
Plan the upgrade before the server is busy
Choose an upgrade signal for each resource and write down who acts. The signal should combine repeated resource pressure with business impact, not one isolated spike. Also confirm:
- whether vCPU, RAM and storage can be changed independently;
- whether a resize needs a reboot, maintenance window or migration;
- whether storage can be expanded but not reduced;
- how long the change usually takes and who has access to approve it;
- what backup, validation and rollback steps apply;
- how the application will be checked after the resize.
Leave headroom for a named reason: an expected campaign, another client site, known data growth or an operating task that overlaps the peak. Do not pay indefinitely for an undefined “just in case” buffer, and do not run a revenue-producing site at the edge of its measured capacity simply because the average looks low.
South African buying checks that are not CPU or RAM
A bigger VPS does not shorten a long network path. If most users are in South Africa, test real response times from the networks and devices they use. Separate origin processing time from network latency, DNS, third-party scripts and cache delivery before treating server size as the answer.
Compare the full operating cost in Rand. An overseas price can move with exchange rates, while a local invoice may be easier to budget; neither fact proves better performance. Check transfer charging, control-panel or management costs, backup options and the cost of the next realistic upgrade without inventing a perfect long-term size today.
Finally, match support and management to the people who will run the server. Resource graphs are only useful when somebody can interpret them and act during the business's real peak. If your team does not operate servers, include the management boundary in the buying decision rather than spending the entire budget on hardware.
