Database Bloat in WordPress: Clean Revisions, Transients, Options

If your WordPress dashboard feels sluggish, pages take longer to save, or your site gets slower over time without an obvious cause, database bloat is a strong suspect. The usual culprits are post revisions, expired transients, and oversized autoloaded options that WordPress loads on every request.

The safe way to fix it is to back up first, identify what is actually growing, then remove only stale data and trim the options that are unnecessarily loading everywhere. Do not start by deleting rows at random in phpMyAdmin; the fastest path to a broken site is “cleanup” without a plan.

What database bloat looks like

Database bloat usually shows up as a slow drip rather than a sudden failure. Common symptoms include:

• The block editor takes longer to load or save.
• Admin pages feel sluggish, especially the Posts, Pages, and Settings screens.
• Scheduled tasks or background jobs run late.
• Search, filters, and queries feel slower than they used to.
• Your host shows higher database CPU or slow queries, even though traffic has not changed much.

Sometimes the front end is also slower, but not always. That’s because some database problems mostly affect the dashboard and content editing flow, while others slow every page request.

Why this happens

WordPress is designed to keep writing small amounts of data over time. That is normal. The problem starts when old data is kept forever or when a plugin stores too much information in the wrong place.

The three most common sources of bloat are:

• Revisions — every save of a post or page can store another copy.
• Transients — temporary cached data that should expire, but sometimes lingers.
• Autoloaded options — settings that WordPress loads on every request, even if they are large and rarely used.

There is also a fourth category worth watching: plugin-generated tables. Some plugins create their own tables, and those can grow quickly even when the core WordPress tables are under control.

Start with a backup, always

Before you remove anything from the database, make a fresh backup you can restore. If your host provides on-demand backups, use one now. If you use a backup plugin, confirm the backup completed successfully and is stored off-server if possible.

This matters because some “cleanup” tools are safe, but not all sites behave the same way. A plugin conflict, a custom theme, or a badly written extension can depend on data you did not expect.

Step 1: See what is actually large

Do not guess. First, check which tables are biggest and whether one table is unusually large compared with the rest. Your host may provide a database manager, or you can use a tool like phpMyAdmin if you are comfortable there.

Look for these clues:

• wp_options is much larger than expected.
• wp_postmeta grows quickly with page builders, WooCommerce, or heavy plugins.
• wp_posts is full of revisions and auto-drafts.
• Custom plugin tables are much larger than the WordPress core tables.

If you do not know what “normal” looks like for your site, the important question is not the absolute size. It is whether one table is growing far faster than the rest and whether that growth lines up with the slowdown you are seeing.

Step 2: Clean up revisions safely

Revisions are usually the easiest win. They are useful, but they can pile up fast on sites with frequent edits.

Safe ways to reduce revisions include:

• Delete old post revisions you no longer need.
• Keep a smaller number of future revisions per post.
• Review large pages or posts that are edited often, since they tend to generate the most clutter.

A careful cleanup tool can remove revisions while keeping current content intact. If you use a plugin, make sure it clearly says it is deleting revisions, not published content or page-builder data.

If you are editing by hand, proceed carefully. Revisions are stored as posts in the database, which means a mistaken delete can remove more than you intended. This is one place where a backup is non-negotiable.

Step 3: Clear expired transients

Transients are meant to be temporary cache entries. When they expire, they should disappear or become harmless. In practice, expired transients can accumulate, especially on sites with many plugins or external API calls.

In a healthy setup, clearing expired transients is usually safe. It may briefly make the site work a little harder while caches rebuild, but that is normal. The key is to target expired transients, not randomly remove all cached data if you are unsure how your site uses it.

If a plugin keeps recreating a huge number of transients, that is a sign to investigate the plugin itself. Cleaning the database helps, but it does not solve the underlying cause if something is generating junk constantly.

Step 4: Check autoloaded options before you delete anything

Autoloaded options are often the real hidden problem. WordPress loads autoloaded options on nearly every request, so a large set of them can slow down both front-end and admin pages.

The main question is not “How many options are there?” but “How much data is being autoloaded?” A small number of large options can hurt more than a big number of tiny ones.

What to look for:

• Options with large serialized values.
• Options created by plugins you no longer use.
• Repeatedly updated cache-like data that should not be autoloaded.

Be careful here. Do not disable autoload or delete an option just because it looks big. Some options are critical site settings, and some plugins expect their data to load automatically. If you are not sure what an option does, identify the owning plugin first.

Step 5: Remove stale plugin leftovers

A lot of database bloat comes from plugins that were installed, used, and later removed. Some clean up after themselves. Many do not.

After you verify a plugin is truly gone and no longer needed, you can look for leftover tables and orphaned options it created. This is often the difference between a one-time cleanup and a site that fills back up within weeks.

If you are unsure whether a table belongs to an active feature, leave it alone. Plugin tables are not always named clearly, and some plugins use several tables with related data.

Step 6: Fix the source, not just the symptoms

Cleaning the database once is helpful. Preventing the same growth is better.

Ask these questions after cleanup:

• Which plugin is creating the most revisions, options, or transients?
• Can revisions be limited going forward?
• Is an old plugin still storing data even though it is inactive?
• Is a cache or import tool generating new transient data too aggressively?

If a plugin is creating excessive load every day, the best fix may be configuration, replacement, or removal. Otherwise, you will keep doing “maintenance” for a problem that should have been engineered out.

What not to do

It is easy to do harm while trying to optimize a database. Avoid these mistakes:

• Deleting rows directly from tables you do not understand.
• Running a “clean everything” query copied from the internet.
• Removing all transients without knowing how your cache stack works.
• Changing autoload flags on critical options without checking what uses them.
• Assuming a smaller database is always a faster one.

Good cleanup is selective. It removes junk and preserves the data your site still depends on.

How to prevent database bloat from coming back

The easiest prevention is routine housekeeping and better data habits. A stable site usually has:

• Regular backups before updates and cleanups.
• Limited post revisions where it makes sense.
• Periodic review of old plugins and their leftovers.
• Performance monitoring so slowdowns are caught early.
• A maintenance process that includes the database, not just files and plugins.

If your site changes often, set a recurring reminder to review growth every month or quarter. On content-heavy or WooCommerce sites, that cadence can make a real difference.

When to call a professional

Bring in a professional if the slowdown is affecting revenue, if you are not sure which table or option is safe to touch, or if the cleanup involves custom tables, a complex plugin stack, or a site that has already had problems after a failed optimization. Database work is one of those areas where one wrong delete can create a much bigger repair than the original slowdown.

If you want a safe diagnosis first, use Mend’s free diagnosis. A senior engineer can identify what is actually bloated, quote a flat price before work begins, and clean it up on a backup-first workflow. If you already know the site is stuck and need it handled quickly, Emergency Rescue is the right place to start.

For ongoing help keeping WordPress healthy, a Care Plan can cover updates, backups, security, and uptime monitoring so bloat and other maintenance issues are caught earlier.

Related reading

If you are tracking performance problems beyond database growth, these guides may help:

• Speed Up WordPress: Why Your Site Is Slow and How to Fix It
• What a Good WordPress Maintenance Routine Looks Like
• Speed Up WooCommerce by Fixing the Real Bottlenecks

If a cleanup seems simple but you are not fully sure what a table, option, or plugin is doing, stop and back up. In WordPress, careful removal is faster than fixing a mistake later.