WordPress Database Size Analyzer

1. What is wp_options Autoload Bloat?

WordPress autoloads options marked autoload = 'yes' in wp_options into server RAM on every single visitor request. As documented in WordPress Options API Documentation, keeping autoloaded memory under 800 KB is essential for fast TTFB.

2. Limiting Post Revisions via wp-config.php

Adding define('WP_POST_REVISIONS', 5); to wp-config.php limits revision rows in MySQL. Calculate plugin impact in our Plugin Bloat Score Calculator.

3. Cleaning Expired Transients & Orphan Tables

Audit scheduled background database tasks in our Cron Job Debugger.

4. Bypassing MySQL Overhead via Nimbica Static Edge

Nimbica pre-renders WordPress content into static HTML served from 300+ global edge locations, completely eliminating MySQL database queries during visitor sessions.

5. How the Estimator Formula Works

This is a client-side estimator, not a live database connection — nothing you enter is sent to a server. It combines four inputs into a rough size projection using published averages for row overhead:

• Posts & Pages: with revisions enabled, each post/page is weighted at roughly 0.15 MB (accounting for the base row, postmeta, and an average revision history); with revisions off, that drops to roughly 0.03 MB per post.
• Active Plugins: each plugin adds an average of 2.5 MB, covering its own options rows, custom tables, and logged data — a rough proxy since actual plugin table footprints vary from near-zero to hundreds of megabytes for large SEO or analytics plugins.
• WooCommerce: toggling this on adds a flat 45 MB baseline for order, order-item, and session-related tables.
• Core Overhead: a fixed 12 MB baseline representing WordPress core tables (wp_users, wp_terms, wp_options, wp_comments) on a fresh install.

The "Cleanable Bloat Savings" figure applies 45% of the total when revisions are enabled (since unlimited revisions are the single largest reclaimable component) or 20% when they're capped, representing spam comments, expired transients, and orphaned plugin rows that are typically safe to remove.

6. Worked Example: Reading the Output

With the default slider values — 500 posts, 25 active plugins, revisions enabled, no WooCommerce — the formula computes: (500 × 0.15) + (25 × 2.5) + 0 + 12 = 75 + 62.5 + 12 = 149.5 MB, displayed as 150 MB Estimated Size, with cleanable bloat of 150 × 0.45 ≈ 68 MB.

Interpretation: nearly half the projected database size in this scenario comes from unbounded post revisions, not actual content. Toggling "Unlimited Post Revisions Enabled" off in the calculator alone drops the estimate to roughly 87 MB — illustrating why capping WP_POST_REVISIONS is usually the single highest-leverage database cleanup step for a content-heavy site.

7. Practical Use Cases

• Hosting plan sizing: Estimate whether your site will fit inside a hosting provider's database storage cap before signing up or upgrading.
• Justifying a cleanup sprint: Show a client or stakeholder the "before/after" projected savings of disabling unlimited revisions and clearing transients.
• Pre-migration budgeting: Get a ballpark database export size before planning a host-to-host migration window.
• WooCommerce launch planning: Model how much additional database overhead an online store adds to an existing content site before enabling it in production.

8. Limitations of Estimation

• Not a live scan: This tool never connects to your actual site or database — it projects size from generalized averages, not your real row counts.
• Plugin variance is huge: A logging or analytics plugin can add hundreds of megabytes on a high-traffic site, far above the flat 2.5 MB/plugin average used here.
• Doesn't model comment volume: Sites with heavy comment engagement or spam backlogs in wp_comments will see real sizes exceed this estimate.
• Use it for direction, not precision: Always confirm with a real information_schema.TABLES query or a plugin like WP-Optimize before making storage or migration decisions.