Sizing a VPS: CPU, memory and NVMe without overbuying

Start with the workload, not a package card

Describe what the server must do: How many people use it concurrently, which jobs run on a schedule and which peaks are business-critical? A small web service, large database and modded game server consume resources differently. Without this picture, every sizing recommendation is guesswork.

CPU: separate core count from per-core speed

Parallel workers can use more cores, while one dominant process benefits more from fast individual cores. Check whether builds, backups or scheduled jobs run alongside the main application. Keep some headroom, but do not permanently buy capacity for a peak that can be moved to another time.

Memory: operating system, application and cache

Add the realistic needs of all services and reserve room for the operating system and filesystem cache. Databases often use spare memory effectively, while a leak eventually fills any package. Observe the trend over representative days. Sustained swap activity under load is a warning sign, not the desired operating state.

Storage: capacity is only one dimension

Estimate data, backups, logs and temporary files separately. Databases and small random writes respond to I/O latency, while archives depend more on throughput and capacity. Keep free space so updates, logs and maintenance do not fail on a full filesystem.

Start lean, measure well and grow predictably

• Choose a baseline with sensible safety margin.
• Monitor CPU, memory, I/O and response times together.
• Confirm which resources can grow without reinstalling.
• Update the baseline after major application changes.

Compare fixed server packages and current capacity in the server exchange. If uncertain, run your workload on a 24-hour test server.