A multi-product SaaS company runs its own database clusters on cloud instances and is considering moving to the provider's managed database service. What evidence should decide it?

What managed actually buys

Not "we no longer think about the database" — that expectation is the source of most disappointment. What it buys is specific:

• Automated failover, backups and patching, tested by the provider at a scale no single company can match.
• Point-in-time recovery that works, which is a genuinely hard thing to build and operate correctly.
• Elimination of a class of 3 a.m. work — replication rebuilds, version upgrades, storage expansion.
• Engineers redeployed from keeping the database alive to work that differentiates the product.

What it costs

• A price premium, often significant, over raw instances.
• Loss of control at the margins. Extensions, configuration parameters, kernel tuning, filesystem choices and specific versions may be unavailable. For most workloads this is irrelevant; for a few it is decisive.
• Provider-defined maintenance windows, which means an involuntary failover at a time you did not choose.
• A ceiling. Managed services have limits — connection counts, storage size, IOPS, replica counts — and hitting one is a migration, not a configuration change.
• Lock-in, proportional to how many provider-specific features get adopted.

The evidence that should decide

1. What does self-managing actually cost today? Count it honestly: engineer time on upgrades, backups, failover testing, incident response, and the on-call burden. Most teams have never measured this, and it is usually larger than expected — and the largest component is often the opportunity cost of the most experienced engineers.

2. How good is the current operation? If failover is untested, backups are unverified and upgrades are deferred because they are frightening, managed is almost certainly better and safer. If the team runs a genuinely excellent database operation with tested recovery, the calculus changes considerably.

3. Does the workload need anything the managed service does not offer? A specific extension, a version, a configuration. This is a hard blocker rather than a trade-off, and it must be checked first.

4. Is the workload near a managed-service limit? Adopting a service you will outgrow in a year means paying migration costs twice.

5. What is the failure mode you most fear? If it is data loss, managed services with point-in-time recovery are a strong answer. If it is a provider-wide incident affecting the managed service globally, self-managed across providers is a different bet — but be honest about whether that scenario is real or theoretical for your business.

The judgement being tested

Whether you can resist both reflexes. "Always managed" ignores real constraints and real costs. "We can run it better ourselves" is usually true only for teams who have measured what running it costs them, and is usually asserted by teams who have not.

The most valuable question is often the simplest: what would we do with the engineering time this frees up, and is that worth more than the premium? If the answer is "nothing specific", the premium is harder to justify.