Webspace Hosting: An Old Word for a Constraint That Moved

Webspace is the amount of disk a host gives you for your files. It is a real term with a precise meaning, and it describes a constraint that stopped mattering roughly fifteen years ago.

If you are comparing hosting plans and the first number they lead with is webspace in gigabytes, you are reading a plan written around the wrong limit. Disk is the cheapest thing in a datacentre now. What actually decides whether your site is fast, stays up, and can grow is a different set of numbers, and the plans that lead with webspace often say the least about them.

What webspace means
Why disk stopped being the limit
The numbers that actually decide performance
Working out how much space you actually need
What webspace hosting does not include
Choosing on the right axis
How this fits the rest of the stack
FAQ

What webspace means

Webspace is storage allocated to you on a web server for the files that make up your site: HTML, images, stylesheets, scripts, and on many plans your email and database files as well. The term is a direct translation of the German Webspace and is common across European hosting; in North America the same thing is usually called disk space or storage.

There is nothing wrong with the word. It names something real, and knowing how much you have is genuinely useful when you are storing uploads or serving a media library. The problem is that it became the headline metric on shared hosting plans at a time when a gigabyte was expensive, and it stayed there long after it stopped being the binding constraint.

For context on the scale involved: a typical WordPress installation with its themes and plugins is a few hundred megabytes. A well-optimised static site is often under fifty. A plan advertising 100GB of webspace is offering you two orders of magnitude more than a normal site uses, which is a generous way of telling you nothing.

Why disk stopped being the limit

Three things moved at once. Storage got dramatically cheaper per gigabyte. Images moved to formats that are a fraction of the size at the same quality. And the heavy media that used to fill a disk moved off it entirely, onto video platforms and object storage.

What replaced disk as the constraint is contention for everything else on a shared machine. Your site is one of many on that server, and what actually slows it down is CPU time, memory, the number of PHP processes you are allowed to run at once, and the number of simultaneous database connections. Those are the numbers that decide whether your site survives a busy afternoon.

They are also the numbers that are hardest to find on a plan comparison page, which is not a coincidence. Disk is easy to advertise because it is a single honest number. Concurrency limits are awkward to advertise because they are the thing that makes cheap shared hosting cheap.

The numbers that actually decide performance

When comparing plans, these tell you more than webspace does, roughly in order of importance.

Memory available to your processes. The hard ceiling on what you can run. If PHP or your application exceeds it, requests fail rather than slow down.
CPU allowance, and whether it is shared or dedicated. A fractional vCPU that is genuinely yours behaves very differently from a share of a machine you compete for.
Concurrent process or worker limits. On shared hosting this is often the real cap on traffic. Twenty simultaneous visitors against a ten-process limit means ten of them are queued.
Database connection limits. Frequently a separate and lower limit than you expect, and the cause of connection errors that look like the application is broken.
Bandwidth allowance and the rate beyond it. Unlimited usually means until we notice. A stated allowance with a clear per-gigabyte rate afterwards is more honest and easier to budget.
Whether you can run a process at all. Some plans serve PHP and static files and nothing else. If you will ever need a Node service, a background worker, or a scheduled job, this decides whether the plan has a future.

A plan that publishes these is telling you what it is. A plan that leads with unlimited webspace and unlimited bandwidth is telling you about its marketing.

Working out how much space you actually need

Since it is still worth knowing, here is the arithmetic. Four components, and one of them dominates.

The application. A content management system with themes and plugins is a few hundred megabytes. A static build is tens of megabytes. Framework code is small.
The database. Usually smaller than people expect. A blog with a thousand posts is measured in tens of megabytes of text.
User uploads and media. This is the one that grows without limit, and the only component whose size depends on how long the site has been running rather than what it is.
Backups, if they are stored on the same disk. A full backup is the size of everything above, and keeping several means multiplying it.

For nearly every site the answer is that media is the whole story. If your project will accumulate images, price storage separately and plan to put them in object storage rather than on the application’s disk, where they are simpler to serve, easier to back up, and do not disappear when the application is redeployed.

And if backups are on the same disk as the thing they are backing up, they are not backups. That is the one storage decision genuinely worth getting right.

What webspace hosting does not include

The term describes storage, and a plan sold on storage often quietly leaves out things a working site needs.

A build step. Modern sites are usually built from source rather than uploaded as finished files. A plan that only offers file upload means running the build yourself and uploading the output every time.
Deploy history and rollback. If deployment is copying files over the previous ones, a bad deploy is not undoable and there is no record of what changed.
Runtime logs. When something fails, you want to see the failing request. Many storage-shaped plans give you little more than a generic error log.
Anything long-running. A worker, a queue consumer, a scheduled job, or an application that keeps a connection open. Shared webspace serves requests and ends.
Meaningful isolation. Sharing a machine means sharing its problems, including the ones caused by a neighbour.

None of that matters for a brochure site that changes twice a year, and that is a genuinely fine use of cheap shared hosting. It matters the moment the site becomes something you deploy rather than something you upload.

Choosing on the right axis

A simple decision rule that avoids the whole comparison problem.

Files only, no server-side code. You want static hosting, where the constraint is bandwidth rather than disk and the deployment is a build from your repository. This is both cheaper and faster than shared webspace for the same site.
A content management system you will not extend. Managed hosting for that specific platform, where the operator handles updates and you get file and database access without SFTP.
Anything that runs your own code. An application host with a stated memory and CPU allocation, environment variables, logs, and a database beside it. Storage is a line item here rather than the headline.

For that third case on RunxBuild, a service builds from a GitHub repository with build logs, a live route, runtime logs, and rollback to a previous deploy, on a ladder starting at $4 for a Dev plan and $6 for Basic, with persistent storage attached separately when you need it. Static sites come with 120GB of bandwidth included and $0.10 per gigabyte after that. In neither case is disk space the number that determines what you pay, because it is not the number that determines what you get.

How this fits the rest of the stack

The reason the terminology matters is that it steers the comparison. Shopping on webspace leads you to plans that compete on the cheapest resource in the building, while the things that decide whether your site is quick and reliable go unmentioned. Shopping on compute, memory, database, and bandwidth leads you to plans that have to state what they are. The RunxBuild hosting calculator is built around that second list, with the service, the database, the storage, and the bandwidth as separate line items, which makes it straightforward to compare against a shared plan and see what the difference actually buys.

Useful related references:

FAQ

What is webspace in web hosting?

Webspace is the disk storage a host allocates to you for your website’s files, and often for its email and database as well. It is a common term in European hosting and equivalent to what is elsewhere called disk space or storage. It measures one real thing, but not the thing that usually limits a site’s performance.

How much webspace does a website need?

Far less than most plans offer. A typical content-managed site with themes and plugins is a few hundred megabytes; a static site is often under fifty. The only component that grows without bound is user-uploaded media, which is better kept in object storage than on the application’s disk.

Is webspace the same as bandwidth?

No, and they are frequently confused. Webspace is how much you can store; bandwidth is how much data leaves the server as visitors load your pages. A small site can use very little storage and a lot of bandwidth if it is popular or serves large images, and bandwidth is far more likely to be the number that costs you.

What should I compare instead of webspace?

Memory available to your processes, CPU allowance and whether it is shared, concurrent process and database connection limits, the stated bandwidth allowance and the rate beyond it, and whether the plan can run a long-lived process at all. Those decide performance and headroom; disk almost never does.

Is shared webspace hosting still worth it?

For a small site that changes rarely and runs no code of your own, yes. It stops being the right choice when you need a build step, deploy history, runtime logs, a background worker, or predictable resources, because shared plans are built to serve requests and end rather than to run your application.