When a site gets slow, everyone looks at images and plugins. Very few people look at the database, which is exactly where the worst slowdowns hide on sites with a few years behind them. A bloated database means every visit has to sift through millions of junk rows to find the ten that matter, and no caching plugin fixes that, because the problem shows up precisely when the cache isn't available: saving a post, processing an order, running a search.
Why databases get dirty on their own
You don't have to do anything wrong to end up with a bloated database; letting time pass is enough. Content management systems store far more than what you see. Every time you edit a post, a full revision is saved. Every plugin you install and later delete usually leaves its tables and options behind. Every spam comment that arrived and got filtered still occupies space. Every temporary value stored "just for a while" to speed something up stays there even though it expired a year ago.
The typical result is a modest-sized site with a database of hundreds of megabytes, where the real content occupies a tiny fraction and the rest is sediment.
The four most common sources of clutter
- Post revisions. If you write a long article and save it thirty times, you have thirty complete copies of the text. On a blog with five hundred posts, that alone can be half the database.
- Expired temporary data. Many plugins store temporary results to avoid recalculating them, with an expiration date. The problem is that almost nobody deletes the expired ones, and they pile up by the thousands.
- Orphaned metadata. When a post, product or user gets deleted, its associated data sometimes survives, pointing at something that no longer exists. Those rows are purely dead weight.
- Tables from uninstalled plugins. Uninstalling a plugin rarely deletes its tables. A site with years of trial and error can carry twenty tables nobody ever queries.
Safe cleanup, in the right order
First of all: a full database backup. That's not textbook advice, it's literally the only thing standing between you and an irreversible disaster. Export it from the panel, download it to your computer, and verify the file weighs what it should. Only then do you start.
The order I recommend goes from least to most risky. First, limit revisions going forward: one line in the configuration stops the problem from growing back. Second, delete old revisions, which is completely safe because the published version is untouched. Third, empty the trash for posts and comments, and delete spam. Fourth, remove expired temporary data. Fifth, and now more carefully, delete orphaned metadata. Sixth, and only if you're sure, drop tables from plugins you no longer use; here it's worth writing down the table name and searching for it before touching anything.
After all that comes a step almost nobody takes, and it's the one that actually returns disk space: optimizing the tables. Deleting rows leaves gaps the engine doesn't automatically reuse; optimizing reorganizes the file and compacts it. It's a one-click option in the panel's database manager.
Indexes: the difference between milliseconds and seconds
Here's the part that separates cosmetic optimization from real optimization. An index is essentially the alphabetical index at the back of a book: instead of reading a thousand pages to find one word, you go straight to it. Without an index, every query scans the entire table.
Core tables in well-known systems come properly indexed. The problem appears with tables created by poorly built plugins, or with custom queries filtering on a column nobody indexed. The classic symptom is a site that runs perfectly with a thousand records and crawls with a hundred thousand: that's almost always a missing index, not a lack of resources.
To detect it, most panels offer a slow query log, and many diagnostic plugins show how long each query takes while loading a page. If you see a query taking more than half a second and repeating on every visit, you've found your bottleneck.
The storage engine matters too
There's a technical difference with enormous impact that many older sites still carry: the table engine. The legacy engine locks the entire table when someone writes, so if ten people check out at the same time, nine of them wait. The modern engine locks only the affected row, supports transactions, and recovers far better from a crash. If your site is a few years old, it's worth checking which engine your tables use: converting them usually delivers an immediate, noticeable improvement on write-heavy sites like stores and forums.
Maintenance so it doesn't happen again
- Limit revisions to three or five per post permanently.
- Schedule a monthly cleanup of expired temporary data and trash with an automated task.
- Before installing a plugin, check what it leaves behind on uninstall; good ones offer a full-removal option.
- Check database size every three months. If it grew a lot without the content growing, something is accumulating.
- Watch internal logs. Security and analytics plugins record every visit; on a busy site that's millions of rows a year.
When the problem isn't the database but the server
There's a limit to what optimization can do. If your database is already clean and indexed and queries still drag, the problem is resources: slow disks, insufficient memory for the engine, or simply too many accounts competing on the same machine. The test is simple: if performance changes noticeably depending on the time of day, it isn't your database, it's the neighborhood.
At that point, migrating is the most efficient solution. That's why I recommend BanaHosting: pure SSD on Dell servers with RAID-10, which is exactly the kind of hardware where heavy queries stop hurting, plus 4 to 8 GB of RAM depending on the plan and processors from 3.8 to 6.9 GHz. It includes full cPanel to manage the database comfortably, daily JetBackup copies in case a cleanup goes wrong, and free migration of up to 3 sites with no downtime. Plans start at $4.95 a month with a 30-day guarantee.