Database clean-up
Over the years, tables, logs and records accumulate that nobody needs any more. They make backups large, queries slow and upgrades risky. Because nobody knows for sure what is still used, nobody dares to touch it. I clarify this systematically and clean up in a controlled way.
Discuss a clean-upStefan Pilz · PHP development and databases · 100% remote
SERVICE OVERVIEW
A database clean-up means finding tables, records and structures that are no longer needed and removing or archiving them in a controlled way. I work with MySQL and MariaDB, as commonly used by custom PHP applications, WordPress and online shops. Every deletion is preceded by an inventory and a tested backup.
A database usually grows unnoticed. Log tables fill up every day, plugins leave their tables behind after uninstallation, test data remains and records point to entries that no longer exist. At some point the database is many times larger than the actual content.
The consequences show up in many places: backups take a long time, queries get slower, upgrades with database changes drag on, and personal data is kept longer than necessary. The GDPR requires such data to be stored only for as long as is necessary for its purpose.
SERVICE SCOPE
I record every table with its size, number of records and growth. Then I check which tables and columns appear in the code at all, which queries actually run in production and when a table was last written to. The result is a list with three groups: in use, not in use, unclear.
This includes log, session and cache tables without a retention rule, tables of removed plugins, test data, orphaned records without a parent record and duplicates. In WordPress, stored revisions, expired transients and settings that are loaded on every page view come on top.
Every change is preceded by a backup whose restore has been tested. Doubtful tables are first renamed or archived and only deleted after an observation period. I delete large volumes of data in small batches so that operation is not blocked. Afterwards I review indexes and, if you wish, set up automatic retention rules so that the ballast does not build up again.
TYPICAL SITUATIONS
The following points describe typical situations, not documented client projects.
A large share of the storage goes to logs, sessions or statistics that nobody analyses. Backups and copies for staging environments take correspondingly long.
Plugins and modules were removed, their tables were not. Nobody knows whether something still accesses them. That is exactly what the inventory clarifies.
Old customer accounts, form submissions or logs with IP addresses are never deleted. We define what can go and what must stay because of retention obligations, and implement it technically.
DELIVERABLES & SCOPE
We agree the deliverables before starting. Depending on the scope, these may include:
Which data must be kept for legal reasons, such as invoices or accounting records, is something you define with your tax or legal adviser. I implement these requirements technically. If external systems access the database, we need to include them in the inventory.
For an initial assessment, the system in use, the approximate size of the database and a description of the problem help. We agree the scope of the inventory and the clean-up beforehand.
WORKING TOGETHER
We arrange access through a secure channel. I create a full backup and test the restore.
You receive a list of all tables with usage and recommendation and decide what gets cleaned up.
I clean up in a copy first, then in the live system, step by step and at agreed times.
If you wish, I set up retention rules so that logs and outdated data are removed automatically in future.
RELATED SERVICES
Fix slow pages, poor PageSpeed scores and Core Web Vitals issues at the source.
Find out which code is still needed and remove the rest safely.
Adapt your code to PHP 8.4 or 8.5 before your current version stops receiving security fixes.
QUESTIONS & ANSWERS
Then it can be restored. Every clean-up is preceded by a tested backup, and unclear tables are archived or disabled first rather than deleted immediately.
Usually not. Large deletions run in small batches and at quiet times. If structural changes require a short interruption, we agree the time in advance.
Often yes, especially when large tables are queried on every page view or indexes are missing. Measurements before and after show how much it helps. Other bottlenecks are covered by page speed optimisation.
The GDPR actually requires that personal data is not kept longer than necessary. At the same time there are retention obligations, for example for invoices. What exactly may be deleted is for you to define with your tax or legal adviser; I implement it technically.
MySQL and MariaDB, as commonly used by custom PHP applications, WordPress, Joomla, TYPO3 and online shops.
NEXT STEP
Tell me the system in use, the approximate size of the database and what you have noticed. I will get back to you with a proposal for the inventory.
Your enquiry goes directly to me, Stefan Pilz. We agree the scope and costs before you commission any work.
I read your enquiry and get back to you. Together, we clarify your goals, constraints and open questions.
Depending on the project, we start with a specific implementation or an analysis agreed in advance.
You know which services and deliverables are included. We agree on scope, effort and costs before you commission the work.