Dedicated server vs cloud VPS: which one fits the workload, and what each really costs

The core difference

A cloud VPS is a virtual machine on a host shared with other tenants. You get a defined number of vCPUs and gigabytes of RAM, provisioning in about a minute, per-minute billing, and the ability to destroy and recreate at will. A dedicated server is a physical machine assigned only to you: the CPU, memory channels, NVMe drives and network port are not shared, provisioning takes longer, and billing is monthly. Everything else — cost per unit of performance, latency consistency, scaling model — follows from that one distinction. CPU Cloud covers the first; Dedicated Servers the second.

Side by side

Cost: compare months, not hours

VPS pricing is expressed per hour or minute; dedicated pricing per month. To compare, multiply the VPS rate by about 730 hours. The smallest CPU Cloud plan is roughly $6.47 per month always on; as plans grow the per-unit price of RAM and vCPU stays roughly linear, so large VPS instances become expensive relative to a dedicated machine with the same memory. Dedicated servers start at $87 per month on the Server Auction, where older but fully functional configurations are listed without a setup fee. The current lines and their starting prices are read from the catalog:

The crossover is typically around 16–32 GB of RAM and 8 vCPUs: above that, a dedicated server gives more cores, more memory and local NVMe for a similar or lower monthly figure, provided you use it all month.

Performance: the noisy neighbour problem

On a VPS, a vCPU is a scheduling share of a physical core, and your disk I/O queues behind other tenants. For an I/O-bound API that waits on an LLM endpoint this rarely matters. For a database doing random reads, a vector index under load, or an inference server where tokens per second translate directly into user latency, it matters a great deal: p99 latency on shared hardware is wider and less predictable. Dedicated hardware removes the variance. The AX line pairs AMD EPYC cores with NVMe; the EX line uses Intel Xeon with ECC memory; the GPU line adds data-centre GPUs for self-hosted inference at a fixed monthly cost rather than per minute.

Scaling and failure

VPS wins on elasticity: resize or add nodes in minutes, destroy them when traffic drops. Dedicated servers scale by adding machines and do not resize live, so you size for the ceiling. Failure modes differ too: a VPS host failure is recovered by recreating the instance from an image; a dedicated server failure means a hardware swap. Both argue for the same architecture: stateless API nodes on VPS that can be recreated, stateful services on dedicated machines with backups and, for critical systems, a replica on a second machine.

Which workloads go where

• VPS: API gateways and AI backends, CI runners, staging and preview environments, cron and queue workers, anything you create and destroy.
• Dedicated: PostgreSQL and other primary databases, vector stores with large indexes, object/backup storage (SX line), self-hosted LLM inference (GPU line) with steady traffic, and compute-heavy batch systems that run all month.
• Either: Redis and small caches, monitoring stacks, internal tools; choose by how much state they hold.

A combined stack

A representative production layout for an AI product: two CPU Cloud nodes behind a load balancer for the API, a dedicated AX server for PostgreSQL with pgvector on NVMe, and model calls going to the hosted inference API until traffic justifies a GPU server. Each layer is on the hardware class that suits its state and load profile, and the bill is the sum of a fixed monthly database server plus per-minute API nodes that scale with use. The dedicated servers guides cluster goes deeper on the auction and on database sizing.

Migrating from VPS to dedicated without a cut-over weekend

Most teams start on cloud servers and move the stateful parts to dedicated hardware once the profile is clear. The low-risk path is replication first, promotion second: provision the dedicated machine, restore the latest backup, set it up as a streaming replica of the production database, and let it catch up while the VPS keeps serving. Once replication lag is zero and you have verified a few reports against both, switch the application's connection string, promote the replica, and demote the old primary to a replica for a week in case you need to go back.

Pick the dedicated configuration with headroom for 12–18 months, since it cannot be resized; auction listings on the Server Auction often provide that headroom at a lower monthly price than a new build. Keep the API tier on CPU Cloud nodes so the two layers can scale independently.