WooCommerce Hosting Requirements: PHP Workers and RAM

The WooCommerce hosting requirements published by Woo — PHP 8.3, MySQL 8.0, 256 MB of memory — describe the floor at which the software will boot, not the hardware that will keep a store up on a Monday morning. The number that actually decides whether your checkout survives traffic is one almost no host puts on its pricing page: how many PHP processes can run at the same time.

Below: the published minimums and where they mislead, the six criteria I judge a store host against, what actually burns server capacity in WooCommerce (it is not page views), a sizing table by orders per day, a comparison of the four hosting shapes against those criteria, and the commands to measure your own store before you pay anyone. Versions and figures checked 3 October 2026 against WooCommerce 11.1.2 on WordPress 7.1.2.

The published minimums, and the one that contradicts itself

Two official pages state requirements, and they do not agree.

Woo’s own Server Requirements document asks for WordPress 6.9 or greater, PHP 8.3 or greater (tested up to 8.4), MySQL 8.0 or MariaDB 10.6 or greater, a memory limit of 256 MB or greater, and HTTPS. WordPress core’s requirements page lands in the same place: PHP 8.3, MySQL 8.0 or MariaDB 10.11, HTTPS on every install.

Then look at the plugin header on the wordpress.org listing for WooCommerce 11.1.2. It says Requires PHP: 7.4. That is the version the installer enforces, and it is four major releases behind what the documentation asks for. PHP 7.4 left security support in November 2022.

Treat 256 MB the same way. It is the limit below which things visibly break, not a target. On a store with a dozen extensions I set WP_MEMORY_LIMIT to 512 MB and WP_MAX_MEMORY_LIMIT to 768 MB, because imports and report generation spike well above what a product page needs. If you are hitting the ceiling rather than choosing it, that shows up as a specific error — see how to fix the WordPress allowed memory size exhausted error for the diagnosis.

// wp-config.php, above the "stop editing" line
define( 'WP_MEMORY_LIMIT', '512M' );
define( 'WP_MAX_MEMORY_LIMIT', '768M' );

Those two constants only raise the ceiling PHP will allow WordPress to request. They cannot exceed the memory_limit your host sets in PHP itself, which is why checking the real value matters more than setting the constant. Checking and updating PHP safely covers how to read what you are actually running.

The six criteria I judge a WooCommerce host against

Stating these up front because they decide everything below, and because most hosting comparisons judge on the wrong axis. Uptime percentages and TTFB on the homepage tell you almost nothing about a store, since the homepage is the one page that caches perfectly.

1. Published PHP worker or concurrency count. Not “unlimited traffic” — an actual number, or at minimum a documented concurrency model. A host that will not tell you is telling you something.
2. A persistent object cache you do not have to run yourself. Redis or Memcached provisioned and supported, not “you may install a plugin”.
3. Correct cache exclusions out of the box. Cart, checkout and account pages bypassed, and the WooCommerce session cookie respected by the edge cache.
4. A real system cron, not WP-Cron. WooCommerce’s background queue is not optional work; it is how orders get their follow-up actions.
5. Database headroom and the right to add an index. Shared MySQL with no ability to run DDL is a hard ceiling on a growing catalogue.
6. Backups that actually contain your orders, and a staging site. Post-HPOS, a backup that only captures wp_posts is not a backup of your store.

Price is deliberately not on that list. It belongs at the end, once you know which tier you need — otherwise you shop down into a plan that cannot run the store and spend the savings on a consultant.

What actually consumes capacity: uncached requests, not page views

This is the part that makes WooCommerce hosting requirements different from blog hosting requirements, and it is worth being precise about.

A PHP worker, in the words of Nexcess’s own documentation, is a background computing process that handles “every action requested from a particular website that isn’t cached”. When they are all busy, requests queue. Nexcess allocates a minimum of ten per site and says plainly that too few workers can become “a bottleneck slowing down a website significantly or even bringing it entirely down” — which your visitors experience as a 504, or as the 503 service unavailable error.

