A hosting alert may report an 18 GB WordPress database and prompt an immediate revision purge. If revisions occupy little space while one queue or log table dominates growth, that cleanup adds risk without solving the capacity problem.
Inventory every table, compare growth over time and identify the feature that owns the largest change before deciding what can be retained, archived or removed.
What it means
WordPress database size includes table data and indexes, with additional engine-specific overhead and sometimes temporary or historical files reported separately by the host. A useful diagnosis distinguishes those components.
Large tables are not automatically waste. Orders, search indexes, scheduled-job queues, analytics and security logs may be essential even when their volume is unexpected.
A realistic WordPress example
A store database triples in four months. Revision counts are modest, but an Action Scheduler table and its logs contain a backlog created by a failing integration.
The team fixes the recurring job, applies the retention method supported by that system and then measures the table again. Generic post cleanup would never have addressed the cause.
Why it matters and when to use it
Growth can lengthen backups and restores, exhaust storage and increase maintenance cost. Attribution protects important data while directing effort to the component that can control its lifecycle.
Investigate when growth exceeds a budget, accelerates unexpectedly or threatens operational capacity. Routine cleanup should not replace measurement.
A straightforward route for beginners
- Confirm the exact database used by the WordPress installation.
- Record data size, index size, row estimate and engine for every table.
- Compare the largest tables with an earlier inventory or backup.
- Map each unfamiliar table prefix to the plugin, service or custom code that owns it.
- Ask that owner what the rows represent and which retention or repair method is supported.
- Back up before a narrow action, then repeat the same measurements and test the affected feature.
The advanced route
Separate logical table growth from allocated but reusable space. Review index size, partitioning, binary logs, temporary files and managed-service reporting so the numbers being compared describe the same layer.
Sample row types and timestamps without dumping sensitive payloads into reports. Trend writes over a representative period; a one-time import, an active backlog and unbounded logging require different remedies.
Risks, common mistakes, backup, and rollback
Deleting tables from an apparently inactive plugin can remove data needed for reactivation, rollback or compliance. A broad cleanup may also mask a runaway producer until the same growth returns.
Keep a verified backup and document the owner-approved deletion or archive rule. Validate reads, writes, scheduled work, search and transactions after any change.
How AIOWS helps:
AIOWS Database Cleaner
AIOWS Database Cleaner provides supported WordPress maintenance actions for known data categories once the inventory has identified a legitimate target. Its scope should follow the diagnosis, not precede it.
Create a current backup, select one approved category and measure it before and after the operation. Pair the size comparison with a functional test of the feature that owned the data.
The module cannot classify every custom table or decide the business value of unfamiliar rows. Queue backlogs, logging policy and plugin-specific retention must be resolved with the responsible component.
Related AIOWS articles
- How to Optimize WordPress Database Tables Safely
- Why the WordPress wp_postmeta Table Gets So Large
- How to Remove Spam and Trashed Comments from WordPress
Conclusion and recommended route
Start with table sizes and a growth timeline, then trace the dominant data to its owner. Fix the lifecycle problem and clean only the proven obsolete category; a smaller database is useful only if WordPress still retains what it needs.
