A slow WordPress admin or a database that keeps growing usually traces back to three things: revisions piling up in wp_posts, expired transients never getting cleaned out of wp_options, and options with autoload = yes that get loaded on every single page request whether they're needed or not. Fix all three and most "WordPress feels sluggish" complaints go away without touching hosting resources.
Autoload bloat: the most common offender
Every page load, WordPress runs one query that pulls every row in wp_options where autoload = 'yes' into memory, before it even starts rendering. On a clean install this is a small, fast query. On a site with a few years of plugin churn, it's common to find that table has grown to tens of megabytes of autoloaded data, most of it from plugins that were deactivated months ago but left their settings behind.
You can check the damage with wp-cli, if your plan has shell access:
wp db query "SELECT SUM(LENGTH(option_value)) AS bytes FROM wp_options WHERE autoload='yes';"
If that number is in the megabytes rather than kilobytes, autoload is your problem. Cross-reference against active plugins in wp-admin → Plugins: any option_name prefix belonging to a plugin you no longer use can usually be deleted outright. Don't hand-edit rows you don't recognize; some autoloaded options (like siteurl, active_plugins, and theme mods) are meant to be there and removing them will break the site.
A WordPress optimization plugin like WP-Optimize surfaces this without needing shell access. It has a dedicated database tab that lists the largest autoloaded options and lets you flip individual ones to autoload = 'no' or delete orphaned rows from uninstalled plugins.
Revisions: cap them, don't only delete them once
By default WordPress keeps unlimited revisions of every post and page. A frequently edited page can accumulate hundreds of revision rows, each a full copy of post content in wp_posts. Deleting the existing pile helps once, but revisions come right back unless you cap how many WordPress keeps going forward.
Add this to wp-config.php, above the line that says /* That's all, stop editing! */:
define('WP_POST_REVISIONS', 5);
Set it to false to disable revisions entirely, though keeping a small number (3-10) is usually safer since revisions are your undo history for content edits. This setting only affects new revisions, so pair it with a one-time cleanup of the backlog. With wp-cli:
wp post list --post_type=any --format=ids | xargs -I{} wp post delete-revisions {}
Without shell access, WP-Optimize's cleanup tab includes a revisions counter and a one-click delete for everything beyond a threshold you set. Either way, a database backup first is cheap insurance, and you already have one: server-level daily backups run automatically on Flashcloud hosting, so a bad cleanup run is a one-click restore away, not a disaster.
Transients: expired cache data that never gets swept
Transients are WordPress's built-in temporary cache: plugins use them to store things like API responses or computed data with an expiration time. The problem is WordPress only deletes an expired transient the next time something tries to read it. A transient nobody ever requests again just sits in wp_options indefinitely, expired or not.
Clear them with wp-cli:
wp transient delete --expired
Or the more aggressive version that clears all transients, forcing plugins to regenerate what they actually need:
wp transient delete --all
WP-Optimize and similar plugins expose the same action as a button in their cleanup tab, alongside options to also clean up spam comments, trashed posts, and orphaned postmeta in the same pass.
Object caching changes the math
If your site runs on Redis object cache (pre-configured on Flashcloud WordPress installs), transients get stored in Redis instead of wp_options automatically, which sidesteps the expired-transient problem entirely for any plugin using the standard transients API. Autoload bloat and revision growth are unaffected by object caching since those live in the actual post/options tables, not the object cache layer, so they still need the cleanup steps above regardless of caching setup.
A sane maintenance routine
- Set
WP_POST_REVISIONSinwp-config.phponce, so the backlog stops growing. - Run a transient and revision cleanup monthly, either via wp-cli or a plugin's cleanup tab.
- Check autoload size after major plugin changes (installs, removals, migrations) since that's when orphaned options accumulate.
- Take a backup before any bulk database cleanup, even though one already exists automatically.
When to contact support
If a cleanup query hangs, times out, or you're not sure whether an unfamiliar wp_options row is safe to delete, stop and open a ticket from the portal (Support → New ticket) or use live chat. This is real people, not a bot, and they can look at the actual database state with you before anything gets deleted that shouldn't be.