PrestaShop 9 System Requirements: PHP, MySQL & Hosting

Choosing hosting for PrestaShop 9 should not begin with a marketing label such as “ecommerce hosting” or “optimized for PrestaShop.”

It should begin with the actual application requirements.

PrestaShop 9 has a modernized technical stack built around PHP 8.x, Symfony 6.4, MySQL or MariaDB, and a more demanding application architecture than a simple brochure website. A server that can technically install PrestaShop is not necessarily a server that can operate a real store reliably.

This guide covers the official PrestaShop 9 system requirements and, more importantly, explains how to translate those minimum requirements into a sensible production environment.

Version note: This article was verified on September 22, 2026. The current official requirements page recommends PHP 8.5 for PrestaShop 9.1. PrestaShop 9.1.5 is the latest stable 9.1 release at the time of writing.

PrestaShop 9 Requirements at a Glance

The current official PrestaShop 9 documentation lists the following baseline:

These values are a starting point.

A store with 500 products and ten orders per day may operate comfortably on modest infrastructure.

A store with:

• 100,000 products;
• millions of image files;
• thousands of combinations;
• supplier XML imports;
• marketplace synchronization;
• multiple stores;
• ERP integration;
• large cron jobs;
• many Back Office users;

has a completely different resource profile.

PrestaShop 9 PHP Compatibility

PHP is one of the first things you should verify before installing or upgrading PrestaShop 9.

PrestaShop 9.0

The official compatibility table currently lists:

• PHP 8.1 — supported
• PHP 8.2 — supported
• PHP 8.3 — supported
• PHP 8.4 — recommended
• PHP 8.5 — not supported for 9.0

PrestaShop 9.1

The current table lists:

• PHP 8.1 — supported
• PHP 8.2 — supported
• PHP 8.3 — supported
• PHP 8.4 — supported
• PHP 8.5 — recommended

That distinction matters.

Do not simply ask your hosting provider whether it “supports PHP 8.”

You need to know:

1. the exact PrestaShop version;
2. the exact PHP version;
3. whether your modules support that PHP version;
4. whether your theme or custom code has PHP compatibility problems.

Should You Always Use the Recommended PHP Version?

For a fresh installation, using the recommended PHP version is generally a good default.

For an existing production store, test first.

A module can be compatible with PrestaShop 9.1 but still contain code that breaks on PHP 8.5.

Typical PHP compatibility problems include:

• stricter parameter types;
• null passed where a string or number is required;
• removed or deprecated functions;
• dynamic property issues;
• incompatible Composer dependencies;
• old vendor libraries;
• invalid method signatures.

The correct process is:

clone production → switch staging to target PHP → test everything → deploy

Do not change PHP on a high-revenue store directly because the hosting control panel makes it look like a harmless dropdown.

Check Web PHP and CLI PHP Separately

This is a common source of confusion.

The PHP version used by your website may not be the same PHP version used in SSH or cron jobs.

For example:

php -v

may report PHP 8.3 while PHP-FPM serving the website uses PHP 8.5.

Likewise, a cron command such as:

php /var/www/shop/bin/console ...

may accidentally use the server's default PHP binary rather than the version configured for the store.

Always verify:

• web PHP;
• CLI PHP;
• cron PHP;
• supervisor/queue worker PHP.

They should use versions you have intentionally selected and tested.

PHP Memory Limit: Why 512M Matters

The current PrestaShop 9 documentation recommends setting the PHP memory_limit to a minimum of:

memory_limit = 512M

This is per PHP process, not total server memory.

That distinction is extremely important.

Suppose your PHP-FPM workers are allowed to consume up to 512 MB each.

If you configure 30 concurrent PHP workers, the theoretical PHP memory exposure becomes very large.

In reality, most requests will use much less, but you still need to size the worker pool based on measured usage.

Do Not Solve Memory Problems by Raising the Limit Forever

If an import process repeatedly hits 512 MB, the answer may not be:

memory_limit = 2048M

The real problem may be code that loads a complete supplier XML file or every product into memory.

A better architecture is:

Supplier file
    ↓
Streaming parser
    ↓
Batch of products
    ↓
Process
    ↓
Save progress
    ↓
Next batch

This keeps memory usage predictable.

The same principle applies to:

