Your Database Is Rotting From the Inside — And Your Traffic Stats Won't Tell You
There's a particular kind of website problem that's almost designed to be ignored. It doesn't throw up error messages. It doesn't crash your site on a Monday morning. It doesn't show up in your Google Analytics overview as anything obviously alarming. It just... slows things down. Gradually. Imperceptibly. Until one day a customer mentions your checkout took forty-five seconds to load, and you genuinely don't believe them.
Welcome to database decay — the slow puncture of the web development world.
For a lot of UK businesses running WordPress, WooCommerce, or any CMS-backed site, the database is something that exists in the background. It was set up when the site was built, nobody's touched it since, and frankly, nobody's entirely sure what's in it. That's precisely the problem.
What Actually Happens Inside a Neglected Database
Every time someone visits your site, submits a form, makes a purchase, or reads a blog post, your database is doing work. It's logging revisions, storing session data, queuing actions, and accumulating records. Most of this is entirely invisible to you.
WordPress alone, left to its own devices, will create multiple post revisions every time you edit a page. Update a product description ten times? That's potentially ten additional rows in your database that will never be used again. Multiply that across years of operation and hundreds of pages, and you've got serious bloat.
Then there are transients — temporary data your site stores to speed things up — that often never get cleaned out. Spam comments that were never deleted. Order records from abandoned carts. Plugin data left behind after you uninstalled something in 2021. It all accumulates.
The result isn't a crash. It's latency. Queries that should take milliseconds start taking seconds. Pages that once loaded instantly now pause, almost as if thinking. Your server isn't struggling with traffic — it's struggling with the weight of its own history.
The Warning Signs Most Business Owners Miss
Because this degradation is gradual, it rarely triggers alarm bells. But there are tells, if you know what to look for.
Admin panels that feel sticky. If logging into your WordPress dashboard and navigating between screens feels noticeably slow — even when your front-end seems okay — that's often a database issue. Admin queries tend to be heavier, and a bloated database shows its age there first.
Search functionality that crawls. On-site search is one of the most database-intensive operations on most websites. If your internal search results take more than a second or two to appear, that's a red flag worth investigating.
Reports and filtered views timing out. WooCommerce shop owners, take note. If pulling up orders by date range, generating sales reports, or filtering products starts throwing timeout errors or just hanging indefinitely, your database tables are almost certainly unindexed or bloated beyond what your server can handle comfortably.
TTFB creeping upward. Time to First Byte — the delay between a browser requesting a page and receiving the first response — is a Core Web Vitals metric that's directly affected by database performance. A TTFB above 600ms on a standard page is worth investigating. Tools like Google PageSpeed Insights or GTmetrix will surface this.
Diagnosing the Problem Without Calling in a Specialist
You don't need to be a database administrator to get a sense of what's going on. A few accessible tools can give you a useful picture.
Query Monitor is a free WordPress plugin that shows you exactly which database queries are running on any given page, how long they're taking, and which plugin or theme is responsible. It's the kind of tool that can produce a genuine "aha" moment — you'll often find a single poorly-written plugin query is responsible for the majority of your load time.
WP-CLI (WordPress Command Line Interface) lets you run database diagnostics and optimisation commands directly if you have server access. Running wp db optimize won't fix everything, but it's a legitimate first step.
phpMyAdmin, available through most UK hosting control panels, lets you inspect table sizes directly. If your wp_posts table is running into the hundreds of megabytes on a site with a modest amount of content, something is off.
For non-WordPress sites, most hosting providers offer access to database management tools, and the principle is the same: look at table sizes, look at query logs if they're enabled, and look for tables that seem disproportionately large relative to what they should contain.
What You Can Actually Do About It
The good news: database optimisation is one of the few performance interventions that doesn't require a rebuild. It's unglamorous work, but it pays dividends quickly.
Audit and limit post revisions. Adding a simple line to your WordPress wp-config.php file can cap the number of revisions stored per post. Retrospectively cleaning up existing revisions using a plugin like WP-Sweep or Advanced Database Cleaner takes minutes and can reduce database size dramatically.
Clear out transients and orphaned data. This is housekeeping, essentially. A good database cleaning plugin will identify and remove expired transients, orphaned metadata, and unused tables left by deactivated plugins. Run this once, then schedule it monthly.
Add proper indexing. This is where things get slightly more technical, but it's worth understanding. Database indexes are like a book's index — they allow the database to find information without reading every single row. If your developer set up custom tables or you've been running a WooCommerce store for years, there's a reasonable chance some tables are missing indexes on columns that get queried frequently. This is the kind of thing a competent developer can audit and address in a few hours, and the performance uplift can be significant.
Consider object caching. Tools like Redis or Memcached store the results of common database queries in memory, so the database doesn't have to run the same query repeatedly. Many UK hosting providers now offer Redis as a bolt-on, and for high-query sites it's one of the best performance investments available.
Separate your database if you're on shared hosting. If your site has grown considerably since it was first set up on a budget shared hosting plan, the database may genuinely be competing for resources with other sites on the same server. Moving to a VPS or managed hosting environment with a dedicated database instance is often the right call at this stage.
The Bigger Picture for UK SMEs
There's a tendency in the small business world to treat the website as a thing that's been built and is therefore finished. It's not. It's infrastructure, and like any infrastructure, it requires maintenance. The database is the foundation of that infrastructure — the part that holds everything together — and it's also the part that gets the least attention.
The irony is that database issues often get misattributed. Businesses assume their hosting is the problem, or their theme, or their page builder. They upgrade their hosting plan and see modest improvement. They switch themes and gain nothing. Meanwhile, the actual culprit — a bloated, unindexed, query-heavy database — continues to drag on performance regardless.
If your website feels slower than it should, and your traffic figures don't seem to explain it, start underground. The problem is almost certainly in the data.
At WebDorking, we've seen this pattern more times than we can count — sites built carefully, launched well, and then left to accumulate digital sediment until performance becomes genuinely painful. The fix is rarely dramatic. But it does require someone to actually look.