Managed vs self-hosted databases: what you're actually buying

TL;DR

• Verdict: default to managed (RDS, Aurora, Cloud SQL, Atlas) unless you have a dedicated person who genuinely knows database operations, a workload with unusual requirements, or a scale where the managed premium is material.
• Managed removes infrastructure work: hardware, OS patching, backup plumbing, failover mechanics, minor version upgrades.
• Managed does not remove workload work: slow queries, connection exhaustion, replication lag, bloat, failed migrations, or cost surprises. Most production database incidents live here.
• Self-hosting is cheaper on paper and more flexible, but the price is that every 3 a.m. problem is fully yours, including the ones managed providers have automated away.

What “managed” actually means

RDS, Aurora, Cloud SQL, and MongoDB Atlas all sell the same core promise: you get an endpoint, they run the machinery. Concretely, they take over:

• Hardware and provisioning. No procurement, no failed disks, resize with an API call.
• OS and minor-version patching. Applied in maintenance windows you configure.
• Backup plumbing. Automated snapshots, point-in-time recovery, retention policies that exist by default rather than by discipline.
• Failover mechanics. Multi-AZ standby, automatic promotion, DNS repointing.
• Baseline monitoring. CPU, storage, connection metrics, out of the box.

This is real work, and it is precisely the work that small teams do worst, because it is invisible until the day it isn’t. The single most common self-hosted disaster pattern we see is not exotic: it is the backup script that stopped working eight months ago and nobody noticed until restore day.

What managed does not remove

Here is the part the pricing page skips. The majority of production database incidents are workload problems, and they follow you onto managed infrastructure unchanged:

• Bad queries. A missing index or an N+1 pattern saturates an Aurora instance exactly the way it saturates your own box. Managed gives you better graphs to watch it happen.
• Connection exhaustion. Managed engines still have connection limits, and serverless application tiers hit them faster. You still need pooling (PgBouncer, RDS Proxy), and you still need to configure it.
• Replication lag. Read replicas lag under write pressure on every platform. Stale reads and lag-driven failover pain are workload properties.
• Bloat and vacuum problems. PostgreSQL table bloat, autovacuum tuning, and transaction ID wraparound risk are identical on RDS. Nobody at AWS is watching your dead tuple ratio.
• Failed and locking migrations. An ALTER TABLE that takes an exclusive lock on a hot table blocks production regardless of who owns the hardware.
• Cost surprises. Managed replaces capacity planning with a bill. Aurora I/O charges, storage autoscaling, cross-AZ traffic, and snapshot retention can produce invoices 2 to 3x what the calculator suggested, and there is no server to point at.

Side by side

Dimension	Managed (RDS, Aurora, Cloud SQL, Atlas)	Self-hosted
Hardware, OS, patching	Provider’s problem	Yours, forever
Backups and PITR	Default, verified restore still on you	Yours to build, test, and monitor
Failover	Automated, minutes	Yours to design and rehearse
Query performance	Still yours	Still yours
Connection limits, pooling	Still yours (proxy helps)	Yours, more knobs available
Replication lag, bloat, migrations	Still yours	Still yours
Superuser and OS access	Restricted	Full
Extensions and versions	Provider’s allowlist and timeline	Anything, anytime
Raw infrastructure cost	Premium, often 1.5 to 3x compute cost	Cheaper compute, expensive attention
Cost predictability	Variable line items, surprise-prone	Predictable, capacity planning required
Skill required to run safely	Moderate	Genuinely senior

The trade-offs, honestly

The managed premium is an insurance product. You pay a markup so that hardware failure, missed patches, and backup plumbing cannot be the cause of your worst day. For most teams that insurance is underpriced relative to the alternative, which is learning failover under fire.

Self-hosting buys control, and control is sometimes necessary. Specific extensions the provider doesn’t allow, superuser access for deep debugging, exotic replication topologies, data residency in places the big clouds don’t serve, or a cost profile where a 2x compute markup is real money. These are legitimate reasons, held by a minority of teams.

Neither option changes your incident profile much. If your incidents are slow queries, lock pileups, lag, and migration failures (and statistically they are), the hosting decision is close to neutral. The skills that prevent those incidents are schema design, query discipline, and migration hygiene, and they are portable.

Choose managed when

• You do not have a person who has run production databases before, or that person’s time is worth more elsewhere.
• Your team is under roughly ten engineers and the database is not your product.
• You want failover, backups, and patching to be provably boring.
• Your workload is a standard OLTP application on PostgreSQL, MySQL, or MongoDB.

Self-host when

• You have genuine database operations skill in-house and the willingness to keep it on call.
• You need extensions, versions, or superuser access the managed tier refuses.
• Your scale makes the managed markup a meaningful line item and you have measured that the operational cost doesn’t eat the savings.
• You have hard residency or compliance constraints managed offerings can’t meet.

A common mature pattern: managed for the primary transactional store, self-hosted for the specialized pieces (search, analytics, a queue) where control matters and the blast radius is smaller.

When the database is on fire anyway

Managed or self-hosted, the incidents that actually page you tend to be the same ones: a query that fell off a cliff, a migration stuck holding a lock, replication lagging into uselessness, a disk or an I/O bill growing without explanation. Erzon handles exactly these, on RDS and Aurora as often as on bare metal. If you’re mid-incident or staring at a database problem you can’t diagnose, we triage for free and respond within one business hour, with a flat quote before any work starts.