Resource Limits & Real Capacity Five-provider research
Web Hosting Resource Limits Compared
The advertised number of websites is only one ceiling. Real shared-hosting capacity can be constrained first by file count, storage, databases, CPU, RAM, I/O, PHP concurrency, process controls, or provider fair-use rules.
Hostinger and Namecheap currently publish the clearest multi-metric shared-resource tables in this five-provider review. SiteGround publishes detailed fair-use CPU and inode thresholds. Bluehost exposes some hard limits but has conflicting current inode documentation, while DreamHost publishes clear site and storage tiers without one simple low-level resource table. Compare only like-for-like metrics.
Five-provider resource disclosure matrix
Compare the metric—not just the marketing label.
“Unlimited websites,” “ideal visits,” PHP workers, entry processes, CPU seconds and inode limits describe different constraints.
| Provider / shared context | Website / storage disclosure | Inodes | CPU / RAM disclosure | PHP / process disclosure | What to verify |
|---|---|---|---|---|---|
| HostingerWeb Single / Premium / Business | 1 / 3 / 50 sites; 10 / 20 / 50 GB | 200k / 400k / 600k | 1 / 1 / 2 CPU cores; 1 / 2 / 3 GB RAM | 20 / 40 / 60 PHP workers; I/O also published | Live hPanel limits and plan availability |
| BluehostCurrent shared lineup | Starter currently 10 sites / 10 GB; Business 50 sites / 50 GB | Official docs conflict: 200k max article vs 50k soft / 1m ToS article | No single normalized public shared CPU/RAM table used here | No single public PHP-worker count used here | Your portal’s current limits and support guidance |
| DreamHostLaunch / Growth / Scale | 25 / 50 / 100 sites; 25 / 50 / 100 GB | Defined by plan, but reviewed public overview does not expose a simple figure | CPU/RAM shared; process monitor can constrain heavy use | Process-based controls; shared PHP default memory documented separately | Panel usage plus current support guidance |
| SiteGroundStartUp / GrowBig / GoGeek | 1 / unlimited / unlimited sites; 10 / 50 / 100 GB | 200k / 400k / 600k | CPU-second thresholds; up to 768 MB RAM per process | No simple public PHP-worker count in reviewed fair-use source | Fair-use thresholds and account Statistics |
| NamecheapStellar / Plus / Business | 3 / unlimited / unlimited domains; 20 GB / unmetered / 50 GB | 300k / 300k / 600k | 50% / 50% / 100% CPU; 1 / 2 / 2 GB RAM | 20 / 30 / 40 entry processes; 50 MB/s I/O | Do not treat entry processes as PHP workers |
Seven resource limits that can matter before traffic gets large
Inodes
One file, folder, cache object, email message, image derivative, backup fragment, or staging copy can consume file-count capacity. A site can run out of inodes while plenty of disk space remains.
CPU
Dynamic PHP, database queries, cron jobs, crawlers and plugins consume processor time. Some hosts publish cores, some percentages, and some CPU-second fair-use thresholds.
RAM
Memory can be shared account-wide, capped per process, or published as a plan allocation. A high PHP memory_limit value does not create physical RAM the account does not have.
PHP concurrency
PHP workers, entry processes and process monitors are related to dynamic workload capacity but are not equivalent metrics. Do not compare 40 PHP workers with 40 entry processes as if they mean the same thing.
I/O
Disk throughput matters during backups, cache generation, imports, media work and database-heavy operations. A plan can become I/O constrained even when CPU appears acceptable.
Databases
Check database count, per-database size, connection limits and import size. Multi-site WordPress portfolios can hit database ceilings before reaching the advertised website count.
Storage
Storage is the easiest limit to understand but it is rarely the only one. Backups, staging copies, logs, email and generated thumbnails can accelerate usage.
Original capacity diagnostic
Resource Pressure Checker
Use actual dashboard percentages and recent errors. The result helps decide whether to optimize, monitor, or research an upgrade; it does not benchmark provider speed.
How to compare plans without creating a fake capacity score
- Start with your own workload. Record current storage, inodes, databases, traffic, cache ratio and resource warnings.
- Map only matching metrics. Compare inodes to inodes and storage to storage. Keep CPU cores, CPU percentages and CPU seconds in separate columns.
- Preserve headroom. Do not plan around running at 95–100% of a published ceiling.
- Watch the account dashboard. Public documentation cannot describe every account revision, regional plan or legacy package.
- Upgrade for repeated pressure, not one spike. A crawler surge or broken plugin should be diagnosed before paying for a larger plan.
When a resource limit should change your buying decision
Choose a higher tier or a different hosting model when the workload repeatedly reaches the same measurable ceiling after reasonable optimization. Shared hosting is a good fit for many new sites, but a growing store, membership system, busy uncached application, agency portfolio, or plugin-heavy WordPress setup can need isolated resources before it needs more disk space.
Related research: compare inode limits, estimate PHP concurrency, calculate multi-site capacity, and decide whether to optimize, upgrade, or switch.
Claim-level official citations
Use the same source the capacity claim came from.
Resource terminology is not standardized across hosts. Recheck the provider documentation before buying or upgrading because thresholds, plan names, and public disclosures can change.
Research method & evidence discipline
Published limits are compared only when the underlying metric matches.
The page separates hard limits, soft thresholds, planning figures, shared-resource policies, and unavailable public data rather than converting unlike controls into one score.
Page-specific update history
Resource changes are recorded only after substantive verification.
- 01
August 8, 2026 Initial source-backed comparison, original capacity tool, provider caveats, and internal-link cluster published.
- 02
Metric discipline Unlike resource controls stay separate instead of being converted into a fake universal score.
- 03
Future revisions Record the previous value, new value, source, provider context, and verification date when a limit changes.