PrestaShop performance limits: tune, upgrade or leave

The official PrestaShop documentation does not state a maximum size or a traffic capacity: it gives tuning advice and tells you to benchmark your own shop. So when PrestaShop reaches its limits, work in this order. Measure the bottleneck, apply the official server settings, review your modules, upgrade to a current version, and consider leaving for Shopify Plus, BigCommerce or a custom build only if a measured limit remains. Many slow stores can improve before that last step, but only a benchmark can tell you whether yours will.

Facts below come from PrestaShop's documentation and vendor pricing pages, read on 1 November 2026. I build shops with Sylius and custom code, so I have an interest in the last option of this article. I will flag it when I get there.

PrestaShop performance and scalability: what the official documentation says

The optimization guide is short and practical. It asks for OPcache with a generous memory pool (the example uses 256 MB), the File System cache type instead of MySQL, the Smarty cache enabled, and an InnoDB buffer pool sized to your memory. It warns that badly configured Smarty caching, including from modules, can scatter files across the server and cause heavy disk activity. Multi front synchronisation should stay off with a single front server or a shared Smarty cache.

The only capacity claim I found there is modest: an Apache example "should allow you to test up to 400 concurrent users". That is a test configuration, not a guarantee. The benchmark guide gives no results either. It explains how to generate a dataset with an entity count of your choice, turn off debug mode, and record hardware and settings. The default makes a small shop of about 100 products, so increase it to match your real catalog.

This is the most useful lesson in the documentation: nobody can tell you PrestaShop's limit for your store. Generate a copy with your catalog size, run a load test, and change one thing at a time.

Where the Symfony migration stands

Buyers often ask whether PrestaShop has finished moving to Symfony. Not entirely, and the project is open about it. Version 9.0 moved to Symfony 6.4, a long term support release with security updates through November 2027, and PrestaShop says its back office is now fully rendered with Symfony and Twig. It also introduced an Admin API on API Platform, described as a work in progress.

The migration of individual pages continues. PrestaShop 9.2, announced on 30 September 2026, adds six more migrated back office pages behind a feature flag: Countries, Merchandise Return, Hook a module, Quick Access, Email body translations and Tax rules. A 2022 post from the project explained the cost: as long as one legacy page remains, the legacy stack, including ObjectModel and Smarty, must stay in place and be maintained. Those figures are dated, but the principle still applies when you judge old modules that rely on legacy parts.

The takeaway for a merchant is practical. The Symfony work matters for long term maintenance. It will not by itself speed up a slow category page, so do not treat it as a performance promise.

Should you upgrade first?

If you run an old version, usually yes. The 9.0 announcement mentions lower memory use, WebP and AVIF images and better product page performance on large catalogs, without benchmarks. The 9.2 changelog lists specific fixes, such as paginating the orders grid by ID to avoid a full table sort. The system requirements recommend at least 512 MB for memory_limit, and the 9.2 notes support PHP 8.1 up to 8.5.

Do not underestimate the work. The help center calls version 9 a major version with incompatible changes, and the announcement warns that modules and themes may need updates. The official tool is the Update Assistant module, which can also run from the command line. I did not find an official statement in my reading covering every old starting version, so verify yours before you plan, and test on a copy. My guide to the developer documentation helps you audit overrides and modules first.

Alternatives: Shopify Plus, BigCommerce or a custom build

Note that a hosted platform solves the server problem and nothing else. It will not fix a catalog with poor data, a heavy theme or too many scripts. If your issue is really a tangle of business rules, hosted platforms may even make it harder. This is the option in which I have a commercial interest, as I work with Sylius, and it is worth it only with a budget for lasting maintenance. For a data view of the move, my article on the PrestaShop database schema shows what must be mapped.

When to leave and when to stay

Stay if your problem disappears on a tuned staging server, if your modules explain the slowness, or if your team knows the platform well. Consider leaving if a benchmark on tuned infrastructure still fails at your realistic peak, if key modules have no compatible path to a supported version, or if your business rules now fight the core. If you need an uninterrupted 24 hour on-call service for high seasonal peaks, a larger agency will suit you better than an independent like me.

Next step

Collect your PrestaShop and PHP versions, your module list, your overrides, and the three pages that hurt most at peak. That is enough for a first diagnosis. You can request a first look through my free site audit, or describe your project on my ecommerce page. I reply within 24 working hours, and you speak directly with the person who writes the code. If tuning is all you need, that is what I will tell you.