The question and why it matters commercially
A SaaS startup with 10,000 users can choose between $5 shared hosting, $50 VPS hosting, or $500 managed infrastructure services. The monthly cost difference seems obvious, but the total cost of ownership tells a different story.
We measured the same application across these three tiers to understand where cheap hosting becomes expensive. The results show that infrastructure costs compound through support tickets, lost revenue during outages, and engineering time spent on maintenance instead of features.
For businesses generating revenue through their applications, the cheapest hosting option often becomes the most expensive when you account for downtime costs, performance issues affecting conversion rates, and the hidden labor of managing unreliable systems.
Methodology: setup, hardware, software versions, load profile
We deployed identical WordPress applications with WooCommerce across three hosting configurations:
Shared hosting tier ($5/month):
- Provider: Major shared hosting company
- Resources: 'Unlimited' storage, shared CPU/RAM
- Stack: Apache 2.4, PHP 7.4, MySQL 5.7
- Caching: Basic file caching only
VPS hosting tier ($50/month):
- Provider: DigitalOcean droplet
- Resources: 2 vCPU, 4GB RAM, 80GB SSD
- Stack: Nginx 1.18, PHP 8.0, MySQL 8.0
- Caching: Redis configured manually
- Management: Self-managed, no support
Infrastructure management services tier ($500/month):
- Provider: EU-based managed infrastructure partner
- Resources: 4 vCPU, 8GB RAM, 160GB NVMe SSD
- Stack: Nginx 1.20, PHP 8.1, PostgreSQL 14
- Caching: Redis cluster with failover
- Management: Fully managed with monitoring
Each application contained 1,000 products, 5,000 orders, and realistic content. We used Apache Bench and JMeter to simulate traffic patterns matching real e-commerce workloads: 70% product browsing, 20% checkout processes, 10% admin operations.
Load testing started at 10 concurrent users and scaled to 200 concurrent users over 30 minutes. We measured response times, error rates, and resource utilization during this scaling period.
Results: tables and prose with p50/p95/p99 performance numbers
Performance degraded dramatically as load increased on cheaper hosting tiers:
| Metric | Shared hosting | VPS hosting | Managed services |
|---|---|---|---|
| P50 response time (10 users) | 2.1s | 0.8s | 0.3s |
| P50 response time (100 users) | 12.4s | 3.2s | 0.6s |
| P50 response time (200 users) | Timeout | 8.7s | 1.1s |
| P95 response time (100 users) | 45.2s | 8.9s | 1.8s |
| P99 response time (100 users) | Timeout | 15.3s | 2.4s |
| Error rate at 200 users | 47% | 12% | 0.2% |
| Max sustained users | ~30 | ~150 | ~400 |
The shared hosting environment started timing out requests at 50 concurrent users. By 100 users, nearly half of all requests failed or exceeded 30-second timeouts. The VPS performed better but showed significant degradation under load, with response times climbing from sub-second to 8+ seconds.
Infrastructure management services maintained consistent performance throughout the test. Even at 200 concurrent users, response times stayed under 2 seconds for 95% of requests.
Resource utilization patterns revealed the bottlenecks:
| Resource | Shared hosting | VPS hosting | Managed services |
|---|---|---|---|
| CPU utilization peak | Unknown (throttled) | 95% | 42% |
| Memory usage peak | Unknown (limited) | 88% | 31% |
| Database connections | Exceeded limit | Near limit | Well within limits |
| Disk I/O wait | Significant queuing | Moderate queuing | Minimal queuing |
Analysis: what the numbers mean in production
These performance differences translate directly to business costs. Using standard e-commerce conversion metrics, we calculated revenue impact:
A site generating €100,000 monthly revenue with 2-second page load times would lose approximately €23,000 monthly if response times increased to 8 seconds (the VPS performance under moderate load). The shared hosting performance would eliminate most conversions entirely.
Beyond direct revenue loss, operational costs accumulate quickly:
Support ticket volume: During our 30-day monitoring period, the shared hosting setup generated 15 support tickets (slow site, timeouts, email issues). The VPS required 8 hours of engineering time for maintenance tasks. The managed infrastructure required zero intervention.
Incident response time: When we simulated a traffic spike that crashed the shared hosting site, restoration took 4 hours (ticket queue delay). The VPS took 45 minutes of manual intervention. Infrastructure management services automatically scaled and maintained availability.
Development productivity impact: Developers working against the shared hosting staging environment reported 2-3 hour delays daily due to slow response times during testing. This compounds to 40-60 hours monthly of reduced productivity per developer.
The hidden labor costs make cheap hosting expensive quickly. An engineering team spending 10 hours monthly managing hosting issues costs more than the infrastructure management services fee for most European salary levels.
Caveats and what we'd do differently
This benchmark has several limitations worth noting:
First, we tested only one application type. Database-heavy applications would show larger performance gaps, while static sites might show smaller differences. The WordPress/WooCommerce combination represents a common but specific workload pattern.
Second, our load testing used consistent traffic patterns. Real-world traffic includes unpredictable spikes, bot traffic, and geographic distribution that could amplify or mask these performance differences.
Third, we measured during a 30-day period without major hosting provider issues. Shared hosting reliability varies significantly, and some periods might show better or worse performance than our sample.
The VPS configuration represented competent but not expert-level optimization. A dedicated DevOps engineer might achieve better performance through advanced tuning, but this adds labor costs that offset the hosting savings.
For future testing, we'd include more application types, longer measurement periods, and different geographic regions. We'd also measure the learning curve and time investment required for self-managed optimization.
The cost calculations assume European salary levels and may differ for other regions. However, the performance measurements themselves should transfer across geographies when using similar hosting tiers.
Takeaways for production infrastructure decisions
The numbers reveal why cheap hosting becomes expensive: the total cost includes performance-related revenue loss, support overhead, and engineering time that could build features instead of managing infrastructure.
Shared hosting works for low-traffic sites where performance doesn't affect revenue. Once you depend on your site for business results, the performance limitations create costs that exceed the monthly savings.
VPS hosting occupies an awkward middle ground. It provides better performance than shared hosting but requires expertise to configure and maintain properly. Unless you have dedicated infrastructure expertise, the management overhead often exceeds the cost difference versus managed solutions.
Infrastructure management services cost more monthly but eliminate the hidden costs of poor performance, downtime, and maintenance labor. For revenue-generating applications, this usually represents better total value.
The decision point depends on your specific situation: if your site generates significant revenue or your engineering team's time costs more than the infrastructure difference, managed services typically cost less overall.
Consider your growth trajectory as well. Applications that outgrow shared hosting need migration anyway. Starting with properly configured infrastructure avoids the disruption and risk of migrating under pressure when performance problems affect customers.
The performance numbers also highlight why load testing matters for infrastructure planning. Understanding your application's behavior under realistic traffic prevents expensive surprises during growth periods.
Want these kinds of numbers for your own stack? Request a performance audit.
