Operations retainer

Most teams do not need a full-time DBA; they need a senior MySQL engineer available the day the replica falls behind, the schema change stalls, or the growth curve demands a capacity answer. The retainer is exactly that: reserved availability, hourly billing, and an engineer who already knows your system.

What it covers

• Incident escalation — a MySQL specialist joins your incident channel for the problems that are clearly database-shaped: lag cliffs, lock pileups, sudden plan regressions, disk-pressure emergencies.
• Schema-change management — online DDL run as a discipline: the right mechanism per change (instant DDL, in-place, or copy-based tooling), rehearsed on a production-sized copy, throttled against replication lag.
• Capacity planning — growth-curve analysis against buffer pool, disk, and connection headroom, so hardware decisions happen months before they become urgent.
• Monitoring buildout — the MySQL-specific layer most generic monitoring misses: digest-level query trends, real replication lag, InnoDB internals, and alerts tuned so that pages mean something.

How it works

Retainers begin with a short onboarding review so the engineer on call knows your topology, schema, and recent history before the first incident, not during it. Work is billed hourly against the retainer; unused availability is not a fee. You see who did what, and why, in plain engineering language.

Where it leads

Retainer work tends to shrink itself: each incident closed properly becomes monitoring, a runbook, or a fix that prevents the category. We consider that the point. When a bigger piece of work surfaces — an upgrade, a re-architecture — the same engineers carry it, with the context already paid for.