Most hosting comparisons for WooCommerce are really comparisons of price. This one is a specification: what a store genuinely needs underneath it, why each item matters, and how to tell whether the plan you are on already clears the bar.
It is written to be usable against any host, including ones that are not us. We sell WooCommerce hosting, so treat the recommendation with the scepticism that deserves and check the reasoning instead.
The short answer
A WooCommerce store needs four things a blog does not: an object cache, enough PHP capacity to handle concurrent checkouts, a database that is not contended, and a staging environment so updates can be tested before they reach customers. Everything else on this page is detail.
If your current plan has all four, you are probably fine. If it has none, you are running a shop on infrastructure designed for a brochure site, and it will hold until the day it matters most.
The technical minimums
These are the baseline numbers. They are not ambitious, and a host that cannot meet them is not a candidate.
| Requirement | Minimum | Why it matters for a store |
|---|---|---|
| PHP version | A currently supported release | Unsupported versions stop getting security fixes, and each recent release has been measurably faster |
| PHP memory limit | 256MB | WooCommerce plus extensions routinely exceeds the WordPress default; imports and reports are the usual casualties |
| Database | MySQL or MariaDB, recent | Order tables grow indefinitely and query performance decides how the admin feels |
| HTTPS | Valid certificate, auto-renewing | Payment pages require it, and expiry takes the shop offline |
| Storage | SSD or NVMe | Uncached pages hit disk; spinning disks are disqualifying at this point |
| Backups | Daily, off-site, restorable | Orders are unrecoverable if lost, unlike page content |
The current requirements are published by WooCommerce itself, and the supported-version list for PHP is worth checking against whatever your host has you on, because a surprising number of stores are running something that stopped receiving security patches over a year ago. The same applies to the database: both MySQL and MariaDB publish end-of-life dates, and hosts do not always move you off an old one.
The certificate is the one item on that list you should never be paying extra for. Let's Encrypt issues them free and renews automatically, and any competent host has integrated it. A host still charging for basic HTTPS on a store in 2026 is telling you something about the rest of their pricing.
Object caching, staging and daily backups on every FastCow plan
Talk To Sales →The four things a store adds
The table above gets WordPress running. These four are what separate hosting that works for a shop from hosting that merely works.
1. Object caching
Cart, checkout and My Account are excluded from page caching, because serving one customer a cached copy of another basket would be a data breach. Those pages therefore run the full stack every time. An object cache, normally Redis, keeps database query results in memory so the uncached pages get faster too.
This is the single biggest infrastructure difference between a quick store and a sluggish one, and it is the thing budget hosting most often lacks. It has to be available on the server; no plugin can supply it. Our guide to WooCommerce speed optimisation goes into what it changes and how to confirm it is actually connected.
2. PHP workers, not just PHP
A PHP worker handles one uncacheable request at a time. Your product pages come from cache and cost nothing, but every checkout occupies a worker for its full duration. Run out and requests queue, which customers experience as the checkout hanging at the worst possible moment.
Most hosts do not advertise worker counts, and it is a fair question to ask directly. Concurrency, not monthly page views, is the number that decides whether a sale completes during your busiest hour.
3. Staging
A store cannot test updates in production, because the failure mode is a broken checkout during trading hours. Staging is a copy of the site where updates are applied and a test order placed before anything reaches customers. Without it you are choosing between updating blind and not updating, and both end badly.
This is the requirement most often missing on cheap plans, and the one that quietly makes everything else on this page harder.
4. Backups you can actually restore
Orders are the one thing on a store that cannot be recreated. A page can be rewritten; yesterday’s transactions cannot. Daily is the floor, off-site is essential because a backup on the same server dies with it, and the database matters more than the files.
Ask specifically whether you can restore yourself, and how long it takes. A backup that requires a support ticket and a four-hour wait is a very different product from one you can trigger at two in the morning.
Sizing by order volume
Traffic is the wrong measure for a store. Ten thousand browsers hitting cached product pages cost almost nothing; two hundred simultaneous checkouts cost a great deal. These bands are rough and assume a typical store rather than an unusual one.
| Stage | Roughly | What you need |
|---|---|---|
| Starting out | Under 100 orders a month | Decent shared or entry managed hosting. Staging and daily backups matter more than raw power |
| Established | 100 to 1,000 orders a month | Managed hosting with object caching. This is where shared plans usually start showing strain at the checkout |
| Busy | 1,000 to 10,000 orders a month | Dedicated resources, tuned worker counts, a CDN, and someone watching performance deliberately |
| High volume | Above 10,000, or heavy sale spikes | Scalable infrastructure and a conversation about your specific traffic shape rather than a plan off a page |
Spikes matter more than averages. A store doing 300 orders a month evenly is a different problem from one doing 300 in a single Black Friday evening, and only the second needs headroom it will not use for the other 364 days. Our guide to hosting for high-traffic WordPress sites covers what that headroom looks like.
When shared hosting is genuinely fine
It is fashionable for hosting companies to say shared hosting is never suitable for a store. That is oversold.
A new store with a handful of orders a month, a small catalogue and no immediate growth plans will run perfectly well on good shared hosting. The checkout is slow in absolute terms but nobody is queueing behind anybody else, and the money saved is better spent on product photography or ads.
What matters is knowing the specific point at which it stops being true. That point is not a traffic number, it is a set of symptoms:
- The checkout takes noticeably longer than the rest of the site
- The WordPress admin is slower than the shop front
- Performance is fine most of the time and bad exactly when you are busy
- You have no staging site, so you have stopped updating
Any two of those together mean the platform has become the constraint. Our comparison of managed versus shared hosting covers the general trade-off, and the signs a host is failing you covers the ones that apply to any site.
When to move, and when not to
Migration is disruptive and worth doing for the right reason rather than a marginal one.
Worth moving for: no staging environment, no object cache available, a checkout that slows under concurrent load, an unsupported PHP version your host will not update, backups you cannot restore yourself, or support that cannot answer a WooCommerce question.
Not worth moving for: a page-speed score you dislike, a slow admin that is really database bloat, or a slow checkout you have not yet diagnosed. Those are fixable where you are, and moving will disguise rather than resolve them. Diagnose first; the speed guide covers how.
Questions to ask before you sign
Six questions. The answers separate hosting built for stores from hosting that merely permits them.
- Is object caching available, and included? Sometimes it exists only on higher tiers, which changes the real price.
- How many PHP workers do I get? A host that cannot answer has probably not thought about concurrency.
- Is staging included, and is it one click? If it is manual, it will not get used.
- Can I restore a backup myself, and how long does it take? Self-service matters at 2am.
- Are cart and checkout excluded from caching by default? If they are not, that is a data leak waiting to happen.
- Is migration included, and who does it? Moving a live store is the risky part and worth having done for you.
The security equivalent of this list is our checklist of security questions to ask a web host, which is worth asking in the same conversation.
Moving without losing orders
The particular risk when migrating a store is orders placed during the switch, which can land on the old server after you think you have finished and be lost when it is decommissioned.
The shape that avoids it:
- Copy the site to the new host and test it fully on a temporary URL, including a real test order through every payment method
- Lower your DNS TTL a day ahead so the switch propagates in minutes rather than hours
- Put the store into maintenance mode, take a final database copy, and move that
- Switch DNS, then watch the OLD server for stray orders for 48 hours before shutting it down
- Place a real order on the new host before announcing anything
Our step-by-step on migrating WordPress to a new host covers the general process. We also do migrations free, which for a live store is the part most worth handing to somebody who has done it before.
What it costs
Prices move, so this is bands rather than figures. What you are buying as you go up is not disk space, it is isolation from other people’s traffic and someone competent to call.
| Tier | You typically get | Suits |
|---|---|---|
| Budget shared | No object cache, no staging, shared CPU | A new store proving the idea |
| Managed WordPress | Object caching, staging, daily backups, WordPress-aware support | Most working stores |
| Dedicated or cloud | Guaranteed resources, tuned workers, scaling | High volume or heavy spikes |
Set the cost against an hour of downtime during a sale, which for most stores exceeds a year of the difference between tiers. That comparison, rather than the monthly figure on its own, is the one worth making. Our pricing is public if you want a concrete number to anchor against.
Whatever you choose, the hosting is only half the job. The other half is keeping the store patched, tested and backed up, which our guide to WooCommerce maintenance covers, and keeping it safe, which WooCommerce security covers. Good hosting makes both easier. It does not do either for you.
FAQs
A currently supported PHP release, at least 256MB of PHP memory, a recent MySQL or MariaDB database, HTTPS with an auto-renewing certificate, SSD storage and daily off-site backups. Those get a store running. Object caching, adequate PHP workers and a staging environment are what make it work well.
Yes, and for a new store with a small catalogue and modest order volume it is often the sensible choice. It stops being suitable when the checkout is noticeably slower than the rest of the site, when performance dips exactly when you are busiest, or when the absence of staging has made you stop applying updates.
256MB of PHP memory is the working minimum and 512MB is more comfortable once you are running a normal set of extensions. Server RAM matters less than how it is allocated: a plan advertising plenty of memory but few PHP workers will still queue checkouts under load.
Not strictly, but managed plans bundle the four things stores need most, which are object caching, staging, tested backups and support that understands WordPress. You can assemble those yourself on unmanaged infrastructure if you have the skills and want the control.
A worker handles one uncacheable request at a time, which for a store means one checkout. Cached product pages do not consume them. The number you need depends on concurrent checkouts rather than total traffic, so a small store with sharp sale spikes may need more headroom than a larger steady one.
It will if the uncached pages are the bottleneck, which for stores is common, because object caching, PHP capacity and database performance are all set by the platform. It will not if the real problem is oversized images or plugins loading on the checkout. Diagnose before you move, or you will take the problem with you.
Built For The Uncached Half
Object caching, staging, daily off-site backups and free migration, on every plan rather than as an upgrade. If your checkout is the slow part, that is the part we build for.
See WooCommerce Hosting