• CSV imports;
• image regeneration;
• catalog exports;
• sitemap generation;
• large database operations.

MySQL Requirements

The current official minimum for PrestaShop 9 is:

MySQL 5.7

However, the documentation recommends using a recent database version.

That is sensible.

The minimum version is useful for compatibility boundaries, but a fresh production environment should not deliberately be designed around an obsolete database release unless a specific infrastructure constraint requires it.

Your database version should also be supported by:

• your operating system;
• your hosting provider;
• backup tooling;
• monitoring stack;
• replication strategy, if any.

MariaDB Requirements

PrestaShop 9 currently lists:

MariaDB 10.2 minimum

Again, use a modern supported release for a new production deployment when possible.

Do not choose between MySQL and MariaDB based only on benchmark articles.

Operational competence matters more.

Use the database engine your team or hosting provider can:

• monitor;
• back up;
• restore;
• tune;
• upgrade safely.

Database Performance Is More Than Version Numbers

A modern database version cannot rescue poor database architecture.

Important factors include:

• InnoDB buffer pool size;
• disk latency;
• available RAM;
• slow-query monitoring;
• table size;
• indexes;
• connection limits;
• temporary-table behavior;
• query design.

PrestaShop can generate large datasets even with a moderate number of products.

One product may be represented across:

• product tables;
• language tables;
• shop tables;
• category associations;
• image tables;
• feature tables;
• attribute tables;
• stock tables;
• module-specific tables.

A catalog with 100,000 products may therefore involve millions of related rows.

Use the Slow Query Log

For large stores, database optimization should be based on evidence.

Enable and analyze the slow query log in a controlled way.

Look for queries that appear during:

• category loading;
• search;
• product editing;
• order grids;
• imports;
• stock synchronization;
• feed generation.

Then inspect them using:

EXPLAIN

Do not install random index packs downloaded from the internet.

An index should match a query your store actually executes.

Apache Requirements

The official PrestaShop documentation currently lists:

Apache 2.4 or later

Apache remains a perfectly valid platform for PrestaShop.

The web server should have the required rewrite support and a configuration that allows PrestaShop-friendly URLs and security rules to operate correctly.

Important areas include:

• rewrite rules;
• HTTPS redirects;
• static asset caching;
• upload limits;
• request body limits;
• compression;
• access controls.

If you use Apache with PHP-FPM, monitor both layers independently.

Can PrestaShop 9 Run on Nginx?

Yes.

PrestaShop supports Nginx, and the official developer documentation provides an advanced Nginx configuration example.

Nginx is commonly used for:

• reverse proxying;
• static asset delivery;
• PHP-FPM;
• TLS termination;
• caching;
• rate limiting.

One important detail for PrestaShop 9 is image handling.

Because PrestaShop 9 supports modern formats such as WebP and AVIF, your rewrite rules and static configuration should correctly handle those image extensions.

Do not copy an old PrestaShop 1.7 Nginx configuration without reviewing it.

Apache vs Nginx for PrestaShop 9

There is no universal winner.

A well-configured Apache installation can outperform a poorly configured Nginx installation and vice versa.

Choose based on:

• administrator experience;
• hosting support;
• deployment tooling;
• caching architecture;
• observability.

For many stores, the biggest performance problems are not the web server at all.

They are:

• slow modules;
• poor SQL;
• oversized images;
• too many PHP workers;
• heavy imports;
• slow disks.

Required PHP Extensions

PrestaShop requires several PHP extensions to operate correctly.

The official documentation explicitly lists extensions including:

• OpenSSL;
• PDO;
• PDO MySQL;
• SimpleXML;
• Zip.

Your hosting environment may also need other common extensions used by PrestaShop and modules.

Examples often include:

• cURL;
• GD;
• Intl;
• Mbstring;
• DOM;
• Fileinfo;
• JSON support provided by modern PHP.

Before installation, use the official PrestaShop requirements checker rather than assuming that a generic PHP package includes everything.

allow_url_fopen

The official PrestaShop 9 requirements currently specify:

allow_url_fopen = On

PrestaShop uses remote file access in parts of its workflow.

The documentation also recommends:

allow_url_include = Off

These are different settings.

allow_url_fopen permits supported PHP functions to access remote URLs.

allow_url_include allows remote files in PHP include operations and should remain disabled.

PHP Upload Limits

