Turkey (Turkish)
Germany (German)
Worldwide (English)
Catalog size
More products and variants increase index size, filtering/search work, imports and database growth.
Halkali merkez neighborhood fatih st ozgur apt no 46 , Kucukcekmece , Istanbul , 34303 , TR
Estimate CPU, RAM and NVMe requirements from catalog size, traffic, orders and peak campaigns.
Monthly traffic alone is not enough. Catalog size, order load, peak concurrency, integrations and caching architecture are considered together.
This is a pre-purchase starting estimate. Production sizing should be validated with load testing and observability: p95 latency, PHP worker saturation, peak RAM, database queries and background queue depth.
Plan pricing can change, so the calculator does not hard-code prices. Check the live VPS page for current pricing.
WooCommerce and other ecommerce platforms do not publish an official “X CPU / Y GB RAM” table based on product count. The calculator therefore starts from supported software baselines and adds capacity for catalog size, dynamic checkout traffic, integrations and peak load.
More products and variants increase index size, filtering/search work, imports and database growth.
Cart, checkout and account areas are customer-specific and cannot rely on generic full-page caching.
Orders, email, webhooks, stock sync, feeds and queues can consume resources concurrently during campaigns.
Monthly averages hide the busiest hour, so campaign peaks are modeled separately.
The goal is not to run the server at 100% continuously but to keep reserve for bursts.
Current WooCommerce server recommendations include WordPress 6.9+, PHP 8.3+, MySQL 8.0+ or MariaDB 10.6+, HTTPS and a WordPress memory limit of at least 256 MB. These are supported software baselines, not a capacity guarantee.
Current WooCommerce recommendation
Supported modern database baseline
Per-process WordPress limit, not total VPS RAM
Baseline for secure sessions and checkout
WooCommerce’s 2026 hosting guide highlights dedicated PHP worker capacity and suggests 5–10 dedicated workers as a good starting point. Worker counts must still be sized against the real memory footprint of your theme, plugins and requests.
WooCommerce documentation recommends excluding Cart, Checkout and My Account from full-page caching because they contain customer-specific dynamic data.
Object caching can reduce repeated database reads for frequently requested store data, while a CDN can offload static assets and cacheable responses from the origin.
HPOS has been enabled by default for new WooCommerce installations since 8.2 and uses dedicated order tables to improve the order data model for scale.
Large imports, frequent stock/price sync, feed generation and marketplace API activity can create CPU, RAM, disk I/O and queue load that traffic-only sizing misses.
These are not fixed rules; they illustrate the capacity model used by the calculator.
| Scenario | Catalog | Traffic | Orders | Starting target |
|---|---|---|---|---|
| Small WooCommerce | ≤ 1,000 products | ≤ 50k/month | ≤ 100/day | 4 vCPU · 4–6 GB RAM |
| Growing store | 10–50k products | 50–250k/month | 100–500/day | 4 vCPU · 8–12 GB RAM |
| High-traffic ecommerce | 50k+ products | 250k+/month | 500+/day | 8+ vCPU · 16–32+ GB RAM |
| Campaign / ERP heavy | Large & variant-heavy | 4×–8× peak | high | 8–12+ vCPU · 32–64+ GB RAM |
Test category → product → add to cart → checkout, not just the homepage.
Approximate simultaneous sessions and request rate at campaign peak instead of monthly averages.
Watch p95 latency, 5xx errors, timeouts and checkout failures together.
Measure active workers, queue wait time and long-running requests.
Inspect slow queries, locks, buffer behavior and disk I/O rather than CPU alone.
If normal peak load fully consumes CPU/RAM, the next campaign has insufficient headroom.
The capacity formula is an Eka Sunucu planning heuristic. Software versions and platform behavior are grounded in the official sources below.
There is no universal RAM number. Theme/plugin behavior, product count, concurrent users, PHP workers, database load and caching architecture all matter. 4 GB can be a practical starting point for a small production store, but busy stores require measurement and load testing.
It may work for some optimized catalogs, but variations, filters, XML sync, heavy plugins and checkout traffic can quickly exhaust the margin. Size from database behavior, imports and peak concurrency as well as product count.
No. A persistent object cache can be useful on dynamic database-heavy stores, but it is not a substitute for healthy queries, correct full-page cache rules or sufficient PHP capacity.
Not as generic full-page cache. WooCommerce recommends excluding Cart, Checkout and My Account because they contain customer-specific dynamic information.
A small low-traffic store can start on quality managed hosting. VPS becomes attractive when PHP worker limits, resource ceilings, imports, cron/queue work or campaign spikes require isolated capacity and more control.
No. It narrows the starting capacity. Production sizing must be validated with load tests and measurements because code quality, plugins, queries, cache hit rate and third-party API latency can change performance dramatically.
Use the CPU, RAM and NVMe target from the calculator and compare current Eka Sunucu VPS plans. For large catalogs, ERP sync or campaign peaks, we can help validate the architecture.