A website database is the organised store of information that a dynamic site reads from and writes to: the text of every page, the menus and settings, user accounts, orders and the enquiries people send through forms. On most small business sites it is a MySQL or MariaDB database sitting on the hosting account next to the site’s files.
How a website database works
A content management system such as WordPress keeps its code in files and its content in the database. When someone requests a page, the server runs the CMS code, which asks the database for the right records, assembles them into HTML and sends the result to the browser. A WordPress database is split into tables: one for posts and pages, one for the extra details attached to them, one for users, one for site-wide options, and more added by plugins such as form builders, shops and SEO tools.
Because every uncached page view triggers database queries, the database’s size and tidiness affect speed. Caching helps by saving finished pages or query results so the database is asked less often. The database is also separate from the site files in another important sense: backing up the files alone does not back up the content.
Why it matters
For a UK business, the database is often where personal data quietly accumulates. A contact form plugin that saves every submission keeps names, email addresses, phone numbers and whatever people wrote in the message box, sometimes for years. Under UK GDPR that is personal data, which brings duties: keep it only as long as you need it, protect it properly, and be able to find and hand over or delete one person’s records if they ask. Someone can make a subject access request and you normally have one month to respond, which is hard if you do not know what your plugins store.
The database also matters for performance and resilience. Years of post revisions, expired temporary data, spam comments and leftovers from deleted plugins slow queries down. And a database that is not backed up, or is backed up only on the same server, can be lost along with the site in a hack or hosting failure.
Common mistakes
- Storing every enquiry forever. If submissions are emailed to you and also saved in the database with no deletion schedule, you hold more personal data than you need. Set a data retention period and enforce it.
- Backing up files but not the database. Restoring a site without its database gives you a theme with no content.
- Editing the live database by hand. A search-and-replace done wrongly can break serialised data and take the site down. Test on a copy.
- Leaving plugin tables behind. Uninstalling a plugin often leaves its tables and options, including stored personal data.
- Weak access. Shared database passwords and phpMyAdmin left open to the internet are common weak points.
How to act on it
Start by finding out what your database holds. List the plugins that store submissions, orders or user accounts, and check how far back their records go. Decide a retention period for enquiries, write it into your privacy notice and either switch off database storage (relying on email and your CRM) or schedule deletion.
Confirm your website backup includes the database, runs daily for a site that changes often, and is stored somewhere other than the server. Then tidy up: limit stored revisions, clear expired temporary data and remove tables from plugins you no longer use, always after taking a fresh backup. Slow database queries are one of the server-side causes of poor speed I look for in a technical SEO review.