What Does Managed Database Administration Actually Include?

Managed database services shows up on every IT vendor's homepage, but the phrase hides wildly different scopes. For one supplier it means a monitoring dashboard and a monthly email. For another it means a named DBA team that treats your SQL Server estate the way an internal hire would — proactively, accountably, and with a plan for the things that only show up at 2am or month-end.

If you are a mid-market IT leader (roughly 50–200 employees) evaluating whether to outsource database administration, the question is not “do you offer managed database services?” Everyone will say yes. The question is what does managed database administration actually include — and does that scope match the risk your business is actually carrying on SQL Server or Azure SQL today.

This article defines the service properly: the six core pillars, what "proactive" should mean in practice, what is usually excluded or sold separately, and the questions to ask before you sign.

What managed database administration is (and is not)

Managed database administration is the ongoing, proactive operation of your database estate by an external team acting as your DBA function — covering performance, availability, backup and recovery, security, patching, and capacity — with defined response times and regular reporting.

It is:

A continuous service, not a one-off health check
Proactive monitoring and tuning, not just "call us when it breaks"
Accountable to service levels (response and resolution times)
Documented — you should be able to see what changed and why
Scoped to specific platforms and environments in a written agreement

It is not:

A helpdesk ticket queue with database keywords
Generic infrastructure monitoring that happens to include a database server
A substitute for application-level performance work your software vendor owns
Unlimited scope for a fixed fee — good providers are explicit about what triggers additional cost

The six pillars of managed database administration

1. Proactive monitoring and alerting

The baseline distinguishing feature between managed administration and reactive support. This should include:

Continuous monitoring of instance health, wait statistics, blocking, and deadlocks
Disk space, log growth, and tempdb monitoring before they become outages
Job and maintenance plan failure alerts
Threshold-based alerting tuned to your workload, not generic defaults
A human reviewing trends weekly, not just automated alerts firing into a void

The difference between proactive monitoring and waiting for alerts is largely about what happens between incidents — whether anyone is looking at trend data before it becomes a page.

2. Performance management and tuning

Monitoring tells you something is wrong. Performance management fixes it and prevents recurrence:

Query and execution plan analysis for the workloads that matter
Index review and maintenance (not blanket rebuilds on a schedule regardless of need)
Statistics maintenance
Wait-type analysis to find the actual bottleneck, not just "add more CPU"
Configuration review (memory, MAXDOP, cost threshold for parallelism, and similar settings routinely left at install defaults)

Many performance problems attributed to "the hardware" are actually query design, missing indexes, or parameter sniffing — this is why diagnosing root causes matters more than throwing compute at the symptom.

3. Backup, recovery, and disaster recovery support

This pillar is where "managed" earns its name most visibly, because it is the one nobody notices until it is needed:

Backup strategy design aligned to your Recovery Point Objective (RPO)
Backup job monitoring and failure alerting (a backup job that silently fails for three weeks is a common, entirely preventable disaster)
Regular, scheduled restore testing — not just backup completion
Documented recovery procedures mapped to your Recovery Time Objective (RTO)
Disaster recovery architecture review (log shipping, Always On, geo-replication, or equivalent, depending on platform)

A backup you have never restored is a hope, not a plan. Ask any provider directly how often they test-restore your backups and what evidence they produce.

4. Patching and version management

Patching debt is a quiet risk that accumulates silently until it becomes a security or compatibility crisis:

Scheduled patching windows agreed with your business, not surprise Friday-night changes
Testing patches in non-production before production rollout where feasible
Version and support lifecycle tracking (so you are not still running an edition Microsoft stopped supporting eighteen months ago)
Cumulative update and security patch application on a defined cadence
Rollback plans for every patching window

5. Security hardening and access control

Increasingly inseparable from "administration" rather than a bolt-on:

Least-privilege access review for logins and roles
Surface area reduction (disabling unused features and protocols)
Encryption at rest and in transit configuration
Audit logging for privileged actions
Vulnerability assessment against current CIS or Microsoft baseline guidance
Coordinated response with your security team or provider when incidents occur

