WooCommerce Database Update Not Working

Quick fix: open WooCommerce → Status → Scheduled Actions, filter to Pending, and look for actions in the woocommerce-db-updates group. If they sit there with a scheduled time in the past and the count is not falling, nothing is wrong with your database — your site is not running background tasks, and that is the problem to solve.

Take a backup first, using how to back up a WordPress site. Never restore an older store database to escape this — it discards every order placed since the backup.

What the update actually does

WooCommerce stores a database version separately from the plugin version. When a release adds routines that reshape stored data, it compares the two, finds routines it has not run, and shows the update notice.

Pressing the button does not perform the work. It enqueues each routine as a scheduled action, and Action Scheduler then processes that queue in the background across many small requests, triggered by WP-Cron and by loopback requests to your own site. Only when the last routine completes does WooCommerce write the new database version and clear the notice.

That architecture explains the symptom. A "stuck" update is almost never a broken table. It is a queue with nobody working it.

Classify what you are actually seeing

• Pending actions, count falling: it is working. Wait.
• Pending actions, count static: background processing is not running. Go to WP-Cron.
• Failed actions: a routine started and crashed. Read the log entry.
• No actions at all: the queue was never populated, or a stale cache is showing an old notice.
• Notice returns after completing: an object cache is serving the old stored version.

Rule out the cheap causes first

Stale output. Hard-reload the admin page and clear any page and object cache before believing the notice. An admin notice served from cache costs nothing to eliminate and accounts for a surprising share of reports.

The button was never pressed. The update is deliberately manual on many upgrade paths. If there are no pending actions at all, press it and watch the Scheduled Actions screen.

An install lock. WooCommerce sets a short-lived transient while an update run is in progress so two runs cannot collide. If a previous attempt died mid-flight, that lock can suppress the next one until it expires. Wait ten minutes and retry once before assuming anything worse.

Confirm whether WP-Cron is running at all

This is the single most common real cause. Confirm it rather than assuming it:

• Open Tools → Site Health and look for a failed loopback request. Action Scheduler depends on the site being able to call itself, and a failed loopback stops the queue dead — see loopback request failed.
• Check whether DISABLE_WP_CRON is defined in wp-config.php without a real system cron replacing it. That combination silently stops all background work and is a common leftover from a performance tutorial; the correct pairing is described in replacing WP-Cron with a system cron.
• Look at the oldest pending action's date. If it is days in the past, nothing has processed the queue since then — a site-wide fault, not a WooCommerce one.

A store whose cron is broken also stops sending scheduled emails, so this is worth fixing regardless of the update.

Look for a backlog ahead of the queue

Action Scheduler processes a limited batch per run. If a plugin has queued tens of thousands of actions, your handful of update routines sit behind them and may take days to surface. Confirm by comparing the pending count across all groups with the count in the update group. If the total is enormous, deal with the backlog — usually by finding and disabling whatever generates it — rather than re-pressing the update button.

Read the failed actions

If actions failed rather than stalled, the log entry names the reason. Two dominate:

• PHP timeout or memory exhaustion on a routine touching a very large table. Raise the limit for the run, per increasing the WordPress memory limit, and check whether your host caps execution time separately.
• A database error — usually the database user lacking permission to alter tables, or a full disk. Check the server error log, and if a table is damaged, work through repairing a WordPress database before retrying.

If SSH is available, running the update through WP-CLI executes it in the foreground and prints the failure directly instead of burying it in a queue.

Do not confuse this with the order table migration

Moving orders to high-performance order storage is a separate migration, with its own screen under the advanced settings and its own sync queue. It does not produce the database update notice, and switching storage modes while updates are pending compounds both problems. Finish one, verify, then start the other.

Verify the repair

Confirm the notice is gone after a hard reload, that the Status page reports a database version matching the plugin version, and that pending and failed counts in the update group are both zero. Then place a test order and open a report, because those exercise the data the routines reshaped.

Then fix the process that let it stall. Pending background work is a standing risk to every future release, so schedule updates deliberately rather than in a rush, following updating plugins safely.