Monitor your WordPress database size with data vs. index breakdowns and an on-demand scan button to detect bloat before it affects performance.
Database Size Tracking
This is a PRO feature. Unlock real-time monitoring, environment indicators, version history, and more. Upgrade to PRO →
The Database Size Tracking feature monitors the size of your WordPress database, breaking it down into data and index components so you can identify bloat and optimize proactively.
What It Displays
- Total Database Size - Combined data and index size, formatted in MB or GB
- Data Size - The actual data stored in your database tables
- Index Size - The size of database indexes used for query performance
- Table Count - The total number of tables with your WordPress prefix
How It Works
Version Info queries the MySQL information_schema to calculate the total data_length and index_length for all tables matching your WordPress database prefix. This is the same method used by professional database management tools.
Scan Now Button
Unlike CPU and memory metrics which update automatically, database size is cached for 12 hours by default due to the heavier nature of the information_schema query. To force a fresh scan:
- Navigate to Settings > Version Info > System Resources.
- Click the Scan Now button in the database section.
- The database size data will refresh immediately via AJAX.
The 12-hour cache prevents unnecessary database queries on every page load. For most sites, database size doesn't change significantly within shorter intervals.
Customizing the Cache Duration
Developers can adjust the database cache TTL using a filter:
add_filter( 'version_info_db_cache_ttl', function ( int $seconds ): int {
return 3600; // Cache for 1 hour instead of 12 hours
} );
Use Cases
- WooCommerce sites: Monitor table size growth during high-traffic sale events.
- Content-heavy sites: Track database bloat from post revisions, transients, and log tables.
- Maintenance routines: Verify the impact of database optimization plugins by comparing before/after sizes.
On very large databases or shared hosting with limited information_schema access, the query may take a few seconds to complete. The caching mechanism ensures this only happens on the initial scan or when manually triggered.