Who runs it on Tuesday?

The same arithmetic, sharper. Somewhere in most estates there is a database that has been running for years, that something important depends on, and that nobody currently employed is confident enough to touch. The report that took four seconds takes forty. There is a version upgrade everyone agrees is overdue and nobody will start. The backup job reports success and has never been restored from.

An engineer who can read a query plan, plan a version move and rehearse a restore is a scarcer hire than an administrator and a more expensive one, for work that is genuinely intermittent. Heavy for the six weeks of a migration or a performance crisis, quiet for the eight months after. So the post goes unfilled, the work goes to whoever is nearest, and the estate becomes something everybody routes around.

• Performance, with the reason attached. Not “we added an index”, which query, why it degraded, what it costs you now, and what it does at twice the volume.
• Version upgrades and migrations: on-premise to managed, one engine to another, or simply off a release that is out of support, with a tested rollback and a cutover somebody has rehearsed.
• Backup you have restored from, on the schedule the business assumes rather than the one the job happens to run. An untested backup is a belief, not a control.
• Patching, capacity and the unglamorous maintenance that stops the crisis being scheduled for you.
• Modelling, where a schema has stopped fitting what the business does, which is also what makes reporting trustworthy later, and is where this connects to data and AI rather than being the same work.

This is done day to day by engineers who came up through databases, which is why we offer it rather than treating the database as somebody else’s dependency. Inside a retainer, or as a single piece of work when there is a specific thing wrong.

Threshold alerts catch the outage and miss almost everything that costs money. A workload that has been quietly drifting upward for three weeks never crosses a threshold; a job that runs twice as long after a release never crosses one either; and a spend line that doubles on the 3rd of the month is invisible until the invoice arrives on the 1st.

• Anomaly detection on spend and behaviour: the alert is raised against what this estate normally does, not against a number somebody typed in once.
• A real-time cost dashboard you can open yourself, by account, project, environment and team, rather than a monthly PDF that arrives after the money is spent.
• A person between the alert and you. Every anomaly is read by an engineer before it becomes either a change or a phone call. Automated remediation happens only where you have signed off the specific action in advance.

Two shapes, and you pick. A support retainer: a fixed monthly figure sized on devices, sites, users and cover hours, which is the right answer when you want the budget line to be predictable. Or a variable model priced on the estate under management, which suits an estate that is still growing or seasonal, and which falls when the estate shrinks.

Either way you get the model itself, not just the number, so you can see what changes when you add a site or double the team. And if the honest answer is that you need two days a month rather than a retainer, we'll quote that instead.

The first thirty days are documentation and stabilisation: what exists, what's at risk, what's out of support, what has no backup. You get that as a written baseline whether or not you stay with us afterwards. We don't do the six-week discovery phase that bills like a project and produces a slide deck.