On a brochure site, nearly every request is cached, so ten workers is generous. A store is the opposite case, for four reasons:

• Cart, checkout and My Account can never be cached. Every hit on those is a full PHP request plus database queries.
• Logged-in and session-carrying visitors bypass the page cache entirely. One shopper with something in their cart browsing fifteen category pages is fifteen uncached requests.
• AJAX fires constantly. Add-to-cart, cart fragment refreshes, variation lookups and filtered product queries each hit admin-ajax.php or the Store API, and each takes a worker.
• The background queue competes with your shoppers. Action Scheduler runs inside the same worker pool as your front end unless you move it to CLI.

So the useful question is never “how many visitors a month”. It is roughly: peak concurrent uncached requests × average request duration. A 400 ms uncached page and ten workers gives you about 25 such requests per second before a queue forms. Halve the request time and you double the capacity — which is why fixing a slow query is often cheaper than buying a bigger plan.

WooCommerce hosting requirements by store size

These are my own working figures from sizing and rescuing stores, not vendor specifications, and I would rather give you a number you can argue with than a vague “it depends”. Orders per day is the driver because it tracks checkout concurrency better than traffic does. Assume a reasonably lean theme and twenty or so extensions.

Two notes on reading that table honestly. First, product count matters mostly through admin and search queries, not front-end page loads — a 20,000-product catalogue is painful in wp-admin long before it is painful on a category page, which is the subject of diagnosing a slow WordPress admin dashboard. Second, the “high volume” row is where LIKE '%term%' product search stops being viable and you want a real index; WooCommerce product search plugins compared goes through the options.

Shared, VPS, managed WordPress or Woo-specific

Four shapes, scored against the six criteria above. I am describing categories rather than listing vendor prices, because plan specifications and renewal rates change monthly and a price I quote today will be wrong by the time you read it.

Your cache hit ratio is worse than your host’s dashboard claims

Here is a failure mode that sends people shopping for more RAM when they do not need it.

WooCommerce starts a session for a visitor and sets a cookie. Any decent page cache treats a session cookie as a signal to bypass the cache, which is correct — serving one shopper’s cart to another is the worst bug in ecommerce. The problem is that extensions routinely start a session for visitors who have done nothing at all, so a browsing visitor with an empty cart gets a cookie, bypasses the cache, and consumes a PHP worker for every page they look at.

WooCommerce acknowledged this directly. In version 10.3 Woo shipped an experimental option called Clear Customer Sessions When Empty, which runs on template_redirect at priority 999 — late, so extensions have had their chance to put something in the session — and if both the cart and the session are genuinely empty, it removes the server-side session and the cookie. It skips logged-in users, and it is disabled by default. You have to turn it on.

On a store where an analytics extension was starting sessions on every page view, enabling that moved a large share of category traffic back into the page cache. If your host reports a 95% hit ratio and your workers are still saturated, this is the first thing to check, before you upgrade anything. The mechanics of which pages may and may not be cached are covered in WooCommerce caching plugins: what breaks and what works.

It is still flagged experimental, so test it on staging with your actual extension set rather than switching it on during a sale.

The database: HPOS changed what “a backup of my store” means

Since WooCommerce 8.2, released in October 2023, High-Performance Order Storage has been the default for new installations. Orders no longer live in wp_posts and wp_postmeta. They live in four purpose-built tables:

wp_wc_orders
wp_wc_order_addresses
wp_wc_order_operational_data
wp_wc_orders_meta

This is a straightforward win for performance — order queries stop fighting every post, page and revision for the same index. It has two consequences for hosting that people discover at the worst possible moment.

First, any backup or migration tool that predates HPOS, or that works from a post-table export, will produce a file that looks complete and contains no orders. Verify by restoring to staging and counting rows, not by trusting a green tick. WooCommerce backup plugins compared goes through which tools handle this correctly.

