How to Choose the BEST VPS Explained

Once you've decided a VPS is the right move, how to choose a VPS comes down to sizing four things to your workload: CPU, RAM, storage, and bandwidth. Start small and measure. A typical small site or app runs comfortably on 1 to 2 vCPUs, 2 to 4 GB of RAM, and SSD or NVMe storage, then you scale the one resource that runs out first. Most people overbuy. The right size is the one that handles your load with a little headroom, and nothing more.

This guide assumes you've already settled the type question. If you haven't, the pillar on which hosting type is best for small websites and the breakdown of VPS vs cloud hosting vs dedicated cover that, and what a VPS is covers the basics. Here we size the box you've chosen, spec by spec, with a rule of thumb for each and the signs you picked too little or too much.

How many vCPUs does a VPS need?

Most small workloads need 1 to 2 vCPUs, and you add cores only when CPU is the thing that runs out. A vCPU (virtual CPU) is a share of a physical processor core assigned to your server. More cores help when work runs in parallel: many concurrent requests, background jobs, video encoding. They do little for a single slow task.

Two distinctions matter. Shared vCPUs draw from a pool other customers also use, which is cheaper and fine for bursty, average-load work like a typical website. Dedicated vCPUs reserve capacity for you, which costs more and earns its keep for steady high-CPU work like databases under constant query load.

The tell that you're sharing a busy host is CPU steal time, the percentage of time your virtual CPU waits for a physical core because the hypervisor is busy serving another VM. As one engineer on Hacker News put it, high steal time "is strong indication you are being ripped off CPU" (Hacker News). Check it with top or vmstat and read the st column.

• Rule of thumb: start with 1 to 2 vCPUs for a small site or app. Move to dedicated cores when CPU is consistently your bottleneck.
• Too little: CPU usage sits above 80 percent during normal traffic, requests queue, or steal time is persistently high.
• Too much: average CPU sits in the low single digits and never climbs under load. You're paying for cores that idle.

How much RAM does a VPS need?

Plan for your working set plus headroom, not the bare minimum. RAM holds your running processes and caches. A small WordPress site with caching is fine on 1 to 2 GB, a growing app or a small database is happier at 4 GB, and anything running multiple services wants 8 GB or more. The number you want is enough to hold normal load with room to absorb a spike.

Headroom is the part people skip. An app that uses 90 percent of its RAM at rest has nothing left for a burst, and that's when it falls over. Independent sizing guides put the same practical floor on it: for a small WordPress site under roughly 20,000 to 30,000 pageviews a month with caching, 1 vCPU and 1 to 2 GB of RAM is usually enough, with 4 GB the common next tier as you grow (Launchcodex).

Swap is the safety valve, not the plan. Swap is disk space the system uses as overflow when RAM fills. A small swap file (often 1 to 2 GB, or up to the size of your RAM) stops a brief spike from killing a process, but a server that swaps constantly is slow, because disk is far slower than memory. Use swap as a cushion, then add RAM if you lean on it.

• Rule of thumb: size RAM to your normal working set plus 30 to 50 percent headroom. Add a small swap file as a cushion.
• Too little: memory sits above 90 percent, the kernel starts killing processes (the OOM killer), or the server swaps heavily under load.
• Too much: gigabytes sit free and unused at peak, with no caching or workload that would ever claim them.

SSD or NVMe, and how much storage?

Pick storage on three axes: type, size, and IOPS. For type, prefer SSD over spinning disk, and prefer NVMe when your work is disk-heavy. NVMe (a faster way to connect flash storage than the older SATA interface) handles far more small random reads and writes, which is exactly what databases do. For size, count your data plus the OS plus room to grow, and leave 20 percent free.

The performance gap is large and worth knowing before you pay for it. Benchmarks put NVMe roughly an order of magnitude ahead of SATA SSD on IOPS (input/output operations per second, the count of small reads and writes a disk handles each second). At the queue depths databases work at, NVMe delivers on the order of hundreds of thousands of IOPS where SATA SSD tops out far lower (ServerMania). For a static site or a small app that mostly serves cached pages, SSD is plenty. For a database under load, NVMe is where the difference shows up.

Size is the easy part, with one rule: never run a disk near full. Filesystems slow down and some databases misbehave as they approach capacity. Total your application, OS image, logs, and backups, then add margin.

• Rule of thumb: SSD for general use, NVMe for databases and I/O-heavy work. Size to your data plus OS plus 20 percent free.
• Too little: the disk crosses 80 percent used, write latency climbs, or a database stalls on reads it can't serve fast enough.
• Too much: you provisioned for years of growth you can't yet measure, on storage that bills monthly whether it's full or not.

How much bandwidth and what about egress fees?

