Database Size Creep on WordPress Sites

Your WordPress site still loads. Disk space looks fine. Then backups start timing out, migrations fail, and the host emails about MySQL size limits. The database grew quietly for two years while plugins did their thing in the background.

Database creep is one of the most common performance problems we see on otherwise "fine" WordPress sites. Not glamorous. Very fixable if you know where the bytes hide.

How WordPress databases get fat

WordPress stores almost everything in MySQL: posts, settings, plugin data, order history, form entries, security logs, and endless rows of "temporary" cache. A 200 MB site on disk can have a 2 GB database without anyone noticing until something breaks.

Common culprits:

• Post revisions: every save adds a row; heavy editors on busy sites pile up fast
• Autoloaded options: plugins stuffing large JSON into wp_options with autoload=yes loads on every page hit
• Transients: expired cache rows that never got cleaned
• WooCommerce tables: sessions, logs, Action Scheduler queue, old orders on high-traffic stores
• Form and security plugins: entries and firewall logs stored in the database instead of files
• Spam comments: thousands of rows in wp_comments waiting for deletion
• Analytics and SEO plugins: historical data you forgot was being collected

Symptoms before the quota email

• Backups fail or take hours
• Staging clones choke on import
• wp-admin feels sluggish on list tables (posts, orders, users)
• Hosting panel shows database over plan limits
• Migrations to a new host fail mid-dump

These often show up before front-end page speed scores complain. The public site is cached; the database still suffers on admin and checkout.

Find the heavy tables first

Do not guess. Check sizes before you delete random rows.

With phpMyAdmin or Adminer, sort tables by size. Look at wp_options, wp_postmeta, wp_posts, and any plugin tables with names like actionscheduler_*, wf* (Wordfence), or form plugin prefixes.

WP-CLI if you have SSH:

wp db size --tables
wp option list --autoload=yes --format=count
wp transient list --format=count

A single autoloaded option over 1 MB is a smoking gun. We touched autoload pain in WordPress admin slow before upgrading the server.

Safe cleanup moves

Backup first. Always. Then:

• Limit or disable excessive post revisions (constants in wp-config or revision management plugins)
• Delete spam and trashed comments
• Purge expired transients (WP-CLI or reputable cleanup plugins, not random SQL from a forum)
• Trim old Action Scheduler completed actions on WooCommerce sites
• Configure security/form plugins to log to files or rotate database logs
• Remove unused plugins that left tables behind (check with a developer if unsure)

Avoid bulk DELETE on tables you do not recognize. "Freeing space" by wiping wp_postmeta without understanding it restores from backup in a bad mood.

Plugins that help vs plugins that hurt

Database optimization plugins can schedule cleanups. They can also delete the wrong thing if misconfigured. Prefer tools that show what will be removed and work on staging first.

Plugins that store everything in the database because it is convenient for the vendor are a long-term tax. Sometimes the fix is switching form storage or log retention settings, not buying a bigger server.

When to upgrade hosting instead of cleaning

Cleanup wins when the bloat is accidental. Upgrade wins when the data is legitimate and growing: large WooCommerce history you must keep, big membership sites, LMS progress records. You need more database resources and better backup windows, not just DELETE statements.

If you are on shared hosting hitting MySQL limits with a real store, that pairs with signs you outgrew shared hosting.

Prevention habits

• Quarterly database size check (five minutes in phpMyAdmin)
• Revision limits on editorial sites
• Log retention policies on security plugins
• Staging tests before installing "analytics for everything" plugins
• Object cache for heavy sites (cuts repeated option reads; see our object cache guide)

Bottom line

WordPress database creep is slow, silent, and expensive at backup time. Measure table sizes, clean with a plan, fix plugin habits that cause bloat, and upgrade when the data is real growth not junk.

Backups failing or database over quota? Talk with Swift Host. We can review what is eating space and whether cleanup or a bigger plan is the right fix.