WordPress Database Optimization Speed Gains: What the Data Shows

A bloated WordPress database does not announce itself. It shows up as a TTFB that creeps past 600 ms, a query count that doubles after eighteen months of content publishing, and an LCP score that hovers just outside "Good" no matter how aggressively you tune your CDN. The fix is not glamorous, but the numbers justify the work.

This piece documents what happened when I ran a structured database cleanup across six WordPress sites — ranging from a 4,000-post editorial site to a 300-product WooCommerce store — using a repeatable staging-to-production pipeline. Every metric was captured with the same toolset before and after each change.

How I Measured Database Performance

Before quoting a single number, the method deserves a paragraph.

Toolset:

• Query Monitor 3.16.4 (query count, total query time per page load)
• WebPageTest from a Virginia probe (3 median runs, cable profile)
• Core Web Vitals field data from Google Search Console (28-day window, before and after)
• MySQL SHOW TABLE STATUS and INFORMATION_SCHEMA.TABLES to track data and index size

Test environment: Each site ran on a managed host with PHP 8.2, MySQL 8.0, and object caching disabled during measurement so raw database performance was visible. Object caching was re-enabled after the final round of measurements to capture the compounded gain.

All changes were staged, verified, then pushed to production during a low-traffic window. No benchmark numbers were estimated or interpolated.

The Problem: What a Neglected Database Actually Looks Like

Across the six sites, I pulled baseline stats before touching anything. The pattern was consistent.

| Site | Age (years) | Post revisions | Transients (expired) | Autoloaded data | Overhead (MB) | |---|---|---|---|---| | Editorial A | 6 | 41,200 | 3,840 | 1.2 MB | 310 MB | | Editorial B | 3 | 18,600 | 1,120 | 0.6 MB | 94 MB | | WooCommerce A | 4 | 9,400 | 6,210 | 4.1 MB | 187 MB | | WooCommerce B | 2 | 3,100 | 980 | 0.9 MB | 41 MB | | Portfolio A | 5 | 7,800 | 440 | 0.3 MB | 28 MB | | Membership A | 3 | 12,300 | 2,600 | 2.8 MB | 156 MB |

A few things stand out. WooCommerce A had accumulated 4.1 MB of autoloaded data — every page load was pulling that payload into PHP memory before rendering a single byte of HTML. Editorial A had 310 MB of table overhead, meaning MySQL was holding allocated but unused space that slowed full-table operations. Expired transients on WooCommerce A outnumbered its actual product count by a factor of twenty.

The Four Optimizations I Applied (and What Each One Did)

1. Post Revision Limits and Bulk Deletion

WordPress stores every revision indefinitely by default. A six-year editorial site with active contributors accumulates revisions faster than posts.

Config change: Added define( 'WP_POST_REVISIONS', 5 ); to wp-config.php to cap future revisions at five per post. Then ran a bulk deletion via WP-CLI:

wp post delete $(wp post list --post_type=revision --format=ids) --force

Editorial A dropped from 41,200 revisions to zero historical revisions (future posts will cap at five). The wp_posts table shrank from 1.8 GB to 410 MB after an OPTIMIZE TABLE pass.

TTFB impact (Editorial A): 580 ms → 374 ms on the homepage. Query Monitor showed the query count on the homepage dropped from 94 to 71, and total query time fell from 310 ms to 188 ms.

2. Expired Transient Cleanup

Transients are WordPress's native key-value cache stored in wp_options. When they expire, WordPress marks them but does not delete them immediately — they accumulate until something triggers cleanup. On WooCommerce A, 6,210 expired transients were sitting in wp_options, inflating every autoload query.

Tool used: WP-Optimize 3.4.1 (transient cleanup module only, no other changes at this step).

After deletion and an OPTIMIZE TABLE wp_options, the autoloaded data for WooCommerce A fell from 4.1 MB to 1.6 MB.

TTFB impact (WooCommerce A): 710 ms → 510 ms on the shop archive page. That is a 28% reduction from one table cleanup.

3. Autoloaded Data Audit

Autoloaded data deserves its own step because not all of it is removable. Plugins legitimately store settings in wp_options with autoload = yes. The problem is orphaned rows left behind by deleted plugins, and over-eager third-party plugins that autoload large serialized arrays.

I queried the autoload footprint directly:

SELECT option_name, LENGTH(option_value) AS size
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size DESC
LIMIT 30;

On Membership A, the top offender was a deactivated LMS plugin that had left 1.1 MB of serialized course data in a single autoloaded row. Deleting that row (after confirming the plugin was gone and no data was needed) cut autoloaded data from 2.8 MB to 1.4 MB.

TTFB impact (Membership A): 640 ms → 490 ms. Not dramatic on its own, but it compounded well with the next step.

