How much RAM, vCPU, and storage does a website need at different stages

Choosing the wrong server spec is a quiet, expensive mistake. Your site loads slowly, bounce rates climb, and you either pay for capacity you never use or watch your server fall over the moment a campaign drives real traffic.

This guide gives you a clear, stage-by-stage framework for RAM, vCPU, and storage requirements. It covers what changes as your traffic grows, why e-commerce sites operate under different rules than content sites, how caching changes the math entirely, and what storage type you need at each level. No vague advice. Specific numbers and the logic behind them.

Why server specs are a revenue issue, not just a technical one

Getting your hosting specs wrong costs money in a way that shows up directly in your conversion data. A 2-second delay in page load time increases bounce rates by 103 percent, according to Google research cited by Huckabuy. For e-commerce sites, the impact is even sharper. Sites loading in 1 second convert at 3.05 percent on average. That drops to 1.08 percent at 5 seconds, a 65 percent reduction in conversions for the same volume of traffic, based on Portent's study across 94 million page views.

The root cause of slow load times is often under-specced hosting, not bad code. When a server runs out of RAM, it starts writing active processes to disk. Disk is 50 to 100 times slower than RAM. When a server runs out of CPU, requests queue up. When storage IOPS are saturated, database queries stall. All three bottlenecks show up as slow page loads to the user and as poor LCP and INP scores to Google. If you want to understand how Google measures these signals, our Google Search Console guide covers Core Web Vitals reporting in detail.

"When you're running paid campaigns and your server can't handle the resulting traffic spike, you're not just losing visitors. You're burning budget on conversions that never complete." Tanner Medina, Co-Founder & Chief Growth Officer, Launchcodex

Fixing these issues is straightforward once you understand what resource handles what job and which stage of growth demands which spec.

What RAM, vCPU, and storage actually do

Each server resource handles a different job, and they do not substitute for each other. RAM holds active processes in fast memory so the CPU can access them without reading from disk. The vCPU executes instructions and processes requests. Storage holds your files and database at rest. If any one of the three is starved, performance degrades regardless of how strong the others are.

As the ScalaHosting technical team notes, if you get RAM or CPU wrong, the other cannot compensate. The same logic extends to storage. Fast NVMe storage reduces latency on database reads, but a server with 1 GB of RAM and a queue of 200 simultaneous requests will not be saved by fast storage alone.

How each resource maps to user experience

• RAM: Directly affects how many concurrent users your server can handle without swapping to disk. Running out causes 500 internal server errors.
• vCPU: Determines how fast each request gets processed. An overloaded vCPU means requests wait in a queue, adding latency to every page load.
• Storage: Affects database query time and file read speed. The type of storage, NVMe, SSD, or HDD, sets the ceiling on how fast your database responds under load.

The vCPU quality problem most buyers miss

A vCPU is a slice of a physical core allocated to your virtual machine by a hypervisor. It is not a dedicated physical core. Providers can and do oversell vCPU counts. Two plans both labeled "4 vCPU" from different providers can deliver very different real performance depending on the underlying hardware generation, how many virtual machines share the physical host, and whether the provider uses KVM or a container-based approach like OpenVZ.

As Alibaba Cloud's infrastructure guidance explains, overprovisioning vCPUs can cause CPU ready time, which is the time a virtual CPU spends waiting for a physical core to become available. More vCPU does not always mean faster. When evaluating providers, ask about CPU generation and test with YABS before committing to a plan.

The four-stage hosting framework

Your hosting requirements change at predictable traffic thresholds. The framework below maps four stages of growth to specific RAM, vCPU, and storage specs for a typical content site. E-commerce sites and database-heavy applications should apply the multiplier covered later in this article.

A widely used benchmark across the VPS industry is 1 CPU core and 2 GB of RAM per 200,000 monthly visitors. That ratio, based on years of real-world hosting data from providers including ScalaHosting, is a useful starting point. The table below expands it into a full staged spec framework.

Stage 1: launch (0 to 10,000 monthly visitors)

A new site, small business page, or personal blog has minimal concurrent users. Standard shared hosting handles this stage cleanly. An entry-level VPS with 1 vCPU and 1 to 2 GB RAM will rarely see resource pressure on a well-optimized stack.

A typical shared hosting environment running cPanel, MySQL, and Apache across 20 to 30 low-traffic domains requires just 2 GB RAM as a bare minimum, according to EuroVPS's VPS sizing guide. Storage is not a constraint at this stage. A standard SSD with 10 to 20 GB covers most sites with room to grow.

