Database Optimization: The WordPress Speed Win Most Sites Miss

Database optimization isn't usually anyone's first move on WordPress performance work. It should be one of the first. WordPress databases on long-running sites accumulate transient cache entries, post revisions, orphaned metadata, spam comments awaiting deletion, and abandoned plugin tables. Each item contributes a small amount to total database size. After 2-3 years of normal operation, the database can be 3-5x larger than the content actually requires.

Most performance work focuses on the front-end: image optimization, caching, JavaScript deferral. Database optimization happens on the back-end and contributes to TTFB rather than browser-rendered metrics. For sites whose TTFB is slow, database cleanup is one of the higher-leverage optimizations available.

What gets bloated, in order of impact

The wp_options table is the most commonly bloated. Plugins that add options to wp_options often don't clean them up on uninstall. Sites that have used dozens of plugins over years can have wp_options tables with 5,000+ rows, where most rows are orphaned options from plugins long since removed.

WordPress reads the entire wp_options table on every page load to find the "autoloaded" options. If wp_options is bloated and many entries are autoloaded, this adds to TTFB.

Post revisions are the second-largest contributor. WordPress saves a database row for every revision of every post by default. A blog with 200 posts and an average 8 revisions per post has 1,600 revision rows in wp_posts, where the content rows that matter are just 200.

Transients are third. Plugins use transients for short-term caching. Expired transients don't automatically clean themselves up; they accumulate in wp_options until WordPress's scheduled cleanup runs (which is unreliable on shared hosting).

Spam comments are fourth. Akismet quarantines spam comments in wp_comments with the spam status. The plugin auto-deletes them after 15 days by default, but the delete is sometimes interrupted on busy sites.

Comparison hook: how this differs from "performance optimization"

Performance optimization is usually about reducing render time. Database optimization is about reducing query time. Both improve site speed but they hit different metrics. A site with image-heavy pages benefits more from image optimization; a site with database-heavy operations (many plugins, many custom post types) benefits more from database optimization.

Limited-scope endorsement: database optimization is the right priority when your TTFB is slow and your front-end is already optimized. If your front-end has heavy unoptimized images and TTFB is fast, fix the front-end first.

How to actually clean up

WP-Optimize (free) handles the basics. Schedule weekly cleanup of: post revisions older than 60 days, expired transients, spam comments older than 15 days, trashed posts older than 30 days. The plugin runs the cleanup as scheduled cron jobs and doesn't require manual intervention.

For autoloaded wp_options bloat, use WPDB scanning. The Query Monitor plugin shows you the autoloaded options size in its panel. If autoloaded options are over 1MB, you have a problem. The fix involves identifying which plugin's options are bloated (often via the option_name prefix) and either uninstalling the plugin properly (which should clean them up) or manually removing the orphaned entries.

Don't blindly run "remove all expired transients." Some transients should remain. The right approach is to remove transients older than 7 days that are no longer in use. WP-Optimize handles this distinction.

Direct recommendation

If you're choosing one database optimization plugin: WP-Optimize. The free version handles all the common cases. Schedule it to run weekly. Combined with quarterly manual reviews of plugin-specific tables, this maintains a healthy database without ongoing manual work.

The improvement from a proper cleanup on a 3-year-old WordPress site is typically: 50-150ms TTFB improvement, 200-500MB database size reduction, faster admin dashboard load times. These are measurable and the work is straightforward.

Do not run database optimization tools without a recent backup. Some plugins occasionally over-aggressive cleanup that breaks specific plugin functionality. The risk is small but real, and the recovery from a botched optimization is much faster with a backup than without one.