When a VPS stops being enough
A VPS is the right answer for a great many workloads. These are the symptoms that say yours is no longer one of them.
The four symptoms
- Steal time. Run
topand look at%stin the CPU line. That is time your virtual machine wanted the processor and the hypervisor gave it to somebody else. Anything consistently above a few percent means you are queueing behind other tenants. - Benchmarks that never repeat. The same disk test gives 400 MB/s in the morning and 90 MB/s in the evening. Nothing in your machine changed; the machines around it did.
- Latency spikes with no cause. Your 99th percentile response time has spikes that do not correlate with your traffic, your deploys or your queries.
- You are paying for headroom you never get. Burstable CPU credits, IOPS allowances, bandwidth add-ons — when the extras cost more than the base, the model has stopped working for you.
What bare metal actually changes
You get the whole machine. No hypervisor between you and the hardware, no other tenant on the disks, no scheduler deciding whether your process runs now or in four milliseconds. The performance you measure on Tuesday is the performance you get on Saturday night, because nothing else is moving.
Specifically: all of the cores all of the time, the full memory bandwidth, direct access to the NVMe queues, and a network port that is yours rather than a share of somebody's uplink. See what unmetered actually means for why that last one matters more than most people expect.
What it does not change
You are still responsible for everything above the hardware — see what unmanaged means. A dedicated server does not make bad queries fast, and it will not rescue an application that is bound by something other than the machine. Measure before you move: if your database is slow because it is missing an index, bare metal buys you a faster version of the same problem.
The honest comparison
A dedicated server usually costs more per month than the VPS you are leaving, and less than the three VPSes you were about to buy to spread the load. The crossover comes sooner than most people think, because a single machine with no virtualisation overhead and local NVMe does work that takes several cloud instances to match.
It is also simpler. One machine to patch, one to monitor, one set of logs. A lot of complexity in small infrastructures exists purely to work around the limits of the instance underneath.
How to decide in an afternoon
- Record your current load: requests per second, CPU, memory in use, disk IOPS and latency, bandwidth.
- Note the ceiling you keep hitting. There is usually exactly one.
- Ask us for a quote that clears that ceiling with room to spare. Describe the workload rather than a parts list — we build to order and we will say plainly if the thing you asked for is the wrong shape.
- Move one component first, usually the database, and measure again.
Migrating in covers the move itself, and how much server you actually need covers the specification.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base