The real risk at launch is choosing a shared host that throttles CPU aggressively, causing slow response times even at low traffic. Look for hosts running LiteSpeed or Nginx rather than Apache to keep memory usage low.

Stage 2: growth (10,000 to 100,000 monthly visitors)

At this stage your site has real users. You are possibly running campaigns, email flows, or an active blog. Traffic is uneven and spikes happen. Shared hosting starts to show its limits because you share CPU and RAM with other sites on the same physical server.

A VPS with 2 to 4 vCPU and 4 to 8 GB RAM handles this range comfortably for a content site with caching in place. If you run WooCommerce, handle form submissions, or serve logged-in users at any meaningful volume, target the 4 vCPU and 8 GB end of that range. DCHost's CPU and bandwidth guide is clear on this: with proper caching and optimized images, 1 vCPU and 1 GB RAM can handle 20,000 monthly visitors on a static-heavy site. The moment you add WooCommerce or logged-in users, start with 2 vCPU and 2 GB RAM at minimum.

Stage 3: scale (100,000 to 500,000 monthly visitors)

At this traffic level you need dedicated resources. VPS hosting is still viable, but you should be on a plan with guaranteed resource allocation, KVM virtualization, and NVMe storage. CPU steal time becomes a real concern on oversold VPS environments.

Target 4 to 8 vCPU and 8 to 16 GB RAM for a content-focused site. Add Redis for object caching. Move MySQL to a dedicated database instance if your query volume is high. Use a CDN like Cloudflare to offload static asset delivery from your origin server, which reduces CPU cycles and bandwidth costs significantly.

Stage 4: enterprise (500,000 and above)

A site handling 500,000 or more monthly visitors, especially with dynamic content, user accounts, or transactional features, needs dedicated hardware or cloud infrastructure with auto-scaling. Sites handling heavy content such as video, images, or many plugins can require 6 to 8 vCPU and 16 to 32 GB RAM, according to CyberGrapes' hosting guide.

For database-heavy e-commerce operations, high-traffic dedicated servers should target 32 GB RAM or more, per Bacloud's dedicated server sizing guidance. At this scale, you also need monitoring, load testing, and a documented scaling plan. Vertical scaling, adding more RAM and CPU to a single server, has a ceiling. At some point, horizontal scaling across multiple servers becomes necessary.

How caching changes the math on every spec

Caching is the single biggest variable in hosting resource planning. A fully cached content site can handle 3 to 5 times more traffic on the same server compared to an uncached one. If you skip this, you will consistently overpay for hosting or under-serve your users.

As the GridPane team explains in their server sizing guide, serving a page from the server cache is extremely efficient, and it takes a substantial amount of concurrent traffic to noticeably impact CPU. Any request that bypasses the cache and hits the database is CPU-intensive, especially if it also writes to the database.

The three caching layers that reduce resource demand

1. Page caching: Stores fully built HTML pages and serves them directly without running PHP or querying the database. This reduces CPU and RAM demand per request by the highest margin.
2. Object caching: Uses Redis or Memcached to store the results of database queries in memory. This reduces repeat database calls and lowers MySQL CPU load.
3. CDN caching: Offloads static files, images, CSS, and JavaScript, to edge nodes closer to the user. This reduces origin server bandwidth and request volume.

A WordPress site with full-page caching via LiteSpeed or Nginx FastCGI, object caching via Redis, and a CDN in front can comfortably handle 100,000 monthly visitors on a 2 vCPU and 4 GB RAM VPS. Without caching, that same site would likely need double the compute to avoid slowdowns during traffic peaks.

The caching ceiling you cannot ignore

The EuroVPS team makes an important practical point: when memory consumption for PHP and MySQL processes scales past 16 GB, application-level caching is no longer enough. At that threshold, you need external caching, a CDN, and serious consideration of clustering or load balancing. No WordPress caching plugin replaces infrastructure-level solutions at that scale.

"We always tell clients: don't spec-jump based on assumptions. Set up real monitoring on day one and let your actual usage data drive the upgrade decision." Derick Do, Co-Founder & Chief Product Officer, Launchcodex

E-commerce sites need more: the resource multiplier

