What this problem looks like
Database size rarely affects front-end speed until tables hit millions of rows. It always affects backup windows, staging sync, and admin queries on meta-heavy plugins.
Never truncate wp_posts for shops. Order and subscription data lives there. Focus on transients, logs, sessions, and revisions first.
Find what consumes space
In phpMyAdmin, sort tables by size. Common culprits: wp_postmeta, wp_options, wp_actionscheduler_actions, wp_actionscheduler_logs, wp_comments.
wp db size --tables
wp transient list --search= --format=countSafe cleanup targets
- Post revisions beyond your retention policy.
- Trashed posts and spam comments.
- Expired transients in wp_options.
- Completed Action Scheduler actions older than 30 days.
- Large wc-logs files under uploads.
WooCommerce-specific caution
Do not delete orders, subscriptions, or customer download permissions. WooCommerce → Status → Tools offers Clear expired transients and Clear customer sessions for safer session cleanup.
Remove orphaned post meta carefully
Plugins leave orphan meta when posts delete improperly. Advanced DB Cleaner can remove orphans after backup. Run on staging first and verify shop checkout after cleanup.
Schedule ongoing maintenance
Limit revisions with wp-config constant WP_POST_REVISIONS. Schedule weekly transient cleanup on busy sites. Monitor Action Scheduler failed actions separately from size.
define( 'WP_POST_REVISIONS', 5 );
define( 'EMPTY_TRASH_DAYS', 7 );When to stop DIY and hire help
Tables over several gigabytes, corrupted indexes, or multisite networks need DBA-level help. BugShield shrinks WooCommerce databases and fixes slow meta queries.