Stores that import products, modules, themes, or large data files should review:

upload_max_filesize
post_max_size
max_execution_time
max_input_time

Do not blindly set every limit to enormous values.

For large supplier feeds, CLI is usually a better solution than accepting a 1 GB upload through the Back Office.

A robust workflow downloads or receives the supplier feed through a controlled process and handles it in batches.

PHP-FPM Worker Configuration

If you use PHP-FPM, one of the most important settings is worker capacity.

Typical pool parameters include:

pm.max_children
pm.start_servers
pm.min_spare_servers
pm.max_spare_servers

There is no correct universal value.

Measure real PHP process memory.

For example, if an average busy worker consumes 150 MB and your machine has 8 GB RAM, configuring 50 PHP workers would be dangerous once you account for:

• MySQL;
• Redis;
• operating system;
• web server;
• cron jobs;
• filesystem cache.

Running out of memory can cause far more damage than making a user wait briefly for an available worker.

OPcache Should Be Enabled

A production PrestaShop server should use PHP OPcache.

OPcache stores compiled PHP bytecode in memory so PHP does not need to parse and compile every file on every request.

For a large PrestaShop installation with many modules, OPcache needs enough memory to keep useful code cached.

Monitor:

• OPcache memory usage;
• cached script count;
• restart frequency;
• hit rate.

Do not simply enable it and assume the default configuration is optimal.

Server RAM: How Much Do You Really Need?

PrestaShop's official requirement says, effectively, that more RAM is useful and recommends at least 512M memory allocation per PHP script.

But this does not mean a production server needs exactly 512 MB of total RAM.

A rough practical view:

Small store

A small low-traffic store may operate with:

• 2–4 GB RAM;
• limited PHP worker count;
• modest database;
• few background jobs.

Medium store

A more active store may benefit from:

• 4–8 GB RAM;
• more PHP workers;
• larger InnoDB cache;
• Redis;
• regular imports.

Large catalog or busy store

Stores with large catalogs and heavy automation may need:

• 8–32 GB RAM or more;
• dedicated database resources;
• separate job workers;
• carefully sized PHP pools.

These are not official PrestaShop requirements.

They are capacity-planning examples.

The correct answer comes from measuring your workload.

CPU Requirements

PrestaShop does not require a specific CPU model.

What matters is workload.

PHP benefits from strong per-core performance, while concurrent traffic and background jobs benefit from additional cores.

CPU-intensive tasks include:

• image resizing;
• AVIF encoding;
• large imports;
• feed generation;
• search indexing;
• cache rebuilding;
• XML processing.

If a shop runs customer traffic and multiple heavy imports simultaneously, additional cores can provide useful headroom.

Storage: SSD or NVMe

For modern PrestaShop hosting, SSD should be considered the baseline.

NVMe is especially useful for:

• large databases;
• many random reads/writes;
• image-heavy catalogs;
• cache-heavy workloads;
• high concurrency.

Mechanical hard drives can still serve backup or archival roles, but they are a poor choice for active ecommerce database workloads.

Watch Inode Usage

Image-heavy PrestaShop installations can create huge numbers of files.

Each product image may generate multiple image types.

If you have:

100,000 products
× 3 images
× 8 image types

you can easily reach millions of generated files.

Some hosting plans impose inode limits.

A server may therefore report plenty of free disk space while refusing to create more files because the inode quota is exhausted.

Monitor both:

• storage capacity;
• inode consumption.

Image Formats in PrestaShop 9

PrestaShop 9 introduced native support for:

• WebP;
• AVIF.

These formats can significantly reduce image transfer size.

However, AVIF encoding can require more CPU.

If you regenerate hundreds of thousands of images, plan that work as a maintenance operation or CLI task rather than running it during peak traffic.

Disk Space Planning

Do not size storage only around the current product image directory.

Also account for:

• database;
• logs;
• cache;
• temporary imports;
• backups;
• generated thumbnails;
• staging copies;
• deployment releases;
• export files.

A safe server needs spare space.

Operating permanently at 90–95% disk usage leaves little room for temporary operations and increases incident risk.

Operating System

PrestaShop's official documentation states that it works best on Unix-based systems such as:

• Linux;
• macOS.

For production hosting, Linux is the normal choice.

Windows may work in some scenarios but is not actively supported in the same way.