An online store is not just a website with products on it. Most of its traffic comes from logged-in users whose requests cannot be cached in the traditional sense. Every add-to-cart action, checkout step, and account interaction writes to the database. The practical rule is to plan for 1.5 to 2 times the CPU and RAM of a content site at the same traffic level.

A WooCommerce or Magento store serving 20,000 to 50,000 monthly visitors needs at least 4 vCPU and 8 GB RAM. At 50,000 to 150,000 visitors, target 6 to 8 vCPU and 16 GB RAM, with NVMe storage and Redis object caching running separately from your web server process. Slow checkout pages are also one of the top causes of lost revenue. Our conversion rate optimization guide covers how page speed and server performance connect directly to checkout completion rates.

Why e-commerce is harder on your server

• Authenticated sessions: Logged-in users bypass page cache, so every request hits PHP and MySQL directly.
• Cart and inventory writes: Every purchase, stock update, and session change generates database writes, not reads. Writes cost more in IOPS and CPU time.
• Search and filtering: Product filtering and search queries are often the heaviest operations on an e-commerce database. Without proper indexing and Redis caching, these queries run full table scans.
• Payment processing: Integrations with payment APIs add external request latency and processing time that compounds under concurrent checkout load.

Practical e-commerce configuration at each stage

At the growth stage, covering 10,000 to 50,000 monthly visitors for a store, run WordPress and MySQL on the same VPS with at least 4 GB RAM, Redis, and NVMe storage. At the scale stage, covering 50,000 to 200,000 monthly visitors, separate your database server from your web server. At enterprise level, consider managed database services like Amazon RDS or Google Cloud SQL, combined with auto-scaling web tier instances.

PCI DSS compliance for sites processing card payments also rules out shared hosting entirely. VPS with resource isolation, or dedicated hosting, is the minimum standard.

Storage type matters: when SSD is enough and when NVMe earns its cost

Standard SATA SSDs are adequate for most sites up to the growth stage. NVMe earns its cost at the scale stage and above, where database IOPS become a real constraint. NVMe reads and writes at roughly 4,000 MB/s on average, compared to about 400 MB/s for SATA SSDs, making it approximately 10 times faster for the read and write workloads that matter in a database context.

The relevant metric is not raw sequential speed. It is IOPS, which measures how many discrete read and write operations storage can complete per second. SATA SSDs max out at around 100,000 IOPS. NVMe drives reach 1 million IOPS. For a blog serving static pages from cache, this difference is invisible. For a WooCommerce store under Black Friday load, it is the difference between a fast checkout and a timed-out transaction.

The cost argument for NVMe

According to a 2025 benchmark comparison by WeHaveServers, NVMe costs roughly 30 to 50 percent more per TB than SATA SSD. When you factor in IOPS per dollar, the performance-per-dollar ratio is approximately 10 times higher. For database-heavy workloads, one NVMe drive outperforms a RAID 10 array of SATA SSDs in most real-world scenarios.

Storage type decision guide

One practical note: if a provider in 2025 is still offering HDD-based VPS plans as a performance option rather than a pure backup tier, that signals something about their infrastructure investment priorities. HDD has no place in modern web hosting for sites where load time affects business outcomes.

Six signs you need to upgrade your hosting now

Most hosting failures are predictable. The data is in your dashboard days or weeks before users start complaining. Knowing what to watch for lets you upgrade before you lose traffic, not after.

These are the six clearest signals that your current spec has become a constraint.

1. CPU usage consistently above 80 percent during normal traffic. Peak spikes are expected. Sustained high CPU during ordinary sessions means your compute budget is already exhausted.
2. RAM usage persistently above 90 percent. When RAM fills up, your server starts writing to disk swap. Response times degrade even if CPU load looks manageable.
3. Recurring 500 internal server errors. These typically indicate PHP processes running out of memory. They are a direct symptom of insufficient RAM for the concurrent load your site is handling.
4. Slow checkout or form submission pages on otherwise fast sites. Dynamic pages that write to the database reveal storage and CPU pressure that static pages mask entirely.
5. Warning emails from your hosting provider about resource limit breaches. Most shared and entry-level VPS providers monitor and alert on these thresholds. Each alert is a documented signal to move up.
6. Load times that were previously acceptable becoming noticeably slower after a content change, traffic increase, or new plugin addition. The site has crossed a resource threshold.

As the BitLaunch infrastructure team notes, stable and reliable performance is always better than a theoretical high spec that never reaches its peak. What is on a plan page matters less than monitoring your actual utilization over 30 to 60 days and making decisions from that data.

