Database bloat and how to clean it
Your WordPress database (the store that holds your posts, pages, settings and orders) slowly fills with leftovers: old post revisions, expired temporary data and records from plugins you removed long ago. Take a backup f
The short answer
Your WordPress database (the store that holds your posts, pages, settings and orders) slowly fills with leftovers: old post revisions, expired temporary data and records from plugins you removed long ago. Take a backup first, then clean it with a trusted cleanup plugin or phpMyAdmin, in that order. Doing this a few times a year keeps the site quick and the backups small.
What it means
The database is where WordPress keeps everything that is not a file: every post, page, comment, setting, order and plugin record. Each time you save a draft, WordPress keeps a copy called a revision. Plugins store transients (short-lived cache entries with an expiry date) and often forget to remove them. Settings marked as autoloaded are read on every single page view, so when that list grows, every page gets a little slower.
None of this is dangerous on its own. The problem is that it piles up. The database ends up many times larger than it needs to be, the admin screens hesitate, backups take longer and the site feels sluggish for no obvious reason. Cleaning it is routine maintenance, not an emergency repair.
Common causes
- Post revisions. WordPress keeps every saved version of every post and page forever unless you tell it otherwise.
- Expired or abandoned transients. Plugins create them constantly and many never clean up after themselves.
- Autoloaded options from old plugins. Uninstalling a plugin rarely removes its settings, and those settings keep loading on every page.
- Orphaned postmeta. Extra data attached to posts or products that were deleted or imported and removed, left behind with no owner.
- WooCommerce Action Scheduler. The
wp_actionscheduler_actionstable records every background job (emails, subscription renewals, webhooks) and can grow very large on a busy store. - Spam comments and trashed items that were never emptied.
How to fix it
- Take a full backup first. This step is host independent and not optional. On WP Alpha, open the management console (Plesk with WP Toolkit), go to Websites & Domains, then Backup & Restore, and run a backup. Wait for it to finish before you touch anything.
- Measure the problem. In WordPress go to Tools, then Site Health, then the Info tab. The Database section shows the total size and, on recent WordPress versions, the size of your autoloaded options. In the console, Websites & Domains, then Databases, shows the database size, and phpMyAdmin lets you sort tables by size so you can see which ones are heavy.
- Limit future revisions. Open wp-config.php in File Manager and add
define('WP_POST_REVISIONS', 5);above the line that says that is all, stop editing. Five recent versions is plenty for most sites. - Run a cleanup plugin. A well reviewed database cleaner such as WP-Optimize can remove old revisions, expired transients, spam, trashed posts and orphaned data in a few clicks. Run one category at a time and check the site after each.
- WooCommerce housekeeping. Go to WooCommerce, then Status, then Tools. Use Clear transients and Delete orphaned variations. For the Action Scheduler table, open phpMyAdmin from the console and delete rows in
wp_actionscheduler_actionswhose status is complete, failed or canceled. Leave pending rows alone. - Trim autoloaded options. In phpMyAdmin run
SELECT option_name, LENGTH(option_value) AS size FROM wp_options WHERE autoload IN ('yes','on') ORDER BY size DESC LIMIT 30;. Rows named after plugins you no longer use can be deleted. If you are unsure, change the autoload value to no instead of deleting. - Remove orphaned postmeta. In phpMyAdmin run
DELETE pm FROM wp_postmeta pm LEFT JOIN wp_posts p ON p.ID = pm.post_id WHERE p.ID IS NULL;. This only removes data whose parent post no longer exists. - Reclaim the space. In phpMyAdmin tick all tables and choose Optimize table from the drop-down. This is
OPTIMIZE TABLEand it hands disk space back. While you are there, check the Type column. Any table still on MyISAM should be moved to InnoDB withALTER TABLE wp_tablename ENGINE=InnoDB;because InnoDB is faster under load and far more resistant to corruption. - Check the site. Load the homepage, log in, open a product or post, and run through a form or checkout. Keep the backup until you are satisfied nothing is missing.
On WP Alpha
Every WP Alpha site is backed up every two hours and backups are kept for 30 days, so a cleanup that goes wrong is a short step back rather than a disaster. Restores are queued from the management console (Plesk with WP Toolkit) and can be as small as a single file or as large as the whole site. If you prefer a copy you control, you can also send backups to your own Dropbox, Google Drive, Amazon S3 or FTP storage as often as hourly.
phpMyAdmin, SSH and WP-CLI are all available, so every step above can be done on the platform. Redis object caching is on every plan and softens the cost of a heavy options table, but it does not remove the clutter, so the cleanup is still worth doing. If you would rather not run database queries yourself, support is available 24/7 on live chat and will walk you through it.