A typical production stack may use:

Linux
Nginx or Apache
PHP-FPM
MySQL/MariaDB
Redis
Cron/systemd

Is Shared Hosting Enough?

Shared hosting can be sufficient for:

• a small catalog;
• low traffic;
• minimal automation;
• a small number of modules.

The limitations usually become visible when you need:

• long-running CLI jobs;
• custom PHP settings;
• high worker limits;
• Redis;
• large imports;
• SSH;
• custom Nginx configuration;
• process supervision;
• detailed monitoring.

A shared plan may advertise generous disk space while heavily restricting CPU or process time.

Read the actual limits.

When Should You Choose a VPS?

A VPS is useful when you need predictable control over:

• PHP version;
• PHP-FPM;
• database configuration;
• cron;
• Redis;
• filesystem;
• web server;
• logs;
• security tools.

For stores with serious imports, custom modules, or tens of thousands of products, a VPS often becomes more practical than constrained shared hosting.

It also makes development and production environments easier to standardize.

Dedicated Server or Cloud Infrastructure

A dedicated server or larger cloud environment becomes useful when:

• traffic is consistently high;
• catalog jobs are heavy;
• database size is large;
• many staff work in Back Office;
• availability requirements are strict.

Do not split everything into microservices simply because the store is large.

A powerful single host with a well-configured database can be easier to maintain than an unnecessarily complex distributed architecture.

Scale when measurements justify it.

Redis and Caching

Redis can help in architectures that use it correctly for:

• cache;
• sessions;
• queues;
• locks.

It is not a universal “make PrestaShop fast” switch.

If a product page spends most of its time running an unindexed SQL query, Redis will not solve the underlying problem.

Use caching after measuring where time is spent.

CDN

A CDN is useful for static assets such as:

• product images;
• CSS;
• JavaScript;
• fonts.

Benefits include:

• lower origin traffic;
• faster delivery for distant visitors;
• improved cache hit rates;
• reduced bandwidth pressure.

But a CDN does not make slow PHP or database queries disappear.

Measure TTFB separately from asset download time.

Cron and CLI Access

For a serious PrestaShop store, SSH and cron access are extremely valuable.

Long jobs are better executed through CLI:

php bin/console ...

or module-specific commands.

Examples:

• product imports;
• stock updates;
• image optimization;
• category synchronization;
• feed generation;
• housekeeping.

CLI avoids many browser and proxy timeouts.

Large Stores Need Workload Separation

If your store imports 100,000 products every night, that background work competes with customer traffic.

A better design uses:

• bounded batches;
• queues;
• worker limits;
• locks;
• off-peak schedules.

For example:

Web traffic → PHP-FPM pool
Product import → CLI worker
Image processing → dedicated worker
Stock sync → small frequent cron
Database → shared but monitored resource

This prevents one giant job from consuming the whole server.

Backup Requirements

Hosting is incomplete without backups.

Keep backups of:

• database;
• files;
• product images;
• module configuration;
• environment configuration.

Do not store the only backup on the same disk as production.

A disk failure should not destroy both the store and its backup.

Test Restores

A backup status of “successful” proves only that a program created a file.

It does not prove that you can rebuild the store.

Regularly restore into a test environment and verify:

• database imports;
• images exist;
• Back Office works;
• modules load;
• cron definitions are known;
• environment variables are available.

HTTPS Is Mandatory in Practice

A production ecommerce site should run entirely over HTTPS.

This protects:

• account credentials;
• sessions;
• API communication;
• checkout data.

Use modern TLS configuration and automate certificate renewal.

Also ensure that:

• HTTP redirects to HTTPS;
• canonical URLs use HTTPS;
• internal links do not create mixed content.

Email Delivery Is Part of Hosting

Order confirmation, password reset, support messages and account notifications depend on reliable email delivery.

Use a suitable transactional mail provider or correctly configured SMTP service.

Monitor:

• delivery errors;
• authentication;
• SPF;
• DKIM;
• DMARC.

A perfect server is not enough if customers never receive order confirmation emails.

Logging and Monitoring

A production PrestaShop stack should provide access to:

• Nginx/Apache access logs;
• Nginx/Apache error logs;
• PHP errors;
• PrestaShop logs;
• database slow queries;
• system metrics;
• cron logs.

