Managed Service
A capability the provider operates — provisioning, patching, backup, scaling and failover — leaving you the configuration and the data.
The right way to evaluate one is by which operational responsibilities actually transfer, since that varies far more than the marketing suggests. Ask specifically: who patches, who takes and verifies backups, who handles failover, who is paged at 3 AM, and what the provider's own SLA is — because your service's availability is now bounded by theirs.
The reason to default to managed is that the transferred work is real, continuous, unglamorous and easy to underestimate. The reason not to is narrow: an unsupported configuration, a regulatory constraint, a scale where the price premium exceeds a team's cost, or a capability so core that operating it is itself the differentiation.
The recurring surprise is that managed does not mean unmanaged. You still own capacity planning, cost, schema and query performance, connection limits, version upgrades (which are scheduled, not optional), and the design that determines whether any of it works.