MyISAM vs InnoDB in WooCommerce: Why Your Database Engine Matters for Inventory

WooCommerce has changed enormously over the years, but some stores are still carrying database decisions made a decade ago. One we still come across is MyISAM, an older MySQL storage engine that was widely used by WordPress installations in the past.

Modern WordPress and WooCommerce environments generally use InnoDB. If your store has been running for years, has moved between hosts, or has tables created by older plugins, you may have a mixture of both without realising it. And when software is controlling physical inventory, that difference matters.

An old database choice that still matters

For a basic brochure site, the database engine is something most owners never need to think about. A write might mean updating a page title or saving a setting.

WooCommerce is different. Orders, stock changes, payments, imports and integrations can all be touching the database within the same few seconds. That's the environment Stokkap lives in, so it's the one we care about.

MyISAM vs InnoDB: what's actually different?

MyISAM	InnoDB
Older storage engine	Modern MySQL default
Table-level locking	Row-level locking
No transaction support	Supports transactions
No rollback	Supports rollback
Weaker crash recovery	Strong crash recovery
Can bottleneck under concurrent writes	Better suited to busy, write-heavy sites

Why this matters more for inventory

When Stokkap performs an operation, we may be changing stock across locations, recording an adjustment, updating WooCommerce, creating an audit entry, or allocating inventory to an order. Those changes need to agree with each other.

The last thing we ever want to hear from a customer is:

"The transfer says it completed, but the stock is wrong."

Or:

"Stock disappeared from one location but never arrived at the other."

That is exactly why we've become stricter about the database foundation Stokkap runs on.

What happens when something fails halfway through?

Websites aren't perfect environments. A database connection can drop. A request can time out. PHP can be interrupted. The server can briefly become unavailable. Two processes can try to change the same inventory at almost the same moment.

Most of the time none of this is noticeable. The important question is what happens to your inventory when it does happen.

Imagine transferring 10 units from Warehouse A to Warehouse B. Behind that one tap, Stokkap may need to:

1. Validate the available inventory.
2. Deduct 10 units from Warehouse A.
3. Add 10 units to Warehouse B.
4. Record the movement.
5. Create the audit history.
6. Synchronise the resulting stock state.

We don't want steps 1 to 3 succeeding and the connection disappearing before everything else is safely done.

With InnoDB transactions, related database changes are treated as a single operation. If everything succeeds, it's committed. If something critical fails, the transaction can be rolled back instead of accepting a half-finished result. For an inventory system, that's a huge advantage.

It also makes retries safer

Stokkap includes retry and recovery logic because temporary failures happen in the real world. But retrying is only useful if we can reliably establish what happened the first time.

We don't want to blindly run an operation again and deduct stock twice. Equally, we don't want to assume something finished when only part of it did. Transactions, auditing and retry logic work together, and that's the level of protection we want underneath Stokkap as it grows into transfers, stocktakes, purchasing, receiving, pick & pack and wider warehouse operations.

MyISAM can also lock the whole table

There's a practical concurrency reason too. MyISAM relies on table-level locking, so a write can lock an entire table while it's being changed. On a quiet site you may never notice. On a busy WooCommerce store you could have, all at once:

• A customer placing an order.
• Stokkap updating inventory.
• Staff processing a transfer.
• An import changing products.
• WooCommerce Action Scheduler running jobs.
• Another integration synchronising data.

InnoDB normally uses much finer row-level locking, so unrelated operations have a far better chance of carrying on without waiting for an entire table.

Does Stokkap stop working if it finds MyISAM?

No. We know there are thousands of older WooCommerce installations out there, and we don't want a legacy table to suddenly stop anyone running their store. Stokkap keeps compatibility fallbacks for basic operations where possible.

For operations where transactional integrity matters, particularly stock adjustments, transfers and other multi-step inventory operations, we want the relevant tables on InnoDB. That's why Stokkap now checks for MyISAM and shows a Database protection recommendation when it finds it.

Why would my WooCommerce store still have MyISAM?

It's quite common on older stores. Nobody chose MyISAM recently. Typically we find it on:

• Sites started many years ago and upgraded continuously rather than rebuilt.
• Stores migrated through several hosting providers.
• Databases originally created on older MySQL configurations.
• Tables created by old plugins that used MyISAM.

WordPress and WooCommerce moved forward, but old tables don't magically change engine. So we sometimes see stores with mostly InnoDB tables and a handful of MyISAM ones left behind. The site works perfectly normally, so there was never a reason to notice them. Until now.

What to do if Stokkap shows the warning

First: don't panic, and don't change any tables without a backup.

To see where you stand, check WooCommerce → Status for database information. phpMyAdmin or your hosting database tools give a clearer view: look at the Engine column for every table. Ideally all your active WordPress and WooCommerce tables say InnoDB.

1. Ask your hosting provider

This is our recommendation for most store owners. Tell your host your WooCommerce database contains MyISAM tables and you'd like them backed up and converted to InnoDB. A good managed WordPress host will know exactly what you mean.

2. Convert them yourself

If you're comfortable with databases, do it directly through phpMyAdmin or your host's database tools. If you'd rather avoid SQL, plugins such as Index WP MySQL For Speed can convert MyISAM tables to InnoDB and add useful database indexes too. Backup first, either way.

3. Ask Stokkap Support

If databases aren't something you want to touch, get in touch. We'll investigate the warning, check the affected tables and get the database into the right shape for Stokkap. Because we work with WordPress and WooCommerce infrastructure every day, we can also audit the wider setup and spot database, cron, performance or configuration issues that could affect reliable inventory processing.

Reliable inventory starts underneath the inventory software

We can build safeguards into Stokkap. We can audit operations, validate stock, detect failures and retry. But the database underneath all of that matters too.

When you're using software to represent real products on real shelves, "mostly completed" isn't a result we're happy with. A transfer should transfer. An adjustment should adjust. And if something fails halfway through, we'd much rather safely roll back or recover than leave you working out why the numbers no longer add up.

MyISAM isn't suddenly broken. It's just an old engine that's no longer the right foundation for modern WooCommerce inventory. Back up, find the remaining MyISAM tables, and convert them to InnoDB.

Key takeaways

• InnoDB transactions let a multi-step stock operation succeed completely or roll back, never half-finish.
• Safer rollback also makes retries safe, with no double deductions.
• Row-level locking copes better with orders, imports and staff working at once.
• Stokkap still works on MyISAM for basic operations, but advanced ones should run on InnoDB.
• Always take a verified backup before converting.