Monitor:

• CPU;
• RAM;
• disk;
• inode usage;
• PHP worker saturation;
• database connections;
• HTTP 5xx errors;
• job duration.

Without monitoring, capacity problems are only discovered after customers complain.

Development Requirements

If you work with a development version of PrestaShop rather than an installed production package, the official documentation also lists developer tooling.

PrestaShop uses Composer for PHP dependencies.

Current documentation also specifies Node.js 20.x for the relevant development workflow.

Production merchants installing a packaged PrestaShop release do not normally need to compile the entire platform themselves.

Module and theme developers, however, should maintain a compatible development toolchain.

Docker for PrestaShop Development

Docker can be extremely useful for development and testing because it makes versions explicit.

A development stack can pin:

• PHP;
• MySQL/MariaDB;
• web server;
• Redis;
• mail testing.

This helps reproduce bugs and test module compatibility.

Production Docker is also possible, but containerization does not automatically make an application scalable.

You still need:

• persistent database storage;
• backup design;
• image storage;
• logging;
• worker architecture;
• deployment strategy.

Example Small Production Architecture

A small but serious store might use:

1 VPS
├── Nginx
├── PHP-FPM
├── PrestaShop 9
├── MariaDB/MySQL
├── Redis
└── cron / CLI workers

This architecture is simple and easy to troubleshoot.

Example Larger Architecture

A larger store might evolve into:

Load Balancer / CDN
        ↓
Application Servers
        ↓
PHP-FPM
        ↓
Redis
        ↓
Database Server
        ↓
Backup / replica

Separate workers:
- imports
- images
- feeds
- stock sync

Do not start here unless your traffic and operations justify the extra complexity.

PrestaShop 9 Hosting Checklist

Before launching, verify:

• exact PrestaShop version selected
• supported PHP version configured
• web PHP version checked
• CLI PHP version checked
• cron PHP version checked
• required PHP extensions installed
• memory_limit at least 512M where appropriate
• allow_url_fopen enabled
• allow_url_include disabled
• MySQL/MariaDB version supported
• database backup automated
• database restore tested
• SSD/NVMe storage
• sufficient free disk space
• inode usage monitored
• OPcache enabled
• PHP-FPM pool sized
• HTTPS enabled
• transactional email tested
• cron available
• SSH/CLI available for maintenance
• web-server logs accessible
• PHP logs accessible
• slow-query monitoring available
• system monitoring active

Frequently Asked Questions

What PHP version does PrestaShop 9 require?

PrestaShop 9.0 supports PHP 8.1 through PHP 8.4, with PHP 8.4 recommended. PrestaShop 9.1 supports PHP 8.1 through PHP 8.5, with PHP 8.5 recommended according to the current official requirements table.

Does PrestaShop 9 support PHP 8.5?

Yes, PrestaShop 9.1 supports PHP 8.5 and currently recommends it. PrestaShop 9.0 does not list PHP 8.5 as supported.

What is the minimum MySQL version for PrestaShop 9?

The official minimum is MySQL 5.7. A recent supported release is recommended for new deployments.

What is the minimum MariaDB version?

The official minimum is MariaDB 10.2.

How much PHP memory does PrestaShop 9 need?

The official documentation recommends a minimum memory_limit of 512M per script. The server itself needs enough RAM for PHP workers, database, OS, cache and background jobs.

Can PrestaShop 9 run on Nginx?

Yes. Nginx is supported and PrestaShop provides configuration guidance.

Is 2 GB RAM enough?

It may be enough for a small low-traffic store with carefully limited PHP workers, but resource requirements depend on catalog size, modules, imports and database workload.

Is 8 GB RAM enough for 100,000 products?

Potentially, but product count alone is not enough to answer. Combinations, images, traffic, imports, modules, database size and worker concurrency matter.

Do I need Redis?

No. Redis can be useful for caching, sessions, queues or locks in the right architecture, but it is not a mandatory requirement for every store.

Should I choose shared hosting or a VPS?

Shared hosting can work for smaller stores. A VPS is usually more practical when you need control over PHP, cron, Redis, imports, logs and server tuning.

Related PrestaShop 9 guides and resources

• safe PrestaShop 8 to 9 upgrade guide
• PrestaShop 9 performance optimization
• PrestaShop 9 module development guide