Learn how to reduce WordPress database size.

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.

Step 1: Find what consumes space

In phpMyAdmin, sort tables by size. Common culprits: wp_postmeta, wp_options, wp_actionscheduler_actions, wp_actionscheduler_logs, wp_comments.

The commands below need SSH access and will not work inside File Manager:

wp db size --tables
wp transient delete --expired

Step 2: Safe 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 wp-content/uploads/.

Step 3: 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.

Step 4: 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.

Step 5: Schedule ongoing maintenance

Limit revisions in wp-config.php in your site root, next to wp-admin and wp-content. Search for WP_POST_REVISIONS and EMPTY_TRASH_DAYS first. If those lines already exist, update them instead of adding duplicates. If neither exists, paste the constants above the line that says stop editing:

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 at a confirmed price without hourly billing surprises.