PrestaShop 9: features, performance and architecture

The official PrestaShop 9 documentation describes a real change of architecture: Symfony 6.4, a back office rendered with Symfony and Twig, and a new Admin API built on API Platform. On performance, it lists concrete improvements but publishes no benchmark figures in the pages I read. So if your shop has reached its limits, PrestaShop 9 may help, but only a measurement on your own catalogue can tell you whether it solves your problem.

A disclosure: I build and take over custom and Sylius shops, so I have an interest in the case where PrestaShop is no longer enough. For many merchants it remains a sound choice, and I say below when to stay. Every fact here links to the PrestaShop project's own pages, which I read on 1 November 2026.

PrestaShop 9 official features: what actually shipped

PrestaShop 9 became available on 10 June 2025. Version 9.1 followed on 23 March 2026, and maintenance continued with 9.1.4 on 4 June 2026. Check the project's news page for anything newer before you plan work.

The word that matters on that last row is experimental. The 9.1 announcement places multi carrier orders behind a feature flag and recommends testing outside production. If your current limit is splitting orders between warehouses, this is a lead to test, not yet something to build a logistics process on.

Architecture: why it matters to a merchant

The official release page states that Symfony 6.4 is a long term support version with security updates until November 2027. That date gives you a planning horizon: ask your supplier today what the project expects after it, rather than discovering it in late 2027.

The back office moved further towards Symfony and Twig, with Login, Products, Orders, Attributes and Statuses among the migrated pages, and the old product page was removed. If a developer customised that old page, this work does not carry over by itself. The developer documentation describes the Admin API as based on API Platform, secured with OAuth, and organised around business domains rather than the older web services object model. In plain terms, connecting an ERP or a warehouse tool could become cleaner, provided the endpoints you need exist. PrestaShop itself called the API unfinished at the 9.0 launch, so ask for an endpoint by endpoint check.

PrestaShop 9 performance: what is documented, and what is not

The announcements mention native WebP and AVIF images, presenter based rendering for some front office elements, and better product page performance on large catalogues. Version 9.1 adds faster carts when a shop has many product combinations, plus quicker admin notifications. These are useful, but they are claims without published numbers, so nobody can honestly promise you a percentage.

The system requirements give the baseline: MySQL 5.7 or MariaDB 10.2 at minimum, a recent version recommended, and a PHP memory limit of at least 512M. These are minimums, not a sizing guide. A large catalogue with many combinations needs testing on a copy of your real data.

When a shop feels slow, my professional view is that the cause is often elsewhere: an accumulation of modules, a heavy theme, undersized hosting or database queries that were never reviewed. Upgrading will not repair any of these by itself, and it can hide them for a few weeks.

Your shop has hit its limits: what to do, in order

First, name the limit. Is it page speed, back office slowness, a business rule the platform cannot express, or an integration? Each one has a different answer. Then measure your five slowest pages and your slowest back office screens, so you have a reference point.

Second, audit your modules. The upgrade documentation says to check marketplace modules against their compatibility range and to assume custom modules are incompatible until proven otherwise. The 9.1 notes add that the Update Assistant detects incompatible modules and uninstalls those that do not support 9.1. Removing a module that handles your invoices or carriers on a live shop would be costly, so the inventory comes first.

Third, rehearse on staging. Back up files and database, run the upgrade on a copy, replay real orders, and only then schedule production. If you are still on 1.7 or 8, get a written estimate, because the jump includes theme and module work beyond the upgrade itself. Developers will find the structure explained in my guide to the PrestaShop developer documentation.

When to stay on PrestaShop, and when to leave

Stay if your process is fairly standard, your modules have compatible versions and your team knows the back office. An upgrade and some tuning will almost always cost less than a migration, and they carry less risk for your search rankings and your daily operations.

Consider leaving when, on a clean and current installation, your rules still fight the platform: pricing logic that needs layers of overrides, integrations that keep breaking at each update, or a custom core that nobody dares touch. Even then, the alternative must earn its place. A hosted platform such as Shopify suits a standard process, while a framework such as Sylius suits custom rules and assumes a developer stays involved. A migration has its own risks, including lost redirects and rebuilt integrations.

What to ask before you decide

Ask any supplier, including me, for the list of modules they would keep, replace or drop, the measured baseline they will compare against, and the rollback plan if the upgrade fails. Be wary of anyone who promises a speed gain before looking at your shop.

If you want a second opinion, my ecommerce page explains how I work. Send me your version, your catalogue size and what is blocking you. I reply within 24 working hours, you speak directly to the person who writes the code, and if staying on PrestaShop is the better answer, I will tell you.