The fastest way to see what's taking up space is phpMyAdmin's database view: open cPanel from your service page, launch phpMyAdmin, and check the Size column at the bottom of the table list. Once you know which tables are the problem, the fix is usually one of three things: old log or session data piling up, leftover tables from removed plugins, or tables that need optimizing after years of deletes and updates.
Finding the largest tables
In phpMyAdmin, click your database name in the left sidebar, then look at the table list. Click the Size column header to sort by size descending. For WordPress and most CMS platforms, the usual offenders are:
wp_optionswith a bloatedautoloadcolumn (plugins that never clean up transients)- Session or cache tables from plugins (anything with "session", "cache", or "log" in the name)
- Revision tables (
wp_postswith hundreds of post revisions per page) - Spam or trashed comment tables that were never emptied
If you don't have a CMS-specific pattern to check, sort by size and investigate anything unexpectedly large for what it should hold.
Removing what you don't need
Before deleting rows directly in phpMyAdmin, check whether your application has a built-in cleanup tool. WordPress plugins like autoload-heavy option cleaners, or the "empty trash" and "delete revisions" actions in the dashboard, are safer than raw SQL because they respect foreign keys and caching.
When you do need to run SQL directly, phpMyAdmin's SQL tab lets you run queries against the database. A few examples that commonly free up space:
DELETE FROM wp_posts WHERE post_type = 'revision'; DELETE FROM wp_options WHERE option_name LIKE '_transient_%';
Always back up before running deletes you haven't tested. cPanel's Backup Wizard, under Files, can generate a backup you can use as a rollback point if a query removes more than you intended.
Optimizing tables after cleanup
Deleting rows doesn't automatically shrink a table's file size, especially with the InnoDB engine, which many CMS platforms use by default. The space stays allocated until you optimize. In phpMyAdmin, select the tables you cleaned up and use the table list's Optimize table option to run it. For large tables this can take a few minutes and briefly locks the table, so run it during low-traffic hours if the site is live.
When exports and imports get involved
If reducing table size still leaves you needing to move or archive the database, see importing and exporting large databases for the exact commands.
It's also worth keeping an eye on overall disk usage beyond just the database, since databases share the same storage quota as your files and email. Checking your hosting resource usage covers where to see your current disk usage and what happens as you approach the limit.
When to contact support
If a table won't optimize, a query times out repeatedly, or you're not sure whether a table is safe to delete, open a ticket from the portal. Support is real humans, not a bot queue, and they can look at the specific table structure before you risk removing something your application still needs.