If your site runs WordPress, WooCommerce, or any dynamic CMS, most of what makes it your site doesn't live in a file. The posts, products, orders, comments and settings all live in a database, and they get queried fresh on every page load unless something is caching the result. That affects your backups and your migrations, and very often it's the real reason a site feels slow.
What does the database store?
Your theme files, plugin code and images sit in the file system, on the disk inside your server. Your content is in the database:
Posts and pages
Product data and orders
Comments
User accounts
Site configuration and settings
WordPress organises this into tables with names like wp_posts, wp_postmeta, wp_options and wp_terms. Loading a single page can take several queries: the content itself, its metadata, its category and tag assignments, plus various site-wide settings.
Why does this affect page speed?
Something most site owners don't realise: WordPress doesn't just load the settings a page needs. Any option in wp_options marked "autoload" gets pulled into memory on every request, whether that page uses it or not.
On a fresh install this isn't a problem. But plugins add autoloaded options over time, and few of them clean up after themselves. A few years and a few dozen plugins later, a site can be loading a lot of data it doesn't need before it has served the visitor anything at all.
This is a common cause of slow time-to-first-byte, and it's easy to miss because it has nothing to do with server hardware or PHP performance. The database is just doing more work than it needs to.
Why does this matter for backups?
Because your content lives in the database, a backup that only copies your file system is incomplete. A proper backup has two parts:
A file-system backup (themes, plugins, uploads, core files)
A database export (commonly done with mysqldump or an equivalent tool)
Skip the second part and you can restore a site that looks right but is missing every post, product, order and setting created since your last full backup.
Why does this matter for migrations?
Moving a site to a new host or domain has the same requirement: an accurate database export plus a copy of the files.
One thing to be careful with. WordPress stores some of its settings as PHP serialized data, which is essentially arrays with a strict length-based format baked in. If you update a URL across the database with a plain find-and-replace, you can break that format without any obvious error. Parts of the site start behaving oddly, or fail silently.
A serialization-aware search-and-replace tool avoids this. A text editor's find-and-replace does not.
Is the database really why my site is slow?
Often, yes. When a site is slow, the cause is frequently the database rather than the server. Usually it's one of these:
Queries that aren't properly indexed
Table bloat from years of unremoved post revisions
A large number of autoloaded options, as covered above
None of these show up as a CPU or PHP problem. The server can be performing fine while the database does far more work than it should to answer each request.
What can help?
For a database-bound site, one of the more effective fixes is putting an object cache like Redis or Memcached in front of the database. Instead of running the same query again for every visitor, the result gets cached in memory and reused. On sites where the database is the bottleneck, that cuts repeated query load considerably.
Here's what changes:
Without an object cache | With an object cache | |
|---|---|---|
Repeated queries | Re-run against the database on every request | Served from memory after the first run |
Autoloaded options | Reloaded from the database each time | Cached after first load |
Server work per request | Scales with query volume | Scales with cache hit rate |
Effect on TTFB | Grows as content and plugins grow | Stays closer to flat |
Best suited for | Small, low-traffic, mostly static sites | Sites with real query volume: WooCommerce, membership sites, high traffic |
At hosting.com, our hosting environments are built with this in mind, so your site's database can keep up as your content grows.
FAQ
Do I need to think about the database if I'm not a developer? Not in detail, but it's worth knowing it exists separately from your files. It changes what "backup" and "migration" actually mean, and it's often the real cause of a slow site even when nothing points to it on the surface.
Does every WordPress site need an object cache? No. A small site with light traffic and few plugins may never notice the difference. It matters more as query volume grows: WooCommerce stores, membership sites, or anything with real traffic, where the same queries would otherwise run for every visitor.
Can I speed up my database without adding an object cache? To a point, yes. Removing old post revisions, cleaning up unused plugins that left autoloaded options behind, and making sure queries are properly indexed all help. An object cache specifically addresses repeated query load, so it's not the only option.
Is a file-system backup with no database export still useful? It preserves your theme, plugin and media files, but it isn't a complete backup on its own. Restore from it alone and you get back an empty version of your content, since posts, products and settings live in the database.
Why does a plain find-and-replace break things during a migration? WordPress stores some settings as PHP serialized data, which includes a length value as part of the format. A text-based find-and-replace changes the string without updating that length, which corrupts the data silently rather than throwing an obvious error.