Choosing hosting for PrestaShop: what matters and what is marketing

Here is the uncomfortable truth most hosting comparison articles bury: the spec sheet you're shown when you buy hosting and the things that actually decide whether your PrestaShop store feels fast barely overlap. The provider advertises CPU cores, "NVMe storage" and "unlimited bandwidth"; PrestaShop, meanwhile, cares about your PHP version, how much memory a single request is allowed, whether OPcache is on, and how close the MySQL server sits to the PHP process. You can pay for a bigger plan and feel nothing, or pay the same money on a host that's configured for PHP applications and watch your time-to-first-byte halve. This guide is about reading a hosting offer the way PrestaShop reads it, separating the line items that move page generation time from the ones that exist to win the comparison-table war.

Reviewed June 2026 against PrestaShop 1.7.8, 8.x and 9.x hosting requirements. We run mypresta.rocks on a VPS we tune ourselves. The checklist below reflects those hosting decisions; measure performance on your own storefront under a stated test configuration.

To be clear about scope: this post is about choosing the box your store sits on. It is not the tuning guide (that's performance tuning from database queries to full page cache), not the "why is my store slow" diagnosis (what actually makes PrestaShop slow), and not the cache-module breakdown (full page cache modules explained). Hosting is one of the three legs, database, modules, hosting, and here we stay on the hosting leg.

What PrestaShop actually demands from a server

Before you compare a single plan, it helps to know what PrestaShop does on every uncached request, because that's what you're really buying capacity for. A front-office page render boots the PHP framework, loads the active modules, runs the hooks registered against that page, executes a stack of SQL queries (a category page with layered navigation can fire dozens), renders Smarty templates, and assembles the response. That is a PHP-and-MySQL workload, not a static-file workload. So the resources that matter are the ones that make PHP execute fast and let MySQL answer quickly. Not the ones that make a brochure look generous.

PrestaShop's own minimums are a floor, not a target. The platform documents a requirement of PHP and a MySQL/MariaDB database with InnoDB, but the supported PHP version splits by branch: PrestaShop 1.7.8 tops out at PHP 7.4, PrestaShop 8 runs on 7.4/8.0/8.1 depending on the minor release, and PrestaShop 9.x requires PHP 8.1+. A host that's still defaulting you to PHP 7.2 in 2026, or that can't offer 8.1, is telling you something about how current the rest of their stack is.

What actually matters. Read the offer like PrestaShop does

php -i | egrep 'opcache.enable|opcache.memory_consumption|memory_limit'
mysql -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"
curl -o /dev/null -s -w 'TTFB: %{time_starttransfer}s\n' https://www.example.com/

These are the line items that change how a real PrestaShop request performs. If a host is vague on any of them, that vagueness is the answer.

So what does this list actually buy you? Peace of mind that the money you spend lands where PrestaShop feels it. The two items at the top, current PHP and OPcache, are frequently the difference between a sluggish store and a quick one, and they cost nothing extra; they're a configuration choice, not a plan upgrade. If a salesperson can't tell you your PHP version and whether OPcache is on, you're talking to the wrong host.

What is mostly marketing

None of the following is a lie, exactly. Each is a true statement engineered to look like a benefit while telling you nothing about how your store will perform.

"Unlimited" storage / bandwidth / databases. Nothing is unlimited; there's a fair-use clause, and a PrestaShop store that actually uses resources will eventually meet it. The word "unlimited" mostly means "we chose not to print the limit." Worse, unlimited plans are usually heavily oversold shared boxes. The generosity on paper is funded by packing more sites onto the server, which is exactly the thing that makes your store unpredictable.

"Optimized for PrestaShop." Sometimes this is real (a sane PHP build, OPcache, MySQL tuned for InnoDB, maybe a cache layer wired up). Sometimes it means someone installed PrestaShop once and added the phrase to the sales page. The test is specific and fair: ask "which PHP version, is OPcache on, what's the default memory_limit, and is Redis or Memcached available?" A host that genuinely optimizes answers instantly. A host that printed a badge goes quiet.

"99.9% uptime guarantee." Everyone claims it, and 99.9% still permits roughly 8.7 hours of downtime a year. The guarantee is almost always backed by service credits, a few cents refunded, not compensation for lost orders. Treat it as table stakes, not a differentiator, and measure real uptime yourself with an external monitor.

"CPU cores" and "RAM" as headline numbers. A 4-core plan that pins you to PHP 7.2 with OPcache off will lose to a 2-core plan on PHP 8.2 with OPcache on. Raw resource counts only matter once the software stack underneath them is current. Read the stack first, the spec second.

"Free migration." A PrestaShop migration is files plus database plus the parameters.php config plus cron jobs plus SSL plus URL rewrites. Some hosts do all of it; others copy files and hand you the breakage. Ask exactly what "migration" includes, in writing, before you commit.

The hosting tiers, and which PrestaShop store each one fits

The categories matter less than matching the tier to your actual traffic and how much server administration you're willing to own.

The honest read: most PrestaShop stores are best served by a VPS, because the things that decide performance, PHP version, OPcache, memory limits, a local Redis, are exactly the things shared hosting won't let you touch and managed hosting charges a premium to handle. On a VPS you can set them yourself, once, and keep the difference. The catch is that you (or someone) has to be willing to do basic server administration; if that's a hard no, managed hosting buys back the time honestly.

A buying checklist you can run in five minutes

Before you pay, get a yes to each of these, by email if the sales page won't say:

• "Can I select PHP 8.1 or newer per site, and switch it myself?" No self-service PHP switching is a red flag for an ageing platform.
• "Is OPcache enabled by default?" If they don't know what OPcache is, end the call.
• "What memory_limit do I get, and can I raise it to 512M for the admin?" Below 256M will fight you on imports and updates.
• "Is the MySQL database on the same server or local network?" A remote shared DB adds latency to every query on every page.
• "Is Redis or Memcached available?" You don't have to use it today, but you'll want it later, see below.
• "Free Let's Encrypt SSL?" HTTPS is mandatory for a shop; a host charging for SSL in 2026 is a red flag.
• "What exactly does a backup include, and how long is it retained?" You want automated daily backups, 7-day retention minimum, and you keep your own offsite copy regardless, because a backup you've never restored isn't a backup.

Good hosting still needs configuration, and that's a different job

Buying the right box is half the work; the box still has to be set up. The highest-leverage server settings for PrestaShop are OPcache (so PHP source isn't recompiled every request), HTTP/2 or HTTP/3, and Brotli/Gzip compression on text responses. Two of those, OPcache and compression, are usually a host-side toggle; if they're off, turning them on is the cheapest speed-up you'll ever make.

On a VPS where you own these files, two settings carry most of the server-side win. OPcache stops PHP recompiling your store on every request, sane production values for a PrestaShop install look like this (drop into a .ini loaded by your PHP-FPM pool):

opcache.enable=1
opcache.memory_consumption=192
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=60

PrestaShop ships a large file count, so max_accelerated_files needs to be generous or OPcache evicts your own code; 192MB of OPcache memory comfortably holds an 8/9 store plus its module stack. On PHP 8 the bigger lever is the JIT, which is part of OPcache, for a CPU-bound store it's the single largest free gain newer PHP gives you, and it's a reason not to settle for a host stuck on 7.x.

The matching MySQL/MariaDB lever is the InnoDB buffer pool. The RAM cache that keeps your product and category tables out of disk reads. In my.cnf (or a /etc/mysql/conf.d/ drop-in):

[mysqld]
innodb_buffer_pool_size = 1G
innodb_buffer_pool_instances = 1
innodb_flush_log_at_trx_commit = 2

Size the buffer pool so your working set fits, a few hundred MB of catalogue data wants at least that much pool, and a comfortable rule on a dedicated DB box is roughly half to two-thirds of system RAM. The point of the hosting decision is that on shared hosting you can set none of this; on a VPS you set it once and keep the difference. That's the whole argument for a VPS in three lines of config.

One configuration topic deserves a separate guide: object caching with Redis. A compatible module or cache integration can let PrestaShop use Redis for cached data. PHP session storage is configured separately; enabling a cache module does not automatically move sessions into Redis. Whether this improves response times depends on the workload and configuration. The setup and trade-offs are covered in Redis for PrestaShop and the step-by-step Redis cache setup and performance gains. For your hosting decision, confirm that Redis is available and that you can configure the integration your store needs.

How to verify a host instead of trusting the plan

A good host still needs PrestaShop cache settings checked after deployment.

for i in 1 2 3 4 5; do
  curl -o /dev/null -s -w "%{time_starttransfer} %{url_effective}\n" https://www.example.com/product-url
done

Specs are claims; measure the reality. The cleanest test is to put a real PrestaShop store on the host and read its actual behaviour rather than its brochure:

• Time to first byte (TTFB) on an uncached page. Disable full page cache, hit a category page, and look at TTFB in your browser's network panel. This is the rawest signal of how fast the server generates a PrestaShop page. A good VPS on current PHP with OPcache typically lands well under half a second; a struggling shared box can run several times that.
• The back office's built-in checks. Advanced Parameters → Information reports your PHP version, memory_limit and key extension status; the Advanced Parameters → Performance page shows your caching configuration. These tell you what the host actually gave you versus what was advertised.
• PageSpeed only after caching is on. Don't judge a host by a cold PageSpeed run, that mixes server speed with front-end optimisation. We pulled a near-perfect score out of a fully-loaded real store and documented exactly what moved the needle in PageSpeed 99/100 on a real PrestaShop store with 130 modules.

If you've run these and the store is still slow, the bottleneck probably isn't the host. Before you upgrade your plan in the hope of buying your way out, diagnose it: is your store slow. How to check and what to do about it, and remember that a database that's bloated over years will drag a perfectly good server (database cleanup: why your store gets slower over time).

Hosting questions store owners actually ask

Is more RAM or more CPU the upgrade that makes PrestaShop faster? Usually neither, until the software stack is current. A page render is single-request PHP plus MySQL, so the first wins are PHP 8 with OPcache on and enough memory_limit to finish the request. Those cost nothing and routinely beat buying cores. CPU matters once you're saturating it under real concurrency; RAM matters mainly so the InnoDB buffer pool and your PHP workers both fit. Fix the version and OPcache first, then read whether you're actually resource-bound.

Will a faster host fix a slow back office? Partly. The admin's pain is usually memory_limit (imports and translations exhaust 128M) and slow queries, not raw server speed, so a host that lets you raise memory_limit to 512M and runs a tuned InnoDB buffer pool helps more than a bigger CPU. If the front office is fast but the admin crawls, look at memory and the database before you blame the plan.

Can I run Redis on shared hosting? Almost never. Redis needs a running daemon and shell access that shared plans don't give you. If a store is big enough to need Redis it's usually big enough to justify a VPS, which is the same box that lets you set OPcache, memory_limit and the InnoDB buffer pool yourself. Confirm Redis (or Memcached) is available before you assume a plan is "Redis-ready"; the full case for it is in Redis for PrestaShop.

Does managed PrestaShop hosting make a performance module redundant? No, they cover different layers. Managed hosting owns the server: PHP version, OPcache, backups, patching. It does not extract critical CSS, purge unused selectors, split and defer your JavaScript, or serve AVIF. That's front-end asset work that lives in the application, not the server. A tuned host plus a front-end pipeline like Performance Revolution is the combination that holds a real store fast; the host alone leaves the payload problem untouched.

How do I prove a host is fast before I migrate? Put a real PrestaShop page on it and read TTFB on a cache-cold category page (the curl loop above, or your browser's Network tab). A current-PHP VPS with OPcache usually lands well under half a second; a struggling shared box runs several times that. Then check Advanced Parameters → Information for the PHP version and memory_limit you were actually given versus what was advertised. Specs are claims; TTFB is the measurement.

The recommendation, in one paragraph

For the large majority of PrestaShop stores: a VPS with 4GB RAM, SSD/NVMe storage, PHP 8.2+ that you can switch yourself, OPcache enabled, a local MySQL/MariaDB, Redis available, and a datacentre near your customers. That's roughly €20–40/month and it carries most stores comfortably. The money you save against premium managed hosting is better spent on the things hosting can't fix, a clean database, well-built modules, and proper on-store optimisation. We build the module side of that ourselves, and you can see how we run our own stack on our infrastructure page. Hosting is the foundation; choose it by what PrestaShop actually executes, not by which plan has the biggest number on the comparison table.