On a spec sheet a VPS and a VDS can look identical — same RAM, same NVMe, same root access. The difference is what happens to your CPU when the server gets busy, and that single distinction decides which one is right for you.
What a VPS actually is
A VPS (Virtual Private Server) is an isolated slice of a physical machine. You get guaranteed RAM and NVMe storage, your own operating system, root access and a dedicated IP. CPU cores, however, are shared: the hypervisor schedules several tenants across the same physical cores. For the overwhelming majority of workloads this is invisible — you get dedicated-grade performance for a fraction of the price of a whole server.
The shared-core model is why a VPS is such good value. You are paying only for the slice you use, and most of the time your neighbours are idle, so the full power of the core is available to you the instant you need it.
What a VDS adds
A VDS (Virtual Dedicated Server) looks like a VPS but reserves physical CPU cores for you alone. There is no overselling and no steal time — the small delay that appears when the hypervisor makes your workload wait because a neighbour is using the core. Your benchmarks stay flat whether the rest of the host is asleep or on fire. You pay more because nobody else can ever touch your cores.
Steal time: the hidden tax
“Steal time” is CPU time your virtual machine wanted but couldn’t get because the physical core was busy with another tenant. On a quiet host it is effectively zero. On an oversold host during a neighbour’s spike it can climb into the double digits — and for a few seconds your database queries slow down, your API p99 latency jumps, or your trading order executes a beat late. You can watch it yourself on Linux: the %st column in top or mpstat. If that number is regularly above zero and it is hurting you, that is the signal to move to a VDS.
VPS vs VDS at a glance
| VPS | VDS | |
|---|---|---|
| CPU cores | Shared (fair-scheduled) | Reserved for you |
| Steal time | Usually near zero, can spike | None by design |
| Performance consistency | Excellent on average | Flat under any load |
| Price per core | Lowest | Higher (you reserve the metal) |
| Best for | Most web and app workloads | Latency-critical, always-busy workloads |
When a VPS is the right call
- Websites, WordPress, WooCommerce, APIs, bots, staging and game servers.
- Workloads that are bursty rather than constantly pinned at 100% CPU.
- Early-stage products where best-in-class price-to-performance matters more than guaranteed consistency.
- Anything you can scale up later — on Scutex you can move from a VPS to a VDS without rebuilding.
When to step up to a VDS
- Production databases (PostgreSQL, MySQL, Redis) where steal time directly hurts query latency.
- Trading systems and MetaTrader EAs that must execute on time, every time — see our Forex VPS.
- CI/CD runners and ML inference that need predictable, repeatable build and response times.
- Real-time apps — video, VoIP, multiplayer — where a few seconds of jitter is visible to users.
A simple way to decide
Ask one question: would a few seconds of variable CPU, a few times a day, cost you money or breach an SLA? If yes, buy a VDS — the premium is cheap insurance against inconsistency. If no, a VPS gives you more machine for the same budget, and you can always upgrade when your workload outgrows it.
Most teams actually run both: a VDS for the database or trading engine that must never stutter, and cheaper VPS instances for the web tier, workers and staging. That mix gets you guaranteed performance exactly where it matters and low cost everywhere else.
How Scutex handles the upgrade path
You don’t have to get this right on day one. Start on a VPS, watch your steal time and tail latency, and if the numbers tell you the shared core is holding you back, move up to a VDS — same region, same data, no new IP. On Scutex that migration is free, so the cost of starting small is zero.