Most small and medium websites need somewhere between 5GB and 20GB of storage; media-heavy sites, ecommerce catalogs and anything storing large user uploads or local email typically need 30GB to 100GB or more. The number people actually get wrong is not the gigabyte count, though - it is treating storage, bandwidth and inodes as the same resource, and taking ‘unlimited storage’ plans at face value when nearly all of them cap the real constraint, the number of individual files, at a fixed figure regardless of what the plan page says about gigabytes.
This covers how to size storage honestly, what SSD and NVMe actually change, why unlimited plans are bounded anyway, how storage differs from bandwidth as a separate resource entirely, and where backups and media should live instead of the app’s own disk.
Table of contents
- Sizing storage honestly
- SSD versus NVMe, and when the difference matters
- The unlimited storage myth
- Storage and bandwidth are not the same resource
- Where media and backups should actually live
- Persistent storage on a modern platform
- How this fits the rest of the stack
- FAQ
Sizing storage honestly
A text-heavy site - a blog, a documentation site, a brochure site with a handful of images - rarely exceeds a few gigabytes even after years of posts, because text and typical web images are small; the code and dependencies (a Node app’s installed packages, a Python app’s virtual environment) usually take up more disk than the content does. The number climbs fast once a site stores original-resolution photography, video, large PDFs, or user-generated uploads at scale, which is where the 30GB-to-100GB-plus range in most sizing guides comes from.
The practical way to size it is to measure, not guess: check the actual disk usage of a comparable existing site, add the size of a full database export if the database lives on the same disk, and multiply by whatever growth rate makes sense for the content type. Guessing high to be safe on a plan with a hard cap just means paying for headroom that sits empty; guessing low means a migration under pressure later.
It is worth separating the application’s own footprint from the content it serves when doing this math, because they grow at very different rates. A codebase and its dependencies tend to plateau once a project stabilizes; the content directory - uploads, generated exports, a growing database - is the part that climbs steadily over the life of the site, and it is the part worth sizing for the next year rather than for today.
SSD versus NVMe, and when the difference matters
SSD storage beats spinning disk enough that HDD is no longer a meaningful comparison for hosting in 2026 - the real comparison today is SATA SSD against NVMe, which connects over a faster bus and delivers meaningfully higher throughput and lower latency for the same workload. A backup that takes well under a minute on NVMe can take several times longer on SATA SSD, and the gap widens under concurrent load - many small database reads and writes at once, which is exactly the access pattern a busy website’s database produces.
Where this actually matters: a database under real concurrent traffic, or any workload doing lots of small random reads and writes, feels the NVMe difference directly. A mostly-static site serving the same handful of images repeatedly barely notices, because a CDN or the browser cache is doing most of the serving work before the origin disk’s speed becomes relevant at all.
This is also why a plan’s storage speed is worth checking against what actually runs on the disk, not just against the site’s traffic level. A low-traffic site with a database doing frequent writes - a queue table, session storage, an analytics pipeline logging every request - can be more disk-bound than a high-traffic static page, because the bottleneck is the pattern of access rather than the raw visitor count.
The unlimited storage myth
‘Unlimited storage’ is real in the narrow sense that no hosting provider actually measures your gigabytes against a cap - and misleading in the sense that nearly every such plan caps the number of individual files, called inodes, at a fixed figure regardless of their total size, commonly cited in the 150,000-to-250,000 range for shared hosting plans. A million tiny cache files or a large WordPress install with heavy image processing can hit that ceiling while using a small fraction of the storage unlimited implied.
The tell is in the fair-use language most of these plans carry in the fine print: unlimited paired with a clause about normal use, personal use, or the right to suspend an account using disproportionate resources. A plan advertising an unbounded number is describing a marketing position, not a technical one - the actual limit is just measured in a different unit than the one on the pricing page.
Storage and bandwidth are not the same resource
Storage is how much data sits on disk at rest. Bandwidth is how much data transfers out to visitors over a period, typically a month, and the two scale independently - a 2MB page viewed by ten thousand visitors moves roughly 20GB of bandwidth in a month while using only 2MB of storage the whole time. Confusing the two is why ‘do I have enough storage’ is often the wrong question when a site’s real constraint is actually monthly transfer, especially for anything media- or video-heavy with meaningful traffic.
For static sites specifically, bandwidth is usually the number worth watching rather than storage: RunxBuild’s static hosting includes 120GB of bandwidth, then $0.10/GB beyond that, which is a separate line from however many gigabytes the built site itself occupies on disk.
Where media and backups should actually live
The instinct to store everything on the same disk as the application - uploaded images, generated PDFs, database backups - works until the app needs to scale past one instance, or the disk fills, or a redeploy wipes an ephemeral filesystem that was never meant to be permanent storage in the first place. Object storage (an S3-compatible bucket) is the standard answer for user uploads and media: it scales independently of the app, survives a redeploy, and is usually cheaper per gigabyte than attaching more disk to a compute instance.
Database backups deserve the same treatment - stored somewhere other than the disk the live database runs on, on a schedule, with more than one retention point, which is the whole subject of database backup strategy done properly. A backup that lives next to the data it backs up is not a backup against the failure mode - disk loss - that backups exist for.
Persistent storage on a modern platform
The framing that actually matches how storage gets used in practice is per-service, not per-plan: a web service needs a persistent volume attached to it for whatever it writes to disk beyond its own code - uploaded files, a local cache, anything that should survive a redeploy - and that volume is sized and billed separately from the service’s compute plan. Persistent storage attaching to a service this way means resizing storage independently of resizing compute, instead of buying a bigger VPS just because the disk filled up.
This also sidesteps the inode-limit problem from earlier: a volume attached to a service is sized by gigabytes the way it is billed, without a shared-hosting-style cap on file count hiding underneath the number on the page. Resizing it later is an operation on the volume, not a plan migration for the whole service, which is the difference between a five-minute change and an afternoon of downtime planning.
How this fits the rest of the stack
The honest sizing exercise is smaller than most unlimited marketing implies, and the resource actually worth watching is usually bandwidth, not disk. The RunxBuild hosting calculator breaks storage, bandwidth and compute out as separate lines rather than folding them into one vague unlimited promise, so a plan can be sized against what a site actually uses instead of a marketing ceiling nobody checks.
Useful related references:
- Persistent Storage in 2026: When Your App Needs to Outlive Its Container, and How to Stop Finding Out at 3 a.m.
- Bandwidth Calculators: How Pooled Allowances and Overage Actually Work
- VPS SSD Storage: What You’re Actually Getting, When It Matters, When It Doesn’t
- Storage on RunxBuild
FAQ
How much storage does a typical website need?
Most small to medium sites - blogs, brochure sites, documentation - use somewhere between 5GB and 20GB, since text and typical web images are small; the code and its dependencies often take up more disk than the content. Media-heavy, ecommerce or upload-heavy sites commonly need 30GB to 100GB or more.
Is NVMe storage actually faster than SSD for hosting?
Yes, meaningfully so under real workloads - NVMe connects over a faster bus and handles concurrent small reads and writes, the pattern a database under traffic produces, noticeably faster than SATA SSD. A mostly-static site serving cached content through a CDN sees far less benefit, since the origin disk does less of the work.
Is unlimited hosting storage actually unlimited?
In gigabytes, functionally yes for most sites; in practice, nearly every unlimited plan caps the number of individual files, called inodes, at a fixed figure, commonly in the 150,000 to 250,000 range, and carries fair-use language allowing suspension for disproportionate use. The limit exists, just in a different unit than advertised.
What is the difference between storage and bandwidth in hosting?
Storage is how much data sits on disk at rest; bandwidth is how much data transfers to visitors over a period, typically a month. A small page viewed by many visitors can use far more bandwidth than storage, so the two need to be sized separately rather than assumed to track each other.
Where should website backups and media files be stored?
Not on the same disk the live application runs on. Object storage suits user uploads and media because it scales independently and survives a redeploy; database backups belong on a separate schedule and location from the live database, specifically so a disk failure cannot take out both the data and its backup at once.