Disclosure: This post contains affiliate links. If you buy through them, we may earn a commission at no extra cost to you.
Every growing site hits the same wall: the hosting that was fine last year is now the bottleneck. Shared, VPS, and dedicated aren’t good-better-best — they’re different tools with different crossover points. Here’s how to tell which one you actually need, and when to move.
What each one really is
Shared hosting puts hundreds of sites on one server. You get a control panel, no root access, and resources governed by “fair use” limits nobody can quote you. It’s cheap ($2–5/mo) because you’re renting a slice of someone else’s oversold box.
VPS gives you guaranteed virtualized resources and root on your own OS instance ($4–50/mo for the useful range). The hypervisor enforces your slice — your RAM is your RAM. You administer the box (or pay someone to).
Dedicated is the whole physical machine ($80–500/mo). No hypervisor, no neighbors, full hardware access. You also own every problem the hardware can invent.
| Shared | VPS | Dedicated | |
|---|---|---|---|
| Root access | No | Yes | Yes |
| Resources | Best-effort | Guaranteed slice | Whole machine |
| Typical price | $2–5/mo | $4–50/mo | $80–500/mo |
| Scaling | Upgrade tiers | Resize in minutes | Hardware change |
| Admin burden | None | Yours | Yours + hardware |
| Right for | Brochure sites, first blogs | Apps, growing sites | Sustained heavy load |
When shared hosting is fine
Stay on shared while all of this is true: traffic is modest (rule of thumb: under ~10k visits/month for WordPress), you’re not hitting CPU or process limits, page loads are acceptable, and you don’t need anything the panel doesn’t offer (custom PHP extensions, root cron, staging environments, non-PHP stacks). There’s no prize for running your own kernel on a site that gets 40 visitors a day.
Signals it’s time for a VPS
- Throttling notices — CPU seconds, process count, or I/O limits hit regularly. This is the host telling you to leave.
- TTFB over ~1s on cached pages, with the host blaming your (perfectly normal) plugins.
- You need root: custom software, Docker, a second database, Elasticsearch, anything the panel forbids.
- Staging: you want a prod clone to test changes. Doing that on shared is misery.
- Growth headroom: traffic doubling every few months. A VPS resizes in minutes; migrating under fire is how outages happen.
- Email deliverability: shared IPs get blacklisted by association. A VPS with proper SPF/DKIM/PTR is yours alone.
Sizing the VPS (don’t overbuy)
Start at 1–2 GB RAM for a typical site or app. Scale on evidence, not anxiety:
- Sustained load average above your vCPU count → more CPU.
- OOM kills or constant swapping → more RAM.
- High
%iowait→ faster disk (NVMe tier) before bigger box. - Slow queries with everything else healthy → database tuning, not hardware.
One decision to make early: managed vs. unmanaged. Managed VPS (or a panel like RunCloud/SpinupWP on top of an unmanaged box) costs more but keeps you out of 2 AM SSH sessions. A cPanel license alone runs ~$15–20/mo — factor that against just learning the CLI, which for a sysadmin audience is the right call anyway.
When dedicated actually makes sense
- Sustained CPU saturation — your VPS is pegged and the next VPS tier costs as much as hardware. The crossover is real: a 16 GB cloud VPS runs ~$80–96/mo, at which point a dedicated box with 32 GB+ is often cheaper per unit of compute.
- Compliance or data residency — some regimes want single-tenant hardware, not just a virtual slice.
- Noisy-neighbor intolerance — latency-sensitive workloads where even rare steal time is unacceptable.
- Special hardware — GPUs, large local NVMe arrays, custom networking.
What dedicated is not: a performance upgrade for a site that’s slow because of unoptimized queries. Fix the software first — it’s cheaper than hardware and the problem follows you to the bigger box otherwise.
Migration notes (the part people skip)
- Lower DNS TTL to 300 seconds 24–48 hours before the move, so cutover propagates fast.
- Sync files with rsync; dump the database with mysqldump (single transaction flag for InnoDB).
- Test before cutover: point the new box at your domain via your local
/etc/hostsand click through everything. - Cut over by updating DNS. Keep the old site live for a week as instant rollback — flipping DNS back is a five-minute undo.
- Watch the logs on the new box for 48 hours: 404s from missed files, cron jobs you forgot, hardcoded IPs.
The “unlimited” myth
Shared hosts love the word “unlimited” — unlimited storage, unlimited bandwidth, unlimited email. Read the terms of service and you’ll find the real limits: inode caps (often 200k–600k files, which a WordPress site with uploads and backups can genuinely hit), CPU-seconds per day, and clauses permitting throttling for “excessive resource usage” defined entirely at their discretion. “Unlimited” means “unmetered until we notice you.” A VPS with explicit quotas is more honest and usually more generous in practice.
Cloud vs. VPS: just terminology
“Cloud server,” “droplet,” “instance,” “compute” — in the $4–50 range these are all a VPS: virtualized slices on shared hardware. The word “cloud” adds marketing, not redundancy. As recent analyses have pointed out, neither Vultr nor Hetzner offers automatic host-failure failover — if the host node dies, your instance stays down until you restore from snapshot. True high availability (multi-zone, load-balanced, replicated data) is an architecture you build, not a product tier you buy. Don’t pay a premium for the word.
The database is the hidden migration cost
Files are the easy part of any migration; the database is where moves go wrong. Beyond dump-and-restore basics: verify character sets and collations match (utf8mb4 everywhere in 2026), confirm triggers, stored procedures, and scheduled events came across, and for large databases use a replica or incremental approach instead of one giant dump inside a maintenance window. After cutover, watch the slow query log for a week — a new MySQL version or a different I/O profile will surface queries that were “fine” before.
Containers change the math slightly
If your app runs in Docker, the VPS decision gets simpler: you care about a recent kernel, RAM, and disk — the distro and control panel matter less because your environment ships with the image. One caveat: some budget container-based VPS (increasingly rare, but still out there) share the host kernel and can’t run Docker at all. Confirm KVM or another full virtualization if containers are in your future.
When to skip the VPS and go managed
Not everyone should run their own box. If you have no interest in SSH, patching schedules, or 3 AM alerts — or if the site’s revenue would evaporate during the hours you’d spend learning — buy managed hosting or a managed VPS and spend the time on the business instead. A VPS is a tool for people who want control; it’s a liability for people who just want a website. Be honest about which one you are.
The decision framework
Ask in order: Am I hitting resource limits? No → stay. Yes → Do I need root or custom software? No → a bigger shared tier might do, but honestly a small VPS is usually cheaper and better. Yes → VPS. Then: Is the VPS pegged on sustained CPU, or do I need single-tenant hardware? Yes → dedicated. No → resize the VPS and move on.
Most sites that outgrow shared land on a $6–12 VPS and stay there for years. Dedicated is the exception, not the goal. And whatever you choose, revisit the decision annually — traffic patterns change, prices drop, and the right answer in 2026 may not be the right answer in 2028.