Every VPS provider sells the same four numbers, vCPU and RAM and disk and bandwidth, and those four numbers tell you almost nothing about whether the machine will be fast enough or the bill predictable.
The reason is that the numbers are not comparable across providers. Two vCPUs on one platform means two threads you share with strangers; on another it means two cores nobody else can touch. The price difference between those is roughly threefold, and the spec sheet describes them identically.
So the useful comparison is not a table of specs. It is a shorter list of questions the spec sheet does not answer, and a clear-eyed view of what you are signing up to maintain.
Table of contents
- Dedicated versus shared vCPU is the whole ballgame
- Storage, and the IOPS number nobody quotes
- Bandwidth is where the surprise bill comes from
- The question that actually decides it: who maintains the box
- A comparison checklist that survives contact with a sales page
- How this fits the rest of the stack
- FAQ
Dedicated versus shared vCPU is the whole ballgame
A vCPU is a scheduling abstraction, not a piece of silicon. On a shared or burstable plan, your vCPU is a slice of a physical core other tenants are also using. When they get busy, you wait.
That waiting has a name and a number. It is called steal time, and Linux reports it:
# The 'st' column is the percentage of time your vCPU wanted to run
# and the hypervisor gave the core to somebody else.
vmstat 1 5
# Same figure, per-CPU, with more context:
mpstat -P ALL 1 5Steal time under 1% is normal. Sustained double digits means your neighbours are eating your capacity and no amount of application tuning will fix it. This is the single most useful diagnostic on a cheap VPS, and it is the one thing you cannot see from the provider dashboard.
Burstable plans add a second layer: a credit balance that lets you exceed a baseline for a while. Run above the baseline continuously and the credits run out, at which point performance falls off a cliff, often days into a launch, which is the worst possible time to discover it. Read the baseline percentage, not the vCPU count.
Storage, and the IOPS number nobody quotes
Disk is where the difference between a fast VPS and a slow one usually lives, particularly if you are running a database.
The hierarchy is straightforward. Local NVMe is fastest, network-attached SSD is slower but survives the host failing, spinning disk should not be under a database in 2026. What providers rarely publish is the IOPS ceiling and whether it is throttled.
Measure it rather than trusting the description:
fio --name=randread --ioengine=libaio --direct=1 --bs=4k \
--iodepth=32 --size=1G --readwrite=randread --runtime=30 --time_basedThen ask the question the benchmark cannot answer: is that number sustained, or is it a burst allowance that decays? Some providers throttle after a period of sustained IO, which reproduces the burstable-CPU trap on a different axis.
Also check whether local storage is included in backups. On many platforms local NVMe is fast precisely because it is not replicated, which means a host failure takes your data with it.
Bandwidth is where the surprise bill comes from
Providers bill egress in three broadly different ways, and the difference between them at scale is enormous.
- Included allowance, then per-gigabyte overage. Predictable, and easy to model in advance. You need to know both the allowance and the overage rate.
- Metered from the first byte. Every gigabyte costs. Fine for low-traffic services, expensive for anything media-heavy.
- Unmetered or unlimited. Almost always means unmetered up to a port speed, with an acceptable-use policy that permits throttling. Read the policy, because the marketing word and the contract rarely agree.
Estimate before you commit. Average page weight times monthly views, plus any downloads, video or large API payloads. A 2MB page at 100,000 views is roughly 200GB a month, and the difference between a plan including that and a plan billing it can exceed the cost of the server itself.
Also check whether inbound traffic and traffic between your own machines is billed. Many providers charge for cross-region transfer between servers you own, which is exactly the kind of cost you do not think to model.
The question that actually decides it: who maintains the box
An unmanaged VPS is a rented Linux machine. Everything above the hypervisor is yours: OS patching, firewall, TLS certificates, backups, log rotation, monitoring, the web server config, the database, the restart-after-reboot story.
That work is not hard, but it is recurring and it does not stop. The realistic monthly commitment for one production VPS is a few hours if nothing goes wrong, and an unpredictable amount if something does. Multiply by the number of servers and decide honestly whether that is where your time should go.
Three questions that settle it:
- If this machine dies at 3am, who rebuilds it, and from what? If the answer involves remembering what was installed, you have a documentation problem before you have a hosting one.
- When a critical kernel vulnerability lands, who patches and reboots, and how fast?
- Do you have a restore you have actually tested, or a backup you have never read back?
A managed platform trades some control for those three answers being someone else’s problem. On RunxBuild you push a repository and get a build log, a live route, environment variables, runtime logs, metrics and a rollback to the previous deploy. That is a different product from a VPS, and for a lot of teams it is the one they actually wanted.
A comparison checklist that survives contact with a sales page
When you are down to a shortlist, these are the questions worth an email to support. The answers vary far more than the spec tables do.
- Is the vCPU dedicated or shared? If shared, what is the baseline and what happens when credits run out?
- What is the sustained IOPS figure, and is local storage replicated?
- What is the bandwidth allowance, the overage rate, and is inter-region traffic billed?
- Are snapshots included or billed separately, and are they automatic?
- Is there a live migration path to a larger plan, or does resizing mean rebuilding?
- What is the actual support response time on the plan you are buying, not the enterprise tier?
- Which regions, and can you move between them without a rebuild?
Then run a trial. Deploy something representative, load it, and watch steal time and disk latency for a week. A month of a small instance costs less than an afternoon of anyone’s time, and it answers questions no comparison table can.
How this fits the rest of the stack
Comparing providers on the sticker price of the instance is how a stack ends up costing three times the estimate, because the instance is rarely the whole bill. The database, the storage, the egress and the backups each add a line. The RunxBuild hosting calculator puts those together so the total is visible before you commit rather than after. The exercise is worth doing whichever way you go, including when the answer turns out to be a VPS somewhere else.
Useful related references:
- S3-Compatible Storage: The Providers and When to Use Each
- Private Methods in Python: There Are None, and That Is Fine
- Backup as a Service Providers: What to Look For, What to Skip, How to Choose
- Services on RunxBuild
FAQ
What is the difference between a VPS and cloud hosting?
A VPS is a fixed slice of a physical server, billed monthly, that you administer yourself. Cloud hosting usually means the same virtualisation with elastic scaling, finer-grained billing and managed services layered on top. The practical difference is that a VPS is a machine you maintain, while a cloud platform is a set of services you configure.
How many vCPUs do I actually need?
Fewer than you think for most web applications, and the honest answer comes from measurement rather than estimation. Start small, watch CPU utilisation and steal time under real traffic, and resize. Two dedicated vCPUs handle a surprising amount of ordinary web traffic; two shared ones may not.
Is unmetered bandwidth really unlimited?
No. It generally means unmetered up to the port speed, governed by an acceptable-use policy that permits throttling or contact from the provider if your usage is unusual for the plan. It is a reasonable offer for typical workloads and not a licence to serve video at scale.
Should I choose a managed VPS or manage it myself?
It depends on whether server administration is work you want to own. Self-managed is cheaper in money and more expensive in attention, and the attention cost is recurring rather than one-off. If nobody on the team wants to be on call for kernel patches and certificate renewals, that is a real signal.
How do I know if my VPS neighbours are affecting performance?
Watch steal time. Run vmstat with a one-second interval and read the st column: it is the percentage of time your vCPU was ready to run but the hypervisor scheduled another tenant. Under 1% is fine, sustained double digits means contention that no application tuning will fix.