A merchant lists 80,000 product references, 15,000 active online. The category page takes eight seconds to load. The agency recommends a 32 GB dedicated server. Profiling tells a different story: a four-second SQL query, a filter module joining six tables, and Smarty cache disabled to "ease debugging". The real limit was not PrestaShop itself — it was listing architecture on a dense catalogue.
This scenario repeats on shops that grew gradually. The back office displays tens of thousands of product records correctly, which reassures the commercial team. Yet customers do not browse the admin: they open categories, run searches, compare variations. Load concentrates there, long before the host's CPU hits its ceiling.
The useful question is therefore not "how many products can PrestaShop handle?" It is more concrete: which query is your visitor waiting on first, and what slows it — the database, a module, missing cache, or finally the infrastructure?
Where the limit shows up in practice
On a large catalogue, bottlenecks spread across distinct layers. MySQL struggles first on listings and product admin when indexes are missing or ps_product* tables grow without maintenance. Native search becomes painful once facets multiply joins. Smarty or object cache, if absent or poorly invalidated, leaves high response times even when the server looks idle.
Third-party modules amplify the problem: poorly optimised faceted filters, marketing extensions running on every category page, synchronous CSV imports blocking the shop during business hours. Images not served from a CDN can absorb significant bandwidth without alone explaining eight seconds of latency, but they worsen perceived experience.
| Area | Symptom | Lever |
|---|---|---|
| MySQL database | Slow listing, admin products | Indexes, cleanup, read replica |
| Native search | Search timeout or slowness | Elasticsearch, Algolia |
| Smarty / cache | Constant high response time | Page cache, Redis |
| Facet modules | CPU spike on categories | Refactor or dedicated service |
| Images | Saturated bandwidth | CDN, modern formats |
| CSV imports | Shop lock | Async queue, off-peak hours |
A large catalogue exposes poorly designed joins — not the PrestaShop brand itself.
Hosting: beyond vCPU count
Comparing hosts on vCPU count alone hides what actually matters for PrestaShop. Disk I/O determines query speed on large tables: local NVMe or equivalent beats slow shared storage. RAM must size the MySQL buffer pool; eight gigabytes is often the comfort threshold for a heavy catalogue with active cache.
Redis serves both sessions and Smarty or object cache when the application is configured correctly. On PHP, target 8.1 or newer, enable OPcache, and adjust max_execution_time for scheduled imports. Reliable cron is essential for indexing, cache cleanup and queues. Finally, staging lets you test imports and modules without blocking production.
Shared hosting rarely fits heavy catalogues with advanced filters. A VPS or shop-dedicated cloud is more realistic once listings exceed a few seconds despite an optimised database. To compare commerce-oriented offers, see our host directory and MySQL for dynamic sites.
Application optimisations before server upgrade
Before raising hosting spend, check the most frequent application gains. Missing indexes on filtered attributes, id_category and active sometimes turn a six-second query into a few hundred milliseconds. Disable listing modules one by one while measuring page generation time: tedious, but it often identifies the culprit in one morning.
Enable cache with a documented invalidation strategy: without clear rules, you trade slowness for stale data. Externalise search once listing SQL exceeds several hundred milliseconds despite indexes. A CDN for product images reduces perceived page weight — often around seventy percent of total weight. Schedule night imports with partial maintenance mode to avoid saturating the database during the day.
If you hesitate between e-commerce stacks, Magento is not a heavy WordPress helps situate PrestaShop against other catalogue platforms.
Signals the host has become the ceiling
Infrastructure becomes the limiting factor when application tuning is done and symptoms persist. CPU below forty percent while disk I/O wait stays permanently high indicates a disk bottleneck, not CPU. A MySQL slow log filling despite correct indexes suggests undersized memory or storage. RAM saturated by an undersized buffer pool forces repeated disk reads. High network latency to a remote managed database penalises every page.
Then tier upgrade or co-locating app and database makes sense. As long as profiling shows a dominant SQL query, a bigger server only pays more for the same slowness.
The summit: the catalogue reveals module debt
Magento and WooCommerce are not alone with massive catalogues. PrestaShop is lighter in theory but more sensitive to third-party modules on listings. Comparing stacks only makes sense if you measure the same category page, not the same reference count in the database.
Decide and move forward without blind spots
Start by profiling a representative category page and internal search, with the same filters your visitors use most. Then audit modules involved in listing and facets, in staging if possible. Enable object cache and Redis if not already in place, then size MySQL for memory and indexes before considering a host change. Upgrade infrastructure only after hard evidence: query time, CPU load, disk wait. Browse e-commerce hosts in our directory and comparison tool using those measurements, not a generic "bigger server" recommendation.
Frequently asked questions
How many products can PrestaShop handle?
There is no official cap. Shops run 100,000+ product references with an adapted architecture. Without cache, SQL indexes and tuned modules, issues often start between 5,000 and 20,000 active references, especially with heavy faceted filters.
What minimum RAM for a large catalogue?
Plan 4 GB for a well-optimised mid-size shop, and 8 GB or more with external search, many modules or frequent imports. Shared hosting rarely fits beyond a few thousand products with advanced filters.
Is Elasticsearch mandatory?
No, but native SQL search slows on large catalogues with facets. Elasticsearch or Algolia makes sense when listing queries exceed several hundred milliseconds despite indexing.
How do you tell if modules are the problem?
Temporarily disable marketing, filter and SEO modules in staging, then compare category page generation time. Poorly coded listing modules remain one of the most frequent causes on dense catalogues.
With 80,000 references, the question is not "which host?" — it is "which SQL query is your customer waiting on first?"