Published: 03.10.2026
Choosing a VPS size is easier when you start from the workload rather than from a plan name. This article shows how to estimate CPU, memory and disk for a website, a database or a small application, and how to recognise the signs that a server is too small. Our LP-Series servers come in configurations such as 2 vCPU with 4 GB RAM and 40 GB disk, or 4 vCPU with 8 GB RAM and 80 GB disk, and the client area graphs show how your own server uses them.
Start from the workload
Write down what the server must do: how many visitors you expect at busy times, which applications run on it, whether a database is involved and which background jobs run, such as backups or imports. A static site needs far less than a store with search, sessions and checkout. Two applications with the same visitor count can behave very differently, depending on their code and queries, so the description of the work matters more than any plan name.
Estimating by type of workload
These rough categories help with a first guess. Treat them as a starting point and adjust once you see real numbers.
- Static or simple site: little CPU, modest memory, and disk sized for the files and any local backups.
- Dynamic site with a content management system: enough memory for the application, the database and the cache together, plus enough CPU to generate pages at busy times.
- Database-heavy application: memory is the key resource, because the database caches data in memory, and disk speed matters for writes.
- Application with background jobs: reserve capacity for jobs that run at the same time as visitors.
Memory before CPU
On small servers, memory often runs out before the processor does. When memory is short, the system swaps data to disk, and every process slows down. Measure memory use under normal load and at the busiest hour. Leave room for the operating system, the web server, the database and any cache. If the server swaps regularly, add memory before you add processor power.
Disk: size and speed
Disk needs come from your files, your database, logs and any backups kept locally. Keep a safe margin of free space, so that logs and temporary files can still be written. Speed matters for databases and for applications that handle many small files. If the disk runs close to full, clean up first and then decide whether to add space. Extra volumes can be added in the client area.
Signs that you need to upgrade
- Memory is almost always full, and swap usage keeps growing.
- The load average stays above the number of cores during normal working hours.
- Disk use climbs steadily, and cleanup no longer frees enough room.
- Page response times grow with traffic, even after caching and code fixes.
- Backups start to overlap with the busiest hours of the day.
Fix the cause before you upgrade
Not every slowdown needs more hardware. Look for slow database queries, unoptimised images, plugins that run on every request and jobs that run too often. Measure after each fix. If the numbers improve, the bigger configuration may not be needed yet. If they do not, the upgrade is a decision supported by data.
Plan the change
Keep the usage graphs from the client area, so that a decision to move to a larger configuration rests on weeks or months of data rather than on one bad afternoon. Choose a size that covers the next period with some margin. Schedule the change in a quiet window and take a snapshot beforehand, so that you can return to the previous state if needed.
Frequently asked questions
Is it better to overprovision? Some spare room helps with peaks, but large unused capacity wastes resources. Base the size on measured data and a sensible margin.
What if I cannot predict traffic? Start with a moderate configuration, measure for a few weeks and adjust with data. Watch the graphs closely during launches and campaigns.
Do CPU cores matter more than memory? For most small websites, memory limits come first. Processor power matters for heavy computation, image processing and many simultaneous requests.
