25 questions to ask before signing a managed database contract

TL;DR: the five areas are reliability practices, incentives and pricing, people and coverage, compliance and security, and the exit. The most-dodged questions are #3 (show me a real RCA), #8 (what happens to your revenue when my usage grows), and #23 (walk me through leaving you).
A managed database contract is easy to sign and expensive to be wrong about. The provider knows this conversation better than you do; they have it weekly, you have it once every few years.
These 25 questions level the field. They are grouped into five areas, and for each we note what a good answer sounds like and which questions providers most often dodge.
Reliability practices (questions 1-6)
1. Show me the root cause analysis from your last three incidents with any client (anonymized).
Good answer: real documents, with cause categories and follow-up actions. Bad answer: incident reports showing response times but no causes. No RCAs means the provider closes tickets rather than removing failure modes.
2. How do you handle an incident that has occurred twice?
Good answer: a repeat incident triggers an engineering review, not another ticket. Listen for "error budget", "postmortem", "problem management".
3. What was your last restore test for a client? (commonly dodged)
Backups without tested restores are hypotheses. Good answer: scheduled restore tests with timed results shared with the client.
4. What is the committed response time for a P1 database incident, and what are the consequences of missing it?
Good answer: minutes, in the contract, with financial consequences. "Best effort" is not a commitment.
5. What proactive work is included: tuning, capacity planning, upgrade management?
Good answer: a named cadence (monthly reviews, quarterly capacity plans) included in the fee, not billed as change requests.
6. How will I see the health of my own databases?
Good answer: monitoring and dashboards you can access directly, ideally in your own accounts. If visibility lives only on their side, silence and health look identical.
Engine-specific version: make them prove depth on your actual engine, not databases in general.
For PostgreSQL/MySQL, ask how they handle autovacuum/bloat, replication lag, and major-version upgrades.
For Apache Cassandra, ask who owns repair scheduling (Cassandra ships without it), compaction strategy, and tombstone management, because those are exactly where under-staffed Cassandra estates silently degrade. A provider who runs Cassandra well answers these fluently; one who bolted it onto a generalist queue will get vague.
Incentives and pricing (questions 7-11)
7. What exactly is in the fixed fee, and what triggers additional charges?
Ask what the invoices for a comparable client look like. The pattern matters more than the list price.
8. What happens to your revenue when my data volume doubles? (commonly dodged)
The most clarifying question in the set. Usage-scaled pricing means your growth raises their revenue with no extra work. Fixed operational pricing means their margin depends on efficiency. Neither answer is wrong, but you should know which relationship you are entering.
9. Which cost line items do your other clients most often not anticipate?
An honest provider names egress, backup storage, cross-region replication, or support-tier changes without flinching.
10. If you recommend an infrastructure change that cuts my costs, how does that affect your fees?
Good answer: it doesn't, or fees go down. If their fee is a percentage of managed spend, cost optimization works against them.
11. What does the price look like in year three?
Ask for the renewal history of existing clients. Lowball-then-escalate is a known pattern in outsourcing.
People and coverage (questions 12-16)
12. Who exactly is awake at 3 a.m. my time, and what are they allowed to decide alone?
Good answer: named shift structure (follow-the-sun or staffed shifts), with engineers empowered to act on runbooks without a bridge call.
13. Will I have named engineers, or a queue?
Neither is automatically wrong, but a queue plus no RCAs plus per-ticket pricing is the full ticket-mill pattern.
14. What is your team's tenure and turnover?
Database context takes months to build. High turnover means you are perpetually training your provider.
15. How many clients does the team serving me support at once?
You want the model explained without embarrassment. Shared teams are normal; opaque ratios are not.
16. Who is my single point of contact, and what is their authority?
An account manager who cannot get an engineer moving is a mailbox.
Compliance and security (questions 17-21)
17. Give me the responsibility split for [SOC 2 / HIPAA / GDPR / PCI, as applicable]: who patches, who encrypts, who documents, who answers the auditor?
Good answer: a written RACI they have used before.
18. Where does my data physically live, and who can access it?
In-your-account deployments make this answer short. Platform deployments make it long; make them give it anyway.
19. How do you handle access management for your own engineers?
Listen for: least privilege, audited access, no shared credentials, client-side approval for elevated access.
20. What happens when there is a security incident on your side?
Good answer: notification commitments in hours, defined in the contract, with a named process.
21. Which certifications do you hold vs align to?
The wording difference is legal, not cosmetic. Make them state it precisely, and match it to your audit requirements.
The exit (questions 22-25)
22. What proprietary tooling, if any, will my environment depend on?
Every proprietary dependency is a switching cost you are pre-paying. Open-source stacks in your accounts keep dependencies portable.
23. Walk me through what leaving you looks like. (commonly dodged)
Good answer: a documented offboarding process, knowledge transfer commitments, data handover formats, and a straight face. A provider confident in its service has no reason to hide the exit.
24. What do you charge for offboarding support?
Get it in the contract now. Exit pricing negotiated during an exit is not a negotiation.
25. Can I speak to a client who left you?
The strongest question in the set. A mature provider has departed clients who left on good terms (acquisitions, insourcing) and will connect you. Panic here tells you how relationships end.
How to use this list
Do not read all 25 in one meeting. Pick three (#3, #8, #23) for the first call and watch how the conversation handles them; the manner of answering is the data. Take the full list into the reference-check phase and run it against your current provider too: their answers are your baseline.
FAQ
What is the most important question to ask a managed database provider?
"What happens to your revenue when my usage doubles?" It exposes the incentive structure behind every other answer: pricing, proactive work, and optimization behavior all follow from it.
What should be in a managed database SLA?
Committed response and restore times per severity level with consequences for missing them, uptime commitment with clear measurement and exclusion definitions, restore test cadence with shared evidence, and offboarding terms agreed upfront.
How do I evaluate a database MSP's reliability claims?
Ask for artifacts, not assurances: real (anonymized) root cause analyses, restore test results with timestamps, and a reference call with a long-tenured client plus one who left.