6. Capacity planning and scalability

The forward-looking pillar too many providers skip because it does not generate a support ticket:

Growth trend tracking for storage, compute, and connection counts
Proactive recommendations before a workload outgrows its tier or hardware
Right-sizing reviews (as relevant for cloud-hosted platforms, avoiding both under- and over-provisioning)
Scenario planning ahead of known events — new product launches, seasonal peaks, acquisitions

What sits at the edges (get this in writing)

Scope disputes usually happen at the boundary. Clarify these before signing:

Grey area

Common provider position

What to ask

Application-level query design

Often excluded — vendor/dev team owns it

Will you flag it even if you cannot fix it?

Third-party ISV database schemas

Sometimes limited support

What's the support ceiling?

Major version upgrades

Often a separate project, not included

Is upgrade planning advisory-only or hands-on?

Data migration into the platform

Usually a distinct engagement

Do you offer this, or refer out?

Multi-cloud or hybrid estates

Coverage varies widely by provider

Which platforms are explicitly in scope?

24/7 vs business-hours response

Often tiered by contract level

What is covered out of hours, and at what response time?

If a proposal does not answer these, assume the boundary will be argued about during an incident — the worst possible time to discover it.

Signs your current arrangement is incomplete

You may be paying for "managed database services" that is really reactive support wearing different branding if:

Nobody proactively flagged an issue before you noticed it yourself
You cannot recall the last time backups were test-restored
Patching happens only when you ask
Capacity conversations start after something has already slowed down
You have no regular reporting — you learn about problems from users, not from your provider

These are also common signs a business has outgrown ad-hoc, occasional database admin and needs a defined proactive service.

What good reporting looks like

A properly scoped service should give you visibility without you having to ask for it:

Monthly or quarterly health summary (performance trend, incidents, patching status)
Backup and restore-test evidence
Capacity trend charts against thresholds
Security posture summary and outstanding recommendations
A running log of changes made and why

If reporting is verbal, occasional, or only produced when you request it, the service is thinner than the name suggests.

How this differs from a one-off health check

A SQL Server health check is a point-in-time review — useful for a baseline, a pre-migration check, or diagnosing a specific problem. Managed database administration is the ongoing operating model that a health check might recommend you adopt. Many organisations start with a health check to understand their current state, then move to managed administration for continuous coverage.

How this fits Azure SQL vs SQL Server on VM

The six pillars apply on both platforms, but the balance shifts. Azure SQL platform-managed offerings absorb some patching and backup infrastructure automatically, shifting emphasis toward performance tuning, cost optimisation, and configuration. SQL Server on a VM puts the full weight of all six pillars on your provider, including OS-level patching and backup infrastructure design. Choosing between them is its own decision with cost and control trade-offs.

A simple test before you buy

Ask any prospective provider to answer, in writing, for each of the six pillars:

What specifically do you do proactively (not reactively) each month?
What are your response and resolution time commitments, by severity?
What evidence do you provide, and how often?
What is explicitly out of scope, and what does that cost extra?
Who is my named contact, and what is escalation beyond them?

If any answer is vague, the scope is vague — and vague scope is where reactive support hides behind a managed-services invoice.

Why this matters commercially

Database problems rarely announce themselves as database problems. They show up as slow reports, frustrated sales teams, failed month-end closes, or — worst case — an outage during a busy trading period. Better database performance improves reporting and the customer experience precisely because the database sits underneath almost everything else the business runs on.

Properly scoped managed administration is how mid-market companies get enterprise-grade database reliability without building an enterprise-sized internal team.

Definition, not decoration

Managed database administration is proactive monitoring, performance tuning, backup and disaster recovery assurance, patching, security hardening, and capacity planning — delivered continuously, with evidence, against agreed response times. Anything thinner than that is reactive support with a better name.

Before you renew or sign a new agreement, hold your provider (or your internal setup) against these six pillars. The gaps you find are usually exactly where the next incident will happen.

Next step: Book a SQL Server health check to baseline your current estate, or talk to us about what a fully managed service would cover for your specific SQL Server or Azure SQL environment.