When to stop scaling vertically and add more servers

Vertical scaling means adding more RAM and CPU to a single server. It works well through the growth and early scale stages, but it has a ceiling. Once you are running a dedicated server with 32 GB RAM and 8 cores, adding more hardware to a single machine delivers diminishing returns and creates a single point of failure.

Horizontal scaling splits your load across multiple servers. You run multiple web server instances behind a load balancer, with a shared database layer and a CDN serving static assets globally. This is how AWS, Google Cloud, and Azure handle traffic at scale.

The right time to move to horizontal scaling is when one or more of these conditions are true:

• Your site cannot tolerate even minutes of downtime during hardware maintenance or a single server failure.
• Traffic spikes are unpredictable and extreme, such as viral content or scheduled product launches.
• Your database and web server are competing for the same RAM and CPU on one machine.
• You need to serve users across multiple geographic regions with low latency.

Cloud VPS providers like DigitalOcean, Vultr, and Hetzner offer managed load balancers and scalable configurations that make horizontal scaling accessible without managing physical hardware. AWS, Google Cloud, and Azure provide auto-scaling groups that add server capacity in response to real-time demand, reducing both over-provisioning costs and the risk of running out of capacity during peak periods. If you are also building or rebuilding your site at this stage, our web development and digital infrastructure services include architecture planning for teams that need to scale reliably.

A practical spec plan your site can grow into

Hosting specs are not a one-time decision. They are an ongoing process of matching your infrastructure to your actual traffic behavior, site type, and business requirements.

Start with a clear baseline. For most new sites, 1 to 2 vCPU and 2 to 4 GB RAM on an SSD-backed VPS is a sensible and cost-effective starting point. Set up page caching from day one. Monitor CPU and RAM utilization in your hosting dashboard weekly for the first two months. The data will tell you which direction to scale before a problem surfaces.

When you pass 20,000 monthly visitors on a content site, or 10,000 on an e-commerce site, move to a VPS with at least 2 vCPU and 4 GB RAM on NVMe storage. Add Redis for object caching. From there, apply the staged framework above and revisit specs every time traffic grows by 50 percent or more.

The numbers in this guide are benchmarks, not hard rules. Your actual requirements depend on your codebase, plugin count, database size, and how your users interact with your site. The benchmarks give you a starting point. Real monitoring gives you the truth.

For teams managing multiple properties or planning for aggressive growth, Launchcodex builds hosting architecture strategies that map your stack and traffic patterns to a specific infrastructure plan, including monitoring setup, caching configuration, and a documented upgrade path before you hit limits.

FAQ

How much RAM does a WordPress site need?

A basic WordPress site with low traffic and caching enabled can run on 1 to 2 GB of RAM. A growing site at 20,000 to 50,000 monthly visitors should target 4 GB. A WooCommerce store or high-traffic blog at 100,000 or more monthly visitors needs 8 GB or more, with Redis for object caching.

Is 1 vCPU enough for a website?

For a new site under 10,000 monthly visitors with a properly cached stack, yes. Once you move past that range or start running dynamic features such as user accounts, checkout, or membership content, move to at least 2 vCPU.

How much storage does a website need?

Most small to mid-sized websites require 10 to 50 GB of storage for files, database, email, and backups. Large media-heavy sites or e-commerce catalogs can grow larger. The storage type matters as much as the size. NVMe storage is recommended for any site with active database queries.

When should I switch from shared hosting to a VPS?

Switch when you see consistent CPU or RAM warnings from your hosting provider, when your site slows noticeably during traffic peaks, or when you need custom server software or configuration. Most sites benefit from a VPS move somewhere between 10,000 and 30,000 monthly visitors.

Is NVMe worth the extra cost for hosting?

For content-only sites with strong caching, a standard SSD is usually sufficient. For any site with active database usage, including WooCommerce, Magento, membership sites, and SaaS applications, NVMe is worth the cost. The 30 to 50 percent price premium over SATA SSD delivers approximately 10 times the IOPS performance where it counts most.

What is the difference between vCPU and a physical CPU core?

A vCPU is a virtual allocation from a physical CPU, managed by a hypervisor. Multiple virtual machines share the same physical chip. The performance of a vCPU depends on how many VMs share the host and how the provider manages resource allocation. Two plans with "4 vCPU" from different providers can deliver very different real-world performance.