How much RAM WooCommerce uses with 50, 500 and 5,000 products: we measured it
Lab measurements from 5 October 2026: the number of products doesn't make PHP memory per request grow. The database grows, not the RAM.
UptimeMag editorial team · 6 October 2026 · 2 min read
Anyone sizing a VPS for a WooCommerce store almost always asks the same question: with 5,000 products, do I need more RAM than with 50? On 5 October 2026 we put the question to the test in the lab, rather than answering by gut feeling.
How we measured it
Environment: WordPress 7.1.2, WooCommerce 11.1.2, Storefront theme, PHP 8.3.35 with Apache, MariaDB 11.8.9, Redis 7, WP_MEMORY_LIMIT set to 512M, Docker container on an 8-core machine. For each page we made 15 requests, discarding the first and taking the median, with two warm-up requests beforehand to prime OPcache. The 50 and 500-product rows were redone in a separate, independent run: identical figures.
The numbers
| Catalogue | Peak PHP memory (catalogue) | Queries (catalogue) | Generation time |
|---|---|---|---|
| 50 products | 10.80 MB | 80 | 178 ms |
| 500 products | 10.80 MB | 80 | 176 ms |
| 5,000 products | 10.80 MB | 80 | 147 ms |
Product page: 10.77 MB peak, 99 queries, identical across all catalogue sizes. Homepage: 10.59 MB. Container: PHP+Apache stable between 144 and 146 MiB, MariaDB between 108 and 135 MiB.
With Redis object cache enabled, at full catalogue size (5,000 products): 15 queries instead of 80 on the catalogue page, 15 instead of 99 on the product page, memory at 10.84 MB, time 172 ms.
Why the memory doesn't move
The Storefront catalogue shows 16 products per page, always. Whether the store has 50 or 5,000 products, the HTTP request hitting the server works on the same subset of rows. That's why PHP peak usage stays at 10.80 MB regardless of catalogue size: anyone bumping up memory_limit because "I've got loads of products" is treating a symptom that the product count doesn't actually cause.
What does grow with the catalogue is the database: the wp_posts and wp_postmeta tables get bigger, indexes become heavier to maintain, backups take longer. Not PHP memory per request.
The Redis object cache does exactly what it promises: it strips out 80% of the queries (from 80 to 15 on the catalogue page, from 99 to 15 on the product page). It didn't cut response time, because on an unloaded machine the database wasn't the bottleneck.
The sums for sizing a server
For sizing purposes, what matters is the peak PHP usage per request (12 MB in our tests, because PHP allocates in 2 MB blocks) multiplied by the expected number of concurrent PHP requests, plus the room needed for the database, which grows with the catalogue.
Limitations of this measurement
Single request, no concurrency and no page cache, database on the same machine as the web server, simple products with no variations, no plugins beyond WooCommerce, Storefront and Redis Object Cache. A store running thirty active plugins will use more: these figures are the floor, not the ceiling.
How to replicate this on your own server
To read a request's peak memory usage: php -d memory_limit=-1 -r "echo memory_get_peak_usage(true);" inside a script that loads wp-load.php and generates the page. To count queries: enable SAVEQUERIES and read $wpdb->num_queries at the end of the request. For generation time: Query Monitor's timer, or a simple microtime(true) at the start and end of template_redirect.
Written with the help of artificial intelligence and checked by the editors (EU AI Act, art. 50).