Database Optimisation & Tuning

Typical signs: the admin panel opens slower than the site itself, catalog search or filters take several seconds, reports and exports hang the server, the database weighs several times more than the actual content, and your host keeps complaining about exceeded limits.

We pull the slow query logs and see which ones eat the resources. We clean the junk out of the database: revisions, temporary records, logs, leftovers from removed plugins. We add indexes for the queries that actually run, rewrite the five heaviest, tune the database server parameters and put automatic cleanup on a schedule so it runs without you.

Yes. The audit and preparation happen on a copy of the database, and production changes are applied precisely and at an agreed time. For large tables we use non-blocking operations. If some step needs a short maintenance window, we warn you in advance.

It depends on what is actually slow. The biggest gains come from indexes on large tables: a query that took several seconds can drop to tens of milliseconds. At the audit stage we show you the current numbers and a forecast, and the report gives you the actual result.

No. We do not change application logic and we do not delete data that is in use. Indexes and server parameters are transparent to the code. Anything more involved is trialled on a copy and passes through site scenario testing before it is applied.

MySQL, MariaDB and PostgreSQL. That covers WordPress, WooCommerce, Laravel, Django and most custom projects. If you run a different engine, tell us at the start and we will scope it separately.

Every CMS and plugin writes more than you would think: page revisions, transient values, action logs, abandoned session carts, job queues, data from plugins removed long ago. Nobody clears it for years, and in the end the service tables outweigh the content itself.

Usually yes — the admin hits the database harder than the public side, because it runs without caching and makes complex selections. But if the cause is slow hosting or heavy plugins, we will see that at the audit and say so plainly rather than optimising the wrong thing.

With automatic cleanup running on schedule the database holds its shape for years. Problems coming back usually means the project grew several times over or new functionality with heavy queries appeared. Then another round is due, and it is visible in advance through rising response times.

Access to the database and the server, permission to take a dump, access to the site admin and a description of where you notice the slowness yourself. The rest — maintenance windows and priorities — we agree at the start.