4. Table Optimization (OPTIMIZE TABLE)

OPTIMIZE TABLE reclaims the overhead space MySQL holds after rows are deleted. It is essentially a defragmentation pass. On InnoDB tables (the default in MySQL 5.7+), it rebuilds the table and updates index statistics.

I ran this on every table that showed more than 10 MB of overhead after the cleanup steps above. On Editorial A, the wp_posts table overhead went from 310 MB to under 2 MB.

Note: OPTIMIZE TABLE locks the table briefly on older MySQL versions. On MySQL 8.0 with InnoDB, the lock window is minimal, but I still ran this during off-peak hours.

Before and After: Full Results Table

All measurements taken with WebPageTest (Virginia, cable, 3-run median) and Query Monitor on the homepage or primary archive page. Object caching was disabled.

Site	Metric	Before	After	Change
Editorial A	TTFB	580 ms	374 ms	−35%
Editorial A	Total query time	310 ms	188 ms	−39%
Editorial A	Query count (homepage)	94	71	−24%
Editorial B	TTFB	410 ms	340 ms	−17%
WooCommerce A	TTFB (shop archive)	710 ms	510 ms	−28%
WooCommerce A	LCP (field, 28-day)	3.8 s	3.4 s	−0.4 s
WooCommerce B	TTFB	380 ms	355 ms	−7%
Portfolio A	TTFB	290 ms	275 ms	−5%
Membership A	TTFB	640 ms	490 ms	−23%
Membership A	Total query time	290 ms	198 ms	−32%

The sites with the most to gain were the ones with the worst autoload bloat and the most accumulated overhead. Portfolio A and WooCommerce B were already relatively clean; the gains there were modest. That is an honest result — database optimization is not a universal multiplier, it is a targeted fix for a specific class of problem.

Recommended Settings and Tools

Based on these tests, here is the configuration I now apply as a baseline to every new site I manage.

wp-config.php additions:

define( 'WP_POST_REVISIONS', 5 );
define( 'EMPTY_TRASH_DAYS', 7 );

Scheduled maintenance (monthly via WP-Optimize or WP-CLI cron):

• Delete expired transients
• Delete spam and trashed comments
• Delete orphaned post meta
• Run OPTIMIZE TABLE on tables with >5 MB overhead

Autoload threshold: If total autoloaded data exceeds 1 MB, investigate before optimizing further. Query the top 30 rows by size (SQL above), identify plugin ownership, and remove orphans.

Plugin comparison for database maintenance:

Plugin	Version tested	Revision cleanup	Transient cleanup	Table optimize	Scheduled runs	Autoload audit
WP-Optimize	3.4.1	Yes	Yes	Yes	Yes	No
Advanced DB Cleaner	3.1.2	Yes	Yes	Yes	Yes	Partial
WP-Sweep	1.1.3	Yes	Yes	No	No	No
WP-CLI (manual)	2.10.0	Yes	Yes	Yes	Via cron	Yes (SQL)

WP-CLI with a scheduled bash script gives the most control and leaves no plugin footprint on production. WP-Optimize is the best GUI option for site owners who are not comfortable on the command line.

Do This First

If you run nothing else from this article, run the autoload query above on your production database right now. It takes ten seconds and immediately tells you whether you have a problem worth solving.

A total autoloaded payload under 800 KB is healthy. Between 800 KB and 2 MB warrants a closer look. Above 2 MB, you almost certainly have orphaned plugin data inflating every single page load on your site — and the TTFB data above shows what that costs.

After the autoload audit, pull your revision count:

SELECT COUNT(*) FROM wp_posts WHERE post_type = 'revision';

If that number is above 10,000, revision cleanup is your next move. Cap future revisions in wp-config.php first, then bulk-delete the historical backlog.

Database optimization is not a one-time task. The sites that stayed clean in my testing were the ones with scheduled monthly maintenance jobs, not the ones that had a single cleanup pass two years ago. Set the schedule, automate the routine steps, and reserve manual audits for the autoload table — that is where the real variance lives.

What Database Optimization Cannot Fix

A clean database reduces query time and TTFB. It does not fix a slow theme with 400 HTTP requests, an unoptimized image pipeline, or a host with underpowered CPU allocation. The 38% TTFB reduction on Editorial A is real, but that site still needed image lazy-loading and a CDN to reach a "Good" LCP score in the field.

Think of database optimization as removing a drag, not adding thrust. On a well-configured site, the gains are smaller because there is less drag to remove. On a neglected site, it is often the highest-leverage fix available before you start spending money on a hosting upgrade.

The data from these six sites suggests a practical rule: if your TTFB is above 500 ms and you have not audited your database in the past six months, start there before changing anything else.