Clean
Clear out what the database is carrying but no longer needs, so the working set shrinks back towards the data your site actually serves.
Database maintenance
Every WordPress database grows heavier with age. Zinn Digital® treats that as an engineering problem, not a support ticket: clean, optimise and repair run as an automated workflow you buy in one click — and the platform offers it to you at the moment it sees a database bloating.
A WordPress site's files stay roughly the size you built them. Its database does not. Tables accumulate, indexes drift out of shape, storage engines leave space allocated that nothing is using any more, and occasionally a table ends up in a state that needs repairing rather than tuning. None of this announces itself. The site simply gets slower, queries take longer, and the first anyone notices is a page that used to feel instant and now doesn't.
On a single site that is an annoyance. Across a portfolio or a network of hundreds of sites it is a compounding tax — every one of them a little heavier than it needs to be, every one of them asking more of the database server than it should.
Zinn Digital® handles this the same way we handle the rest of the platform: as an automated, repeatable operation. Database maintenance is a first-party service you buy from the dashboard, and buying it runs the optimisation job immediately. There is no queue to join and no engineer to wait for.
Three operations, applied to the site's MariaDB database, run as one job.
Clear out what the database is carrying but no longer needs, so the working set shrinks back towards the data your site actually serves.
Reclaim allocated-but-unused table space and put indexes and statistics back into the shape the query planner expects, so reads stop doing more work than they need to.
Detect and repair tables that have ended up in a bad state — the failure mode that turns a slow site into a broken one if it is left alone.
The purchase charges through billing or your wallet, fulfils, notifies you and marks itself complete. If something goes wrong, refunds and disputes run through the same billing path as everything else you buy from us.
First-party services on this platform come in two shapes. Some are staff-fulfilled: buying them creates a task in our admin queue, routed to the right department, tracked and updated. Database maintenance is not one of those. It is automated — the purchase triggers a Temporal workflow that runs the optimisation job directly against your site. Instant, zero-touch.
That matters more than it sounds. Temporal workflows are durable, retryable and idempotent by design, which is the standard every long-running operation on this platform is held to. If a step fails partway, the workflow retries from where it was rather than half-finishing and leaving your database in an ambiguous state. If a retry re-runs an operation that already succeeded, that is safe by construction.
It also means the service does not degrade under load. Ten customers buying database maintenance at once do not queue behind each other waiting for the same engineer — they are ten workflow executions, and the platform is built to scale them horizontally.
The platform already watches your sites. It uses what it sees to offer the right service at the right time.
There is a dedicated Extras section in the dashboard where you can browse and buy first-party services whenever you like. But the more useful path is the one that finds you: contextual upsells. Database maintenance is surfaced against a bloated database, speed optimisation against a slow site failing Core Web Vitals, malware cleanup against a flagged site, migration at signup.
Those prompts are driven by real observability signals — the same per-site metrics and resource telemetry the platform collects to operate the fleet, not a generic monthly nag. And the AI assistant can both suggest the service and initiate it for you, so the gap between noticing a problem and fixing it is a conversation rather than a project.
Maintenance is the automated layer on top. Underneath, every site ships with full database control.
Each site gets its own database, with support for multiple databases and multiple database users where a project needs them.
Both are built into the dashboard and single-sign-on'd — no separate credentials to manage, no separate login to protect.
Turn external database access on when a tool or a developer needs it, and off again when they don't. Closed by default is the sane state.
Offload repeated reads to Redis so the database is answering fewer queries in the first place. Prevention alongside cure.
The other half of database performance on shared infrastructure is the part you don't control: what everyone else's sites are doing to the same server. Our worker fleet runs MariaDB with CloudLinux MySQL Governor, which throttles database usage per site. One site running heavy queries is constrained inside its own limits rather than slowing the server for its neighbours.
That sits alongside the rest of the isolation stack — LVE caps on CPU, RAM, IO, IOPS and processes, and CageFS giving each tenant an isolated filesystem view. The design intent throughout is the same: a problem on one site stays on that site.
So when your database is slow, the answer is something you can actually act on. It is your database, and database maintenance is the button that fixes it.
Database operations are part of the MCP tool catalogue, so any MCP-capable agent can run them on your behalf.
Our hosted MCP server exposes the platform to Claude Code, Cursor, ChatGPT, Claude Desktop and any other MCP-capable agent — one connection rather than a separate integration per tool. The database tools in that catalogue include guarded query, optimise, and backup and restore. Buying Extras is exposed too, behind an explicit confirmation step.
Everything the agent can do is bounded by the identity it connected as. Tokens are issued through OAuth 2.1, scoped to your organisation and your RBAC permissions, per-tool and revocable. Destructive actions require explicit confirmation, spend caps apply to AI-triggered paid actions, and every MCP action is written to the audit log with identity, tool, arguments and result.
In practice: your agent notices the database is heavy, asks whether it should run maintenance, you confirm, and the workflow runs. The AI is a driver, not an unsupervised operator.
First-party services are data on this platform, not hardcoded features.
In most cases you won't have to work it out yourself. The platform monitors per-site resource usage and surfaces database maintenance as a contextual offer when it sees a database bloating, and the AI assistant can flag it and initiate the job for you. You can also browse and buy it any time from the Extras section of the dashboard, and inspect the database yourself through the embedded phpMyAdmin or Adminer.
We minimise the risk rather than pretend it away. The job runs as a Temporal workflow — durable, retryable and idempotent — so a failed step retries rather than leaving work half-applied, and a repeated operation is safe by design. Every run is recorded in workflow history. On Footprint-Free plans, daily backups are retained for 30 days with one-click restore, so there is always a recent restore point to fall back on if you want one. Take a backup before any significant database change is good practice regardless of who is running it.
It complements them. Every site keeps its own MariaDB database with embedded, single-sign-on'd phpMyAdmin and Adminer, support for multiple databases and users, and a remote access toggle. Database maintenance is the automated version of the routine work — clean, optimise, repair — for when you would rather buy the outcome than run it by hand.
Services on this platform are fulfilled one of two ways. Staff-fulfilled services create a task in our admin queue, routed to the right department with status tracking and customer updates. Database maintenance is automated: buying it triggers the workflow directly, with no human step in between. That is the whole point of building it as a workflow rather than a process.
Yes. Database optimise, guarded query, and backup and restore are all in the MCP tool catalogue, and buying Extras is exposed with a confirmation step. Your agent connects over OAuth 2.1 with a token scoped to your organisation and your RBAC permissions — per-tool, revocable, spend-capped on paid actions, and every call audit-logged. It can only do what you could do.
Database maintenance is a purchasable first-party service rather than a plan inclusion — you buy it when you need it, at the price shown in your currency in the dashboard, charged to your billing account or wallet. Eligibility is set per product line, so what appears in your Extras section reflects the product line you are on. Everything you need to try the platform is in the card-free 7-day trial: no payment details, up to five sites on Footprint-Free Hosting.
The fleet runs MariaDB with CloudLinux MySQL Governor, which throttles database usage per site specifically so one site's heavy queries cannot slow the server for the rest. That sits alongside LVE resource caps and CageFS filesystem isolation. The design goal throughout is containment — problems stay in the cage they started in.
Start a card-free 7-day trial on Footprint-Free Hosting — no payment details, up to five sites — and see how the platform surfaces and fixes the problems you'd otherwise find out about from a slow page.
Start free