Match bandwidth to your transfer, and read the egress terms before you commit. Bandwidth is how much data your server moves, usually measured as a monthly transfer allowance plus a port speed (the link's maximum rate). Most VPS plans bundle generous transfer, often measured in terabytes, which covers ordinary sites easily. The cost that surprises people is egress: the per-gigabyte fee some providers charge for data leaving the server.

Two different billing models hide here. Flat-allowance plans give you a monthly transfer bucket and a slower or overage rate after, which is predictable. Metered plans charge per gigabyte of egress, sometimes with steep markups and no hard spending cap, so a traffic spike or a misconfigured backup can become a surprise bill. Neither is wrong, but they fail in different ways, and the metered model is the one that bites without warning. If you pick a metered plan, find the egress rate and whether you can set a spending limit.

• Rule of thumb: estimate monthly transfer as average page weight times pageviews, then double it for headroom. Confirm the overage or egress rate before you buy.
• Too little: you blow through the allowance mid-month and either get throttled or billed for overage.
• Too much: you're paying for a terabyte tier while serving a few gigabytes a month, which is common and usually harmless, but worth checking.

Where should your VPS be located?

Put the server near your users, because location sets your floor on latency. Latency is the round-trip delay between a user and your server, and physical distance is a hard part of it: data crosses the country in tens of milliseconds and an ocean in a hundred or more, and no plan upgrade removes that. If your audience is mostly in one region, host in that region.

Location also decides data residency, where your data physically lives. Some industries and customers require data to stay in a specific country, so check that before you pick a city. For most small projects the rule is simple: choose the region closest to the people who use the site, and think about multiple regions only when you have measurable traffic in more than one place.

• Rule of thumb: host in the region where most of your users are. Add a second region only when traffic elsewhere justifies it.
• Too far: users in your main market see slow first loads no amount of CPU fixes.
• Over-distributed: you're running and paying for servers in regions with almost no traffic.

Should you choose managed or unmanaged?

Decide honestly whether you want to be the system administrator. An unmanaged VPS is cheaper and hands you everything: OS updates, security patching, firewall config, and troubleshooting at 2 a.m. when something breaks. Managed hosting does that work for you for a higher price. Neither is better in the abstract, it depends on your skills and how you want to spend your time.

This choice interacts with the OS. On unmanaged plans you typically pick a Linux distribution (Ubuntu and Debian are common, well-documented defaults), and you own keeping it patched. Pick the OS you or your team already know, because the time you save on familiar tooling outweighs small technical differences between distributions. Managed hosting, including what we offer at Carpathian, narrows that surface for you, which is worth paying for if you'd rather not run a server you're not comfortable running, and not worth it if you enjoy the control.

• Rule of thumb: unmanaged if you're comfortable administering Linux, managed if you'd rather not. Choose the OS you already know.
• Sign you chose wrong: an unmanaged box sits unpatched for months, or you pay a managed premium for a server you'd happily run yourself.

What about snapshots and backups?

Keep an off-site copy you control, and don't treat the host's snapshot feature as your safety net. A snapshot is a point-in-time image of your server, fast to take and fast to restore, which makes it ideal for rolling back a bad deploy. It is not a backup, because it usually lives on the same provider as the server it protects. If the provider has a bad day or suspends your account, the snapshot goes with it.

This is the most repeated piece of advice in hosting horror stories, and it predates the cloud. "ALWAYS make backups," one administrator wrote on Hacker News. "If a provider goes deadpool on you all of the sudden, you should always have fresh backups in a remote site" (Hacker News). Use snapshots for quick rollbacks and keep an independent, off-site backup for the day the provider itself is the problem.

• Rule of thumb: snapshots for fast rollback, plus an automated off-site backup you can restore without the provider's help.
• Too little: your only copy of the data lives on the same account as the server.

Why does overselling change how you size?

Because the specs on the page are a ceiling, not a guarantee, and a busy host won't deliver them. Hosts sell more capacity than they physically have, betting not everyone uses it at once. This is normal and universal: "Every provider oversubscribes," one administrator noted, because they "do not expect and cannot handle 100% utilization by their subscriber base" (Hacker News). The degree varies, and that variance is what you're buying.

So two VPS plans with identical specs can perform very differently. Catch it by measuring after you provision: watch CPU steal, run a quick disk benchmark, and check whether performance matches the brochure. If steal time is high or disk IOPS come in far below the tier's claim, you picked a crowded host, and the fix is a different provider, not a bigger plan.

How do you size your VPS?

Run these steps in order and you'll land on a size that fits.

1. Identify your workload. Static site, dynamic app, or database-heavy? That sets which spec matters most: CPU and RAM for apps, IOPS and NVMe for databases, bandwidth for media.
2. Start small. For most small projects, 1 to 2 vCPUs, 2 to 4 GB RAM, and SSD or NVMe storage is a sensible floor. Resist the urge to round up.
3. Pick storage by IOPS, not just size. NVMe for databases and write-heavy work, SSD for general serving. Leave 20 percent free.
4. Check the bandwidth model. Confirm the transfer allowance and, on metered plans, the egress rate and any spending cap.
5. Choose the region nearest your users, and confirm any data residency requirements.
6. Decide managed or unmanaged by your own comfort with Linux, and pick an OS you know.
7. Set up off-site backups on day one, independent of the host's snapshots.
8. Measure for a week, then adjust. Watch CPU steal, RAM headroom, disk usage, and transfer. Scale up the one resource that runs out, and scale down anything that never moves.

The honest limitation worth keeping: you can't size perfectly up front, because you don't yet know your load, so the goal isn't a perfect first guess. The goal is a small, well-instrumented start you can adjust with one click. The best infrastructure tends to be the kind you stop thinking about: sized for what you run, easy to grow, and priced for what you use.