What hosting do you actually need for your traffic? A sizing guide

Forget the marketing tier names. Sizing your hosting is about concurrent connections, working set, database write throughput and the cost of being wrong. Here is the back-of-the-envelope calculation that fits almost every site.

The hosting industry has been very good at convincing people that "starter," "business" and "pro" tiers correspond to something real. They mostly do not. The right way to size a host is to work out what your site actually does under load, then pick the smallest box that absorbs the peak comfortably. The calculation takes about ten minutes and it almost always tells you that you are over-paying for capacity you will never use.

Start with concurrent visitors, not monthly traffic

Most hosting plans advertise "monthly bandwidth" and "monthly visits." Both numbers are mostly useless for sizing because they hide the only metric that matters: how many requests are happening at the same moment. A site with a million pageviews a month spread evenly is a fundamentally different load from the same million pageviews concentrated in two viral hours.

The honest number to start with is concurrent visitors at peak. For most small sites that have not yet had a marketing breakthrough, the peak is somewhere between 5 and 50 concurrent visitors. For a site getting modest organic traffic, 100 to 500 concurrent at peak is normal. For sites being actively promoted, 1,000 to 5,000 concurrent at peak is where things get interesting.

To convert monthly pageviews to peak concurrent, the rough rule is: take your monthly pageviews, divide by 1,000, and the result is roughly your peak concurrent. So 100,000 monthly pageviews gives you a peak of around 100 concurrent. A million monthly pageviews gives you around 1,000 concurrent at peak. Real distributions are messier than this, but the order of magnitude is right.

Concurrent connections, not concurrent visitors

A "visitor" is a person browsing the site. A "connection" is a single HTTP request. Modern pages make 30 to 100 requests just to render once, between HTML, CSS, JS, images, fonts and tracking. A site with 100 concurrent visitors making one page load every ten seconds is generating around 1,000 requests per second at the front edge.

The good news is that the static parts of those requests (CSS, JS, images, fonts) get cached by browsers and CDNs and never reach your server. The bad news is that the dynamic parts (HTML, API responses, authenticated content) do reach your server, and those are the ones that actually take CPU time and database queries.

The right number to size for is dynamic requests per second hitting your origin. For a typical content site behind a CDN, that is roughly 1 to 5 dynamic requests per second per 100 concurrent visitors. For an unauthenticated marketing site with aggressive caching, much less. For a logged-in application with personalised content, much more.

The working set is the memory you actually need

Hosting plans love to advertise RAM. The number that matters is your working set: the portion of your database, caches and application memory that is actively being read on every request. If your working set fits in RAM, the database serves from memory and your response times are milliseconds. If it does not, the database hits disk on every miss and your response times jump by an order of magnitude.

For a content site, the working set is roughly: the most popular ten per cent of your content (most reads concentrate on the top of the long tail), the schema and indexes, plus a hundred-megabyte runway for sort buffers and query workspace. A site with 10,000 published posts averaging 5 KB each has a content total of 50 MB; the popular ten per cent is 5 MB; the indexes are maybe 20 MB; the operating set is comfortably under 100 MB. A 1 GB VPS holds all of that with room to spare.

For an application with user accounts, the working set scales with active users rather than total users. A SaaS with 10,000 registered users where 500 are active in any given hour has a working set sized by those 500 users, not the full 10,000.

The matrix that fits most sites

Concrete sizing recommendations, written by working out the cheapest box that comfortably handles the load and rounding up one tier for safety margin.

Up to 10,000 monthly pageviews. Shared hosting or a 1 GB / 1 vCPU VPS. Anything you buy for under USD 5 a month will work. The bottleneck is not the host; it is your time configuring it.

10,000 to 100,000 monthly pageviews. A 1-2 GB VPS, USD 5 to 10 a month. Cache aggressively at the CDN, run the application and database on the same box, you will not notice the load.

100,000 to 1,000,000 monthly pageviews. A 4 GB VPS, USD 15 to 30 a month, with a CDN in front. Move the database to its own VPS if you want headroom. Real work begins here.

Over 1,000,000 monthly pageviews. Application server, dedicated database server, CDN in front, monitoring on everything. The hosting bill is no longer the largest line item; the engineering time is.

Three signals that you have undersized

If you find yourself in any of these positions, your host is too small for what you are doing:

• Page load times during peak hours are twice what they are at three in the morning.
• The host's CPU is consistently above 70 per cent during normal use.
• Database queries that returned in ten milliseconds last month return in a hundred this month, without you having changed the queries.

These are all symptoms of contention. The fix is either to remove the load (better caching) or to add capacity (a bigger box).

The trap of buying for the spike

The opposite mistake is buying for the spike you might one day have. A site averaging 200 concurrent visitors does not need a host sized for 5,000 just because Hacker News might find it on a Tuesday.

The right pattern is to buy for steady state plus a small margin, and have a plan for the spike. The plan is usually: a CDN in front to absorb the brunt, the ability to vertically scale the VPS in one click (most providers support this), and a willingness to take the hit on the rare day it happens. Over-provisioning for a spike that comes twice a year is cheaper paid by the spike than carried every day.

What this looks like in practice

The site you are reading right now serves several million pageviews a month from a single VPS that costs less than fifteen US dollars. Most of the heavy lifting is done by a CDN sitting in front; the origin only sees dynamic requests, which are a small fraction of the total. The database fits comfortably in RAM. The CPU sits at under twenty per cent during normal hours, peaks at sixty per cent during the busiest minute of the busiest day.

That is a sample size of one, but the pattern repeats across thousands of small to medium sites. Most operators are paying for capacity they will never use because the hosting page made the next tier up look like the responsible choice. The responsible choice is to size for what you actually do.