A team is deciding whether to run a database, broker or search engine itself or to use a managed service. What actually drives the decision, and which arguments are usually wrong?

What actually drives it

• Team capacity and expertise, honestly assessed. Running a distributed datastore well requires genuine specialist knowledge, on-call coverage and continuous attention. The question is not whether the team could learn it but whether that is the best use of their time, and for most product teams it is not.
• The fully-loaded cost comparison. Managed services look expensive per unit and the comparison must include engineer time for operations, upgrades, capacity planning, incident response, and the on-call burden — which frequently exceeds the price difference at small and medium scale and is reliably omitted.
• The crossover point. At sufficient scale the managed premium becomes very large and self-managing becomes economical — and the crossover is far higher than most teams estimate, often not reached at all.
• Genuine requirements the managed service cannot meet: a specific version, a plugin, a configuration, a residency constraint, a network topology. These must be verified against the actual service rather than assumed, since managed offerings have expanded considerably.
• Compliance and data location, where the answer may be decided externally.

The arguments usually made badly

For self-managing:

• "We need full control." Usually meaning a handful of configuration options, which should be enumerated and checked against the managed offering — the list is typically shorter than expected and frequently supported.
• "It's cheaper." True only at scale and only if engineer time is excluded, which it should not be.
• "We avoid lock-in." Partly true, and the real lock-in is usually the data and the operational knowledge, not the API. Running it yourself creates its own lock-in: the bespoke configuration, the internal tooling, and the two people who understand it.

For managed:

• "It's fully managed so we don't need expertise." Firmly wrong and expensively so. You still need to understand the data model, query performance, capacity, failure modes and cost drivers. What is removed is the operational toil, not the understanding — and a team that skips the understanding will misuse the service and blame it.
• "It's more reliable." Usually true, and it is not automatic — a badly-configured managed service is not reliable, and provider outages are correlated across your estate.
• "It's simpler." Simpler to operate, and it introduces vendor limits, quota behaviour, and a support relationship that becomes the critical path during an incident.

The consideration most often missed

During an incident with a managed service, your remediation options are constrained to what the provider exposes, and the escalation path is a support ticket. For a component whose failure is existential, that dependency should be a conscious choice with a support agreement to match — and for most components it is entirely acceptable, which is the point of making the distinction explicitly rather than uniformly.

The reasonable default

Managed by default; self-manage where there is a specific, articulable requirement or a demonstrated cost crossover. The scarce resource in almost every organisation is engineering attention, and operating infrastructure is rarely where a product team creates differentiated value.