How many vCPUs and how much RAM does a server need?
There is no single answer to this question, but there is a single way to find it: measure which resource is actually limiting you first. The most common mistake when a server slows down is adding vCPUs, and for most workloads that changes nothing.
vCPU: core count, or per-core performance?
The critical distinction is whether your workload parallelises.
Some workloads spread work across multiple cores — a web server, a PHP-FPM pool, several game server processes. Adding cores genuinely helps there.
Other workloads do their main work on a single thread. Buying 16 cores instead of 4 produces no measurable gain; what decides is the clock speed and IPC of that one core.
| Workload | What decides | Do more vCPUs help? |
|---|---|---|
| FiveM / RedM (CitizenFX) | Single-core performance | No, nothing beyond 3-6 vCPU |
| Minecraft (Java, vanilla) | Single-core performance | Partly, tails off past 4-6 |
| MySQL / MariaDB | Memory + storage latency | Up to a point |
| Nginx + PHP-FPM | Concurrent request count | Yes |
| alt:V | Networking and streaming threads | Yes |
| Multiple CS 1.6 servers | Process count | Yes, 3-4 servers per core |
| Video encoding | Total cores | Yes, close to linear |
The practical rule: on single-threaded work, upgrade the processor family; on parallel work, add cores.
RAM: how the calculation works
A RAM estimate has three components:
- Baseline — the operating system and always-on services. 0.5-1 GB on Linux, 2-3 GB on Windows Server.
- The application's fixed cost — the resource list and assets on a game server, code and caches in a web application.
- The per-unit variable — the part that grows with connected players, concurrent requests or open sessions.
Example: for a 64-slot FiveM server, a Linux baseline of 1 GB, 6 GB for the resource list and streamed assets, 50 MB per player × 64 = 3.2 GB, and 2 GB for MySQL gives roughly 12 GB. That runs comfortably on a 16 GB plan and sits at the limit on 8 GB during peak hours.
Do not rely on swap. Swap turns the moment memory runs out into a slowdown rather than a crash; it is insurance, not a solution. A game server paging to disk is already unusable for its players.
Storage: latency matters more than capacity
Most people look at GB when choosing storage, yet for most workloads the problem is latency rather than capacity. The gap between NVMe and SATA SSD is a matter of percentages on sequential reads but multiples on small random reads — and database queries are precisely small random reads.
Things to keep in mind:
- Growth is permanent. World saves, MySQL binlogs, backups and log files do not shrink back.
- Backups take space. If you keep backups on the same machine, size storage at 1.5x.
- Shrinking storage is not supported. Because it risks data loss, most providers (Datafex included) only grow storage. Picking comfortable headroom up front is easier than migrating later.
What should drive an upgrade decision?
Measure these before growing the hardware:
- CPU: in
top, is a single core pinned at 100%, or is load spread across cores? If it is the former, adding cores is wasted. - Memory: what is
availableinfree -mat peak? If it drops below 500 MB, RAM really is short. - Storage:
%utilandawaitiniostat -x 1. Ifawaitclimbs into milliseconds, storage is the bottleneck. - Application: is the slow query log on? Often the hardware is fine and a single unindexed query is holding up the whole server.
An upgrade made without measuring these four usually means spending the right money in the wrong place.
Where to go next
We have written separately about how resource sharing affects performance: What is a VDS and how does it differ from a VPS?
If you are building a game server, we have compiled RAM, vCPU and storage guidance per game by player count: game server plans. For general use, you can pick each resource and see the monthly total instantly: virtual server plans.