Shared, VPS, dedicated or cloud? Choosing the right tier for your traffic

There are four basic ways to rent a computer on the internet. They differ in one thing that matters more than all the specifications combined: who else is on the machine, and what happens to you when they get busy.

The four tiers, honestly described

Shared hosting

One physical server, hundreds or thousands of customer accounts, one operating system. You get a folder, a database and a control panel. Resource limits are enforced loosely, so a neighbour's traffic spike or badly written plugin slows your site, and a neighbour's compromised account is one privilege-escalation bug away from yours. It costs almost nothing because the provider is dividing one machine's cost by a thousand.

Right for: brochure sites with no revenue dependency and no traffic to speak of. Wrong for: anything that takes orders, runs campaigns or stores customer data.

VPS (virtual private server)

One physical server, split by a hypervisor into a handful of virtual machines, each with its own operating system and a guaranteed slice of CPU, memory and disk. Neighbours exist but they cannot see your files and they cannot consume your allocated resources. The important fine print is whether the vCPUs are dedicated or shared: shared vCPU plans are oversold and will throttle under sustained load; dedicated vCPU plans will not.

Right for: the large majority of business websites, stores and applications, from launch to many hundreds of thousands of visits per month. Wrong for: workloads that need a whole machine's memory bandwidth or specific hardware.

Dedicated server

One physical machine, one customer. No hypervisor, no neighbours. You get all of the hardware and all of the responsibility, including when a disk fails. Provisioning takes hours or days rather than seconds, and scaling means ordering another machine.

Right for: very high sustained traffic, large databases, licensing that is priced per physical core, or compliance regimes that forbid shared hardware. Wrong for: almost everyone else; a well-run VPS tier gets you most of the benefit with far better flexibility.

Cloud infrastructure

Technically still virtual machines, but provisioned through an API, billed by the hour, and surrounded by managed services: load balancers, managed databases, object storage, auto-scaling groups, multiple regions. The unit of thinking is no longer "a server" but "an architecture". The cost is complexity and, at the hyperscalers, a bill that is very hard to predict.

Right for: applications that need redundancy across machines, elastic scaling, or specific managed services. Wrong for: a single website; you will pay cloud prices for VPS performance.

Sizing from numbers instead of adjectives

You need three numbers, and you can get all of them from your analytics and your current host in ten minutes.

1. Peak concurrent users. Not monthly visits. Look at your busiest hour in the last 90 days and take the number of users active at once. For most small businesses this is between 5 and 50 even when monthly visits are in the tens of thousands.
2. How dynamic each page is. A cached page served from a CDN costs the origin almost nothing. A logged-in dashboard, a search, a cart, costs real CPU and database time on every request. Estimate the share of requests that cannot be cached.
3. Your largest regular spike. A newsletter send, a campaign launch, a mention in the press. Estimate the multiple over normal peak. Three to ten times is common.

Then apply a rough rule that has served us well: a well-configured 2 vCPU / 4 GB VPS behind a CDN handles around 50 concurrent users on a mostly cached WordPress or similar site with headroom to spare. Double the dynamic share and you roughly halve that. Double the spike multiple and you want the next size up, or a CDN configured to absorb it. A 4 vCPU / 8 GB dedicated-vCPU server covers the large majority of businesses up to a few hundred concurrent users, which translates to a very busy store.

Five signs you have outgrown your tier

1. Time-to-first-byte above 600 ms at normal load. The server is spending too long thinking before it answers. On shared hosting this is often the neighbours; on a VPS it is usually missing caching or an undersized database.
2. Slowdowns that correlate with nothing you did. Your traffic was flat, the site crawled anyway. That is a neighbour. Only isolation fixes it.
3. Memory alerts or "502 Bad Gateway" during campaigns. The application server is running out of workers or RAM under spike. Resize, or fix caching, before the next send.
4. You are afraid to update things. No staging environment, no rollback, so updates are postponed, so the site becomes insecure. That is a tooling problem that shared hosting cannot solve and a managed VPS does by default.
5. A single machine failing would stop the business. If a hardware fault means hours of downtime and a restore from backup, you have crossed into needing redundancy: a load-balanced pair, a separate database node, a tested failover. That is the point where "cloud" becomes the right word.

What we do about this

Our plans map onto this directly. Core is an isolated 2 vCPU / 4 GB container behind a CDN, which is the right starting point for most single sites. Scale is a dedicated 4 vCPU / 8 GB server with staging and a managed database, for businesses that are actively acquiring customers. Ecosystem is the load-balanced, multi-node architecture for the fifth sign above. The hosting page has the full specification table.

If you are not sure where you sit, the free audit measures your time-to-first-byte, cache hit rate and peak concurrency from public data and tells you which tier the numbers actually point at. Sometimes it is a smaller one than you are paying for now.