Every WordPress installation accumulates database bloat over time. Post revisions, expired transients, orphaned postmeta, spam comments, and trashed items all consume space and slow down queries. A site running for two years might have a database 10× larger than necessary.
The impact is measurable. Complex queries against a bloated wp_postmeta table — which WooCommerce uses heavily — can take seconds instead of milliseconds. This directly affects page load times, admin dashboard responsiveness, and WooCommerce checkout performance.
Automated cleanup
Run on a schedule: limit post revisions to 5-10 per post, delete expired transients weekly, remove trashed posts and comments monthly, and optimise database tables quarterly. These operations are safe but should be preceded by a backup.
Custom indexing
Where significant gains are made. WordPress’s default indexes cover basic operations, but sites with large postmeta tables (WooCommerce stores, sites with ACF) benefit from composite indexes on commonly-queried meta_key/meta_value pairs.
Frequently Asked Questions
Why does WordPress database performance degrade over time?
WordPress databases accumulate bloat through normal operation: post revisions (WordPress saves a revision on every save by default), expired transients that plugins store and never clean up, orphaned postmeta rows left behind by deactivated plugins, spam comments, and trashed items. A site running for two years might have a database 10× larger than necessary. Larger tables mean slower queries — a complex WooCommerce product query that takes 10ms on a clean database can take seconds on a bloated one.
What is the wp_options autoload problem in WordPress?
WordPress loads every row in wp_options where autoload is set to ‘yes’ on every single page request, regardless of whether that data is needed for the current page. Plugins frequently store settings here with autoload enabled and never clean up when deactivated. A site with 500KB of autoloaded data adds that payload to every request’s memory footprint and execution time. Production sites with 2MB+ of autoloaded data can see 200–400ms added to every page load before any content-specific queries execute.
How do I speed up WordPress database queries?
The main approaches are: implement Redis object caching to serve repeated queries from memory rather than the database, clean up database bloat (limit post revisions, delete expired transients, remove orphaned data), add composite indexes on heavily-queried columns in postmeta tables, audit and disable plugins that generate excessive queries, and ensure your hosting uses NVMe storage rather than SATA (10× faster I/O). On WP Pro Host, automated weekly database maintenance handles cleanup and query performance monitoring.
How many post revisions should WordPress keep?
Limiting post revisions to 5–10 per post is a sensible default. Add this to wp-config.php: define('WP_POST_REVISIONS', 5); — this limits WordPress to 5 revisions per post. On sites with many posts and frequent editing, unlimited revisions cause wp_posts and wp_postmeta to grow significantly over time. Existing excess revisions can be removed with WP-CLI: wp post delete $(wp post list --post_type='revision' --format=ids) --force
Does Redis caching replace database optimisation in WordPress?
No — Redis caching and database optimisation address different problems. Redis caches the results of database queries in memory, so repeated queries are served from RAM rather than hitting the database. However, Redis cannot speed up queries that have never been cached (cold requests), queries with high cardinality (unique parameters), or write operations (orders, cart updates). Database optimisation — cleaning up bloat, adding indexes, tuning configuration — ensures the database itself is fast for all query types, including those Redis cannot cache.