Second, if you run a store built before 8.2 you may still be on the legacy post tables, or running both in sync during migration, which doubles order writes. Check which mode you are in under WooCommerce → Settings → Advanced → Features, and check whether compatibility mode is still on. Synchronising two order stores forever is a cost you are paying for nothing.

While you are in the database, the WordPress options table deserves a look. Autoloaded options are fetched on every single request, so a few megabytes of autoloaded transients left behind by a removed plugin taxes every page load:

wp option list --autoload=on --format=table \
  --fields=option_name,size_bytes --orderby=size_bytes --order=desc | head -20

Anything above a megabyte that you do not recognise is worth investigating. If the whole autoloaded set is over about 1 MB, that is a real tax on every uncached request, and it is free to fix.

A persistent object cache is the cheapest upgrade available

Without one, WordPress rebuilds its object cache from the database on every request. With one, the results of expensive queries persist between requests. For a store with a large catalogue this is routinely a bigger improvement than moving to a faster CPU, and on most managed hosts it costs nothing because Redis is already running.

The standard route is the Redis Object Cache plugin, at version 3.0.0 with over 500,000 active installations, 4.5 out of 5 from 179 reviews, tested to WordPress 7.1.2 and requiring PHP 7.2 or greater. It supports Predis, PhpRedis and Relay as clients. The thing to be clear about: the plugin is not the cache. It needs a Redis server to connect to. Installing it on hosting with no Redis available does nothing at all, which is a surprisingly common disappointment.

Check whether you already have one before buying anything, under Tools → Site Health → Status, where WordPress reports a missing persistent object cache as a recommendation. Or from the command line:

# Is an object cache drop-in actually in place?
wp eval 'echo wp_using_ext_object_cache() ? "external" : "none", PHP_EOL;'

# Does a Redis extension exist on this server at all?
php -m | grep -iE 'redis|relay'

If that first command prints none and the second prints nothing, Redis is a question for your host, not a plugin you can install your way out of. WordPress Site Health covers the other recommendations on that screen.

Action Scheduler is competing with your shoppers

WooCommerce queues background work — emails, subscription renewals, stock syncs, webhooks, data updates — through Action Scheduler. Its documented defaults are conservative, and worth knowing before you blame your host:

• It claims a batch of 25 actions at a time (action_scheduler_queue_runner_batch_size).
• It runs one concurrent batch (action_scheduler_queue_runner_concurrent_batches).
• It processes for a maximum of 30 seconds per request (action_scheduler_queue_runner_time_limit).

By default those batches run through WP-Cron, which means they are triggered by visitor page loads and executed by the same PHP workers serving your front end. Two things follow. On a quiet store, nobody visits, so the queue stalls and order emails go out late — the same mechanism behind the missed schedule error. On a busy store, the queue steals workers from checkout exactly when checkout needs them.

The fix is to disable WP-Cron’s page-load trigger and drive it from the server, which is why system cron access is on my criteria list:

// wp-config.php — stop cron firing on visitor page loads
define( 'DISABLE_WP_CRON', true );

# crontab -e   (adjust the path to your install)
*/5 * * * * cd /home/user/public_html && wp cron event run --due-now >/dev/null 2>&1
*/5 * * * * cd /home/user/public_html && wp action-scheduler run >/dev/null 2>&1

Running the queue through WP-CLI is what Action Scheduler’s own performance documentation recommends for throughput, and it is better than raising the concurrency filters, which its docs warn “can substantially increase server load”. Check your backlog under WooCommerce → Status → Scheduled Actions; a pending count in the tens of thousands is a configuration problem, not a capacity problem.

Measure your own store before you pay anyone

Upgrading hosting to fix a slow site works about half the time. The other half, you move a badly behaved plugin onto faster hardware and it is still slow, now more expensively. Twenty minutes of measurement tells you which half you are in.

Start with the time it actually takes to generate an uncached page, since that number divided into your worker count is your real capacity. Request a URL with a cache-busting query string so you are timing PHP rather than the cache:

# Time to first byte on an uncached product page, five samples
for i in 1 2 3 4 5; do
  curl -o /dev/null -s -w "%{time_starttransfer}\n" \
    "https://example.com/product/some-product/?nocache=$RANDOM"
done

Under 400 ms is healthy. Around a second means you have roughly a quarter of the capacity you think you do. Over two seconds, no hosting plan will save you and you have a code problem to find first.

Then find where the time goes. Query Monitor, installed on staging, breaks a single page load into query count, slowest queries, and time attributed per plugin, which is the fastest way to identify the extension responsible. If the answer is one plugin generating 400 queries on a category page, that is the thing to fix. Troubleshooting a plugin conflict step by step covers isolating it safely on a live store.

It is also worth checking whether your database is simply too big to sit in memory, because that is a genuine hosting answer rather than a code one:

wp db size --tables --human-readable --format=table \
  | sort -k2 -h -r | head -15

If your data set comfortably exceeds the memory the database server has for its buffer pool, MySQL goes to disk on queries that should be instant, and more PHP workers will not help. That is the point at which “buy more RAM” is the correct diagnosis. A database that will not answer at all is a different problem — see fixing the error establishing a database connection.

Your theme and plugin stack sets the price of every request

Worth saying plainly, because it is the lever most store owners ignore while shopping for hardware: hosting requirements are partly a consequence of what you installed. A page that executes less PHP and runs fewer queries needs fewer workers to serve the same traffic, and on uncacheable pages — cart, checkout, account — there is no cache to hide behind.

The criterion I use is simple and measurable in Query Monitor: queries and PHP time on an uncached product page with the theme active and nothing else changed. Judge candidates on that, not on marketing copy.

By that measure, the mature lightweight options are the safe picks: GeneratePress and Kadence both have long track records on large WooCommerce stores, and a core block theme such as Twenty Twenty-Six costs essentially nothing per request. Full page builders sit at the other end — they add markup and often their own query layer to every uncached page, which is a real cost at checkout. The page builder comparison has the trade-offs in detail, and how to choose a WordPress theme covers the non-performance criteria.

One more thing on stack cost: bulk email. If you send newsletters from the same server that runs your store, every send competes with your checkout for workers, and your transactional order emails share an IP reputation with your marketing. Send campaigns through an external provider and keep the store’s own mail on a dedicated relay — WordPress emails not sending and WooCommerce SMTP plugins compared cover the setup.

What to ask a host before you hand over a card

Send this to pre-sales. The answers, and how readily they come, tell you more than any review.

• How many PHP workers or concurrent PHP processes does this plan get? If the answer is “unlimited”, ask what happens on the 30th simultaneous uncached request.
• Is Redis or Memcached available on this plan, dedicated or shared, and with how much memory?
• Are cart, checkout and My Account excluded from the page cache by default, and does the edge cache respect the WooCommerce session cookie?
• Do I get system cron access, and at what interval? Can you run Action Scheduler via WP-CLI?
• Is the database shared with other customers? Can I see the slow query log and add an index?
• Do backups include the full database with the wp_wc_orders tables, how long is retention, and can I restore to staging myself?
• Is any plugin I rely on on your blocklist? Ask specifically about your caching and backup plugins.
• What does this renew at after the introductory term, and what does migration off look like?

That last one catches people every year. Introductory pricing on managed WordPress hosting frequently covers the first term only, and the renewal can be two or three times the signup rate. Budget on the renewal figure, and get it in writing before you migrate.

Whatever you choose, test the store properly after you move rather than clicking the homepage and calling it done — how to test your WordPress site after a major update works as a migration checklist too. Place a real test order, confirm the email arrives, and watch the scheduled actions queue drain.

Frequently asked questions about WooCommerce hosting requirements

Where to start

If you do one thing after reading this, time an uncached product page. That single number tells you whether you have a hosting problem or a code problem, and it stops you from buying the wrong fix. Then check whether you have a persistent object cache and whether your cron is real. Those three checks cost nothing and resolve most “my store is slow” cases before any money changes hands.