Managed Databases vs Running Your Own

You can run a database on the same server as your application for no
additional cost, or pay for a managed instance. The price difference is clear
and the value difference is not, because what you are buying is the absence of
work that may or may not otherwise get done.

What managed actually covers

• Automated backups on a schedule, with retention, and
  usually point-in-time recovery.
• Patching of the database engine and the operating system
  beneath it.
• High availability, where chosen, with automatic failover to
  a standby.
• Replication for read replicas, configured through an
  interface rather than by hand.
• Monitoring of database-specific metrics.
• Sensible defaults, which matters more than it sounds:
  default configurations ship conservatively and tuning them is specialist
  work.

What self-hosting requires

All of the above, done by you. Specifically:

• A backup job, scheduled, writing somewhere off the server.
• Monitoring that the backup job succeeded, because silent failure is the
  normal failure mode.
• A restore test, performed periodically.
• Patching, including the planning for restarts.
• Monitoring of connections, slow queries, replication lag and disk space.
• Configuration tuning for the available memory.
• A documented recovery procedure that more than one person understands.

None of this is difficult in isolation. The question is whether it will
actually happen, every month, including the months when something else is
urgent.

The cost comparison, honestly

A managed database is meaningfully more expensive than the marginal cost of
running one on a server you already have, and high availability roughly doubles
it again because you are running two instances. The managed floor is also
higher, since the smallest managed plan is usually sized for production rather
than for a side project. This is covered more generally in
the hidden cost of managed
services.

Against that, weigh the hours. At any commercial rate, a few hours a month of
someone’s attention exceeds the price difference quickly. The comparison is only
favourable to self-hosting if those hours genuinely would not have been spent,
which for a hobby project is true and for a business usually is not.

The question that decides it

Can you name the person who will notice that last night’s backup failed?

If you can, and that person has the time, self-hosting is a reasonable
engineering choice that saves real money. If you cannot, buy the managed
service, because the alternative is not cheaper self-hosting; it is an untested
backup and a bad week at some point in the future.

When self-hosting is clearly right

• Development and staging environments, which can be rebuilt from production
  data and do not need availability guarantees.
• Small projects where an hour of downtime and a restore from yesterday is
  genuinely acceptable.
• Workloads needing extensions or configuration the managed offering does not
  support, which is a real constraint on some platforms.
• Flat-rate providers where the entire point is a predictable bill and the
  team has the skills, as in
  the developer VPS
  comparison.

When managed is clearly right

• Any system where losing customer data would be a commercial
  catastrophe.
• Teams with no database experience, where the defaults alone are worth the
  price.
• Anything needing automatic failover, which is substantial engineering to
  build correctly.
• Regulated environments where you must evidence patching and backup
  practice.

A middle path

Self-host in development and staging, use managed in production. You get the
cost saving where reliability does not matter and the reliability where it does,
and the configuration difference between environments is small if you keep to
standard features.

Whichever you choose, use a standard engine rather than a proprietary one.
Staying on ordinary PostgreSQL or MySQL keeps the decision reversible, which
matters more than the decision itself.