Disk is the specification people over-buy. It is the easiest number on a plan card to understand, so it gets used as a proxy for how serious the plan is, and the result is a great many sites paying for storage they will never fill while sitting at a processor ceiling they hit every evening. Working out the real figure takes about five minutes and replaces the guess with a number.
Measure before you estimate
If the site already exists somewhere, you are not estimating, you are reading. In cPanel, the disk usage page breaks the home directory down by folder, which immediately shows whether the answer is the website, the mailboxes or something nobody meant to leave there. On a server, du -sh * inside the web root and again on the mail directory gives the same answer in two commands. The database size is on the front page of phpMyAdmin.
If the site does not exist yet, add three numbers: what the application weighs on disk, what you expect to publish in two years, and a margin. Then stop, because the third number is where the over-buying happens.
What a site is actually made of
- The application. A content management system with a theme and a couple of dozen plugins, or a framework application with its dependencies installed, is usually a few hundred megabytes before a single page has been published. It is a fixed cost, it does not grow much, and it is rarely the thing that fills an account.
- The database. Almost always the smallest item, and almost always the one people expect to be the largest. Text is extraordinarily cheap to store. Tens of thousands of articles of prose is still measured in tens of megabytes unless something is logging into a table and never clearing it, which is worth checking, because that is the one way a database does run away.
- Images. This is where the space goes. A photograph straight off a camera or a phone is several megabytes, and the same picture resized to the width the page actually displays is a small fraction of that. WordPress compounds it by generating several sizes of every upload, so one careless photograph can land as six files. An image library that was never resized on the way in is the single most common reason an account is full.
- Video. Do not host it on a hosting account. A few minutes of video outweighs everything else on the account put together, and storage is not even the real objection: serving video well is a different job from serving a website, and a video platform does it for nothing.
- Mail. On cPanel the mailboxes live in the same home directory as the site, so they count against the same figure. A mailbox nobody has emptied since 2019, with every attachment anyone ever sent still in it, is a routine discovery when an account fills unexpectedly.
- Things that should not be there at all. A copy of the site in a folder called
old, three archives from three migrations, a log file nothing rotates, and a cache directory that grew because nothing ever prunes it.
Figures that are usually honest
- A brochure or small business site, text and a few dozen properly sized images: 1 GB is roomy.
- A blog publishing weekly with photographs: 2 to 4 GB covers several years, if the images are resized on upload.
- A shop with a few thousand products and photographs of each: 10 to 50 GB, almost all of it images.
- Anything serving video or large downloads: stop estimating. Measure the files, because they are the answer and nothing else on the account is close.
Our own plans line up with that shape rather than against it. The shared hosting plans run 1, 2 and 4 GB on NVMe, which is the brochure and small blog range. The business plans run 20, 50 and 100 GB, with more processor and memory beside them, because an account that genuinely needs 50 GB of storage is usually an account that needs more than two cores as well. The figures are on the plan, with the renewal price next to the first-term price, so the comparison is the one you will actually be paying.
Headroom without buying the plan twice
Take the measured figure, double it, and buy that. Doubling covers two or three years of normal publishing for most sites, and if you are wrong, moving up is handled as a request against the existing service rather than as a new order, so the account is not rebuilt underneath you. Moving to a larger plan covers how that is filed. Buying ten times what you measured is not caution, it is paying now for a guess about 2032.
When you are nearly full
- Resize the image library. On most accounts this alone ends the conversation.
- Empty the mailboxes, or at least the one with fourteen years of attachments in it.
- Delete the copy of the site you kept "just in case" after the last migration.
- Move video to a video platform and embed it.
- Then, and only then, buy more space.
One warning while you are in there. An archive of the site kept on the same account is a copy, not a backup: it fails in exactly the situation a backup exists for, and in the meantime it is occupying the storage you are trying to free. Keep it somewhere that is not the thing it protects.
Why running out hurts more than it should
A full disk does not politely refuse the next upload and carry on. Sessions cannot be written, caches cannot be written, the database cannot write its own temporary files, and a site that was merely out of space starts returning errors that look like something much worse. Watch the figure at 80 percent rather than at 100, which gives you an afternoon to deal with it rather than an evening.