Choosing a server for WooCommerce

WooCommerce's official documentation asks for PHP 8.3 or newer, MySQL 8.0 or MariaDB 10.6 or newer, HTTPS and a WordPress memory limit of at least 256 MB. It gives no figure for the server's RAM. For a small store, starting with 2-4 GB of RAM is reasonable (a rule of thumb that varies with the store). As products and orders grow, so does the load on the database and the processor.

A store doesn't behave like a blog. The cart and checkout pages are different for every visitor, so they can't be cached, and orders are written to the database all day. For the same traffic, a store therefore often needs more resources than a blog.

The official requirements

The WooCommerce server requirements document (an official recommendation) lists:

• PHP 8.3 or newer.
• MySQL 8.0 or newer, or MariaDB 10.6 or newer.
• HTTPS support.
• A WordPress memory limit of 256 MB or more.
• Apache or Nginx as the web server.
• Multibyte string (mbstring) support if your store isn't in English. The document treats this as a requirement that depends on the store, and a Turkish store falls in that group.

The 256 MB figure is a ceiling for one PHP request, not the RAM of the server. If needed, add this line to wp-config.php:

define( 'WP_MEMORY_LIMIT', '256M' );

Older versions such as PHP 7.4 appear in the document only as a legacy fallback, and they are not recommended.

Why a store differs from a blog

• Pages that can't be cached. The WooCommerce caching guide tells you to keep the cart, checkout and account pages out of the cache, because they show data specific to that visitor. Some cookies, such as the cart cookies, should be excluded as well. Check that your caching plugin does this.
• Write load. Creating orders, updating stock and storing sessions all write to the database constantly. A blog writes rarely, while a store writes all day.
• Background jobs. WooCommerce runs deferred work (emails, webhooks, subscription payments) through a built-in job queue called Action Scheduler. The queue is triggered by WP-Cron, so on a store with little traffic, jobs can run late. Setting up a cron task on the server to run WP-Cron on a schedule (together with the DISABLE_WP_CRON setting) removes that dependence. You can see the queue under WooCommerce > Status > Scheduled Actions.

Order data and HPOS

High-Performance Order Storage (HPOS) keeps orders in dedicated tables built for the job, instead of WordPress's general post tables. It has been the default on new installs since WooCommerce 8.2. Older stores don't switch on their own. You enable it under WooCommerce > Settings > Advanced > Features, and a compatibility mode keeps the two structures in sync. For the server, the point is this: the structure is optimized for orders, but the database still needs memory and disk.

Starting size

These values are rules of thumb and vary with the store. They are not a firm promise.

The number of plugins, image sizes and sudden load during a campaign matter as much as the product count. An object cache (such as Redis) lowers the database load, but it needs memory. Start small, then grow by checking the output of free -h and top at peak hours.

Common reasons a store gets slow

• Large, uncompressed product images.
• Unused plugins and extra scripts that run on every page.
• No object cache, so the same database query runs again and again.
• An old PHP version that no longer gets maintenance.

Fixing these often comes before scaling up. Where scaling up doesn't help, the problem is usually in the configuration.

Backups: a daily backup may not be enough on its own

At Seturack the server is backed up every night and the last 7 days are kept. In a store, orders arrive all day, so that alone may fall short. If you restore, the orders placed since the last backup are lost. Take a database dump more often and copy it somewhere else:

mysqldump --single-transaction -u USER -p DATABASE | gzip > orders-$(date +%F-%H%M).sql.gz

In a scheduled job, don't put the password on the command line. Use a ~/.my.cnf file with permissions set to 600. On a ready-made WooCommerce server the application runs in Docker, so run the database commands from inside the container. The database there is MariaDB. The container may not include mysqldump, so use mariadb-dump. Product images live in the wp-content/uploads folder, so copy that as well.

What to prepare besides the size

• HTTPS. It is mandatory for WooCommerce. A ready-made WooCommerce server opens over HTTPS on an address derived from your IP with sslip.io. To connect your own domain, see this article.
• Email. Install an SMTP plugin so order emails go out. The installation doesn't set up email sending.
• Updates. After the installation, updates to WordPress, WooCommerce and your plugins are yours to handle. Take a snapshot from the panel before a big update. A snapshot is no substitute for a backup, it only lets you go back to the point before.

A server with WooCommerce pre-installed is ready in roughly 3.5 to 4 minutes, and you can scale it up from the panel as the store grows. Have a look at the WooCommerce server page.