The Hidden Cost of Managed Services

A managed service is someone else running the boring, difficult parts of a
component for you: patching, failover, backups, replication. That is genuinely
valuable, and for most teams the right answer most of the time. But the sticker
price is rarely the whole price, and the gap is predictable enough to plan for.

You pay for availability, not activity

A managed database bills for the instance existing. An idle database costs
what a busy one of the same size costs. This is the same rule that governs
virtual machines, but it surprises people more here, because a database feels
like a service rather than a server.

The practical consequence is that non-production environments are expensive
if you treat them like production. A staging database running a managed instance
around the clock, used four hours a week, is paying for roughly forty times the
availability it needs.

The control plane fee

Managed Kubernetes is the clearest example. Many providers charge a flat
hourly fee for the control plane itself, entirely separate from the worker nodes
that run your containers. You pay it whether the cluster is running one pod or
four hundred.

For a large deployment that fee disappears into the noise. For a small one it
can be a meaningful fraction of the total, which is why running a single
application on managed Kubernetes is often more expensive than running it on two
virtual machines, before you have deployed anything at all.

Minimum viable size is higher than you think

Self-hosting a database means you can put it on the same small server as your
application. A managed database starts at whatever the provider’s smallest plan
is, and that smallest plan is usually sized for production rather than for a
side project. High availability, where offered, typically means running at least
two instances, so choosing it roughly doubles the line.

None of that is unreasonable. It just means the floor is higher, and the
comparison against self-hosting is not close at small scale even though it
becomes compelling at larger scale.

Storage and backups are often separate meters

The instance price frequently covers compute and a base allocation of
storage. Storage beyond that, automated backup retention, and point-in-time
recovery windows may each carry their own charge. A long retention policy set
once and forgotten is a cost that grows every month while nothing else about the
service changes.

The cost of leaving

This one is not on any pricing page. A managed service shapes your
application around its interface and its operational model. Moving away later
means not only migrating data, which is the obvious part, but also replacing the
operational work the provider was doing for you. If you have never run your own
replication and failover, choosing to start is a project, not a configuration
change.

The honest version of this trade is not “managed services lock you in”. It is
that you are buying out of an operational burden, and buying back in later costs
roughly what you avoided, plus the migration. That can still be an excellent
deal. It is just worth knowing you are making it.

When managed is clearly worth it

• When the component is one whose failure would be serious and your team has
  no one who has operated it before.
• When you need high availability and automated failover, which is a lot of
  engineering to build correctly and very easy to build incorrectly.
• When the alternative is that backups never get tested, which is the usual
  real-world outcome of self-hosting a database without a dedicated owner.
• When the engineering time saved is worth more than the difference, which at
  any commercial rate it very often is.

When self-hosting is the better call

• Development and staging environments, which can run on the same server as
  the application and be destroyed overnight.
• Small, low-traffic production workloads where an hour of downtime is
  survivable and a restore from backup is an acceptable recovery path.
• Workloads on flat-rate providers where the whole point of the platform is a
  predictable monthly bill, covered in the
  developer VPS
  comparison.

How to price it honestly

Before you commit, add up the instance, the storage, the backup retention,
any control plane fee, and a second instance if you want high availability. Then
compare that against the cost of the server you would otherwise run plus an
honest estimate of the hours someone will spend operating it. If you cannot name
the person who would do that operating, the managed option is almost certainly
correct regardless of the arithmetic.