The question this answers
Should this database run as a managed service, or on infrastructure we operate ourselves?
The system needs PostgreSQL with a specific extension the managed offering does not support. The team must decide whether that requirement is worth taking back patching, backups, replication and 03:00 failover.
A structured comparison across the four dimensions that actually decide it — expertise, customization, cost and operational risk — with the failure mode of each choice made explicit.
The same work, done by someone else or by you
Self-hosting does not remove the work in the managed column of Managed Databases. It transfers it. Backups still have to be taken, tested and retained. Minor versions still have to be patched. A standby still has to be kept in sync, and somebody still has to promote it — at whatever hour it fails. The question is never "do we need this work done"; it is "who does it, how well, and what does that cost in money and in attention".
That framing kills the two bad versions of this argument immediately. "Managed is easier" is not an argument, because the residual work — schema, queries, indexes, connections, access control — is where most incidents come from and it does not move. "Self-hosting is cheaper" is not an argument either, because the instance is only the visible part of the cost; the engineer-hours and the on-call rotation are the rest of it, and they are real even when nobody puts them on a spreadsheet.
What genuinely decides it is narrower and more honest: does the team have the expertise, does the workload need something managed offerings forbid, does the arithmetic actually favour self-hosting at your scale, and can the organization absorb the operational risk when it goes wrong at 03:00 on a Sunday.
| Dimension | Managed | Self-hosted |
|---|---|---|
| Expertise required | Application and schema expertise; no DBA needed to start | Real database operations experience, and more than one person with it |
| Customization | Restricted: approved extensions, restricted parameters, no superuser | Complete: any extension, any parameter, any version, any patch |
| Backups and PITR | Configured, executed, monitored by the provider | Yours to build, schedule, monitor and — the hard part — test |
| Failover | Automated promotion in tens of seconds | Whatever you built, exercised as often as you exercise it |
| Patching | Minor versions in a maintenance window | Your calendar, your risk, your rollback plan |
| Cost at small scale | A premium over raw compute for a real service | Cheaper on paper, before engineer-hours |
| Cost at large scale | The premium multiplies with fleet size | Can be substantially cheaper if you already have the expertise |
| Operational risk | Concentrated in the provider, with a documented recovery path | Concentrated in your team, and in whoever knows how it was set up |
| Lock-in | Migration path exists but costs a project | Portable, at the price of running it everywhere yourself |
What "we run it ourselves" actually contains
The gap between the two choices is easiest to see as a list of things that must exist. Managed gives you all of them on day one. Self-hosted gives you a running process and a to-do list, and the honest version of the decision compares that list against the size of the team.
The list below is not exotic. Every item is ordinary database operations, and every item is something a small team can build. The question is whether building nine of them is a better use of the next quarter than the customization that motivated the discussion — and whether they will still be maintained in two years, after the person who set them up has changed teams.
RUNNING postgres process, tuned, on a right-sized instance [both] BACKUP scheduled base backups + continuous WAL archiving [you] RESTORE a documented, rehearsed procedure with a known RTO [you] RESTORE-TEST automated, periodic, alerting when it fails [you] PATCHING minor version cadence, staging first, rollback plan [you] REPLICATION standby in a second zone, lag monitored [you] FAILOVER detection + promotion + endpoint repoint, tested [you] MONITORING connections, lag, bloat, checkpoints, IO, locks [you] ON-CALL somebody who can promote a replica at 03:00 on a Sunday [you] STORAGE volume growth before it fills, IOPS tier [you] SCHEMA tables, migrations, constraints [you, both cases] QUERIES + INDEXES the actual source of most incidents [you, both cases] ACCESS CONTROL roles, privileges, credential storage and rotation [you, both cases] CAPACITY + COST instance sizing and the bill [you, both cases]
When each one is the better answer
There is no universal winner here, and a lesson that declares one is lying to make itself easier to remember. There are, however, clear cases on both sides, and most teams are in one of them.
Managed wins when the team is small, when database operations is not a differentiator for the business, when the workload is ordinary enough that stock configuration is fine, and when the cost of an unplanned recovery — measured in customer trust, not just hours — exceeds the service premium. That describes the large majority of applications, which is why managed is the sensible default rather than a lazy one.
Self-hosting wins when a hard requirement forbids the managed path: an extension that is not on the approved list, a version the provider does not offer, a parameter you must control, a data-residency or regulatory constraint, or a scale at which the premium has become a line item somebody senior is asking about. It also wins when the organization genuinely has database operations expertise — a real platform team, not one enthusiastic engineer — because then the marginal cost is much lower than the spreadsheet suggests.
The middle path is frequently the right one and is usually forgotten: run the ordinary databases as managed services and self-host only the one instance with the unusual requirement. The cost of expertise is paid once, on one system, instead of across a fleet.
if (cheaper_per_month(self_hosted, managed)) {
choose(self_hosted) // engineer-hours not in the comparison
} // on-call not in the comparison
// restore testing not in the comparisonhard_requirement = extension_or_version_or_parameter_or_residency expertise = people_who_can_promote_a_replica_at_0300 >= 2 total_cost = infra + engineer_hours + on_call + incident_risk if (!hard_requirement) choose(managed) // the common case else if (expertise && total_cost_favours(self_hosted)) choose(self_hosted) else choose(managed_plus_workaround) // or: self-host ONLY this one instance
The left version compares the two visible numbers. The right version compares the two decisions — which is a question about the team as much as about the database.
Key points
- The work does not disappear; it is transferred. Backups, patching, replication and failover exist in both worlds — the question is who performs them.
- The residual half — schema, queries, indexes, access control, capacity, cost — is identical either way, and is where most incidents originate.
- Managed is the sensible default for most teams because database operations is rarely the differentiator, not because it is always superior.
- Self-hosting wins on a hard requirement — extension, version, parameter, residency, or scale-driven cost — combined with genuine in-house expertise.
- There is no universal winner, and the mixed answer (managed for the ordinary instances, self-hosted for the one unusual one) is often the best of the three.
The loop, answered
Every field is required, which is why no lesson here can recommend something without saying what it costs and what simpler thing to consider first.
- • Managed: the provider's control plane owns provisioning, patching, snapshots, WAL archiving, standby sync and promotion; you get an endpoint and a parameter group.
- • Self-hosted: you run the engine on a virtual machine or in a container, attach and size the block volume, and build every operational capability the control plane would have provided.
- • The application-facing contract is identical — a connection string, credentials and a network path — which is why migration between the two is possible and why it is still a project.
- • The cost difference is the service premium on one side against engineer-hours and on-call on the other, and only one of those appears on the invoice.
- • Managed: own the parameter group, the maintenance window, the retention policy, the restore test and the major-version upgrade project.
- • Self-hosted: own all of the above plus backup execution, WAL archiving, replication topology, failover automation and the runbook that makes it usable at 03:00.
- • Both: own schema, queries, indexes, connection pooling, database roles and credential rotation.
- • Both: own the decision review. A constraint that forced self-hosting three years ago may have been added to the managed offering since.
- • Self-hosted with backups that have never been restored — discovered on the day it matters, which is the worst possible day to discover it.
- • Self-hosted failover automation that has never been exercised, so its first real run is also its first test.
- • Self-hosted bus factor: one engineer configured everything, documented none of it, and has left.
- • Managed hitting a hard limit mid-project — an extension that cannot be installed, a parameter that cannot be changed — after the schema depends on it.
- • Managed treated as fully outsourced, so nobody watches connections, lag or free storage until an outage.
- • Either choice made on a spreadsheet that omitted engineer-hours, which is how a €400/month saving becomes a quarterly on-call cost.
- • At one or two databases, the managed premium is small in absolute terms and the operational saving is large.
- • At fifty databases the premium is a visible line item, and a platform team amortizes self-hosted expertise across all of them.
- • What runs out first when self-hosting is not compute — it is attention. Operational tasks scale with fleet size and the team usually does not.
- • Managed offerings scale vertically and to read replicas; beyond that, write scaling is a schema and application problem in both worlds.
- • Managed shifts patching of the engine to the provider, which closes a common and dangerous gap — an unpatched self-hosted database is a real, ordinary breach path.
- • Self-hosting gives full control of configuration, which is an advantage only if someone uses it: TLS enforcement, authentication method, audit logging and network policy all become yours.
- • Both require the same discipline above the engine: least-privilege database roles, credentials in a secret manager, no public exposure.
- • Managed offerings often integrate with provider identity, which can eliminate a static password entirely — a genuine security advantage that rarely appears in the comparison. See Roles vs Static Keys.
- • Self-hosted backups need their own access control and encryption; a snapshot on an unrestricted volume is a copy of production with no controls on it.
- • Managed: a service premium over compute plus storage, in exchange for a large amount of engineering time.
- • Self-hosted: lower infrastructure line, plus engineer-hours, on-call compensation and the expected cost of incidents that automation would have prevented.
- • The crossover moves with fleet size and with whether the expertise already exists — a platform team already paid for changes the arithmetic completely.
- • Both are dominated by instance sizing, which is a right-sizing problem independent of the choice. See Right-Sizing Without Causing an Outage.
- • The same signals either way: connections against the ceiling, replica lag, free storage, checkpoint and lock behaviour.
- • Self-hosted additionally: backup job success, WAL archiving lag, and the date of the last successful restore test.
- • Time spent on database operations per month, tracked honestly — it is the only number that settles the cost argument.
- • The signal that lies in both: a green process check.
postgresis running during connection exhaustion, storage-full and replication breakage alike.
- • Managed, always, until a hard requirement forces otherwise. For most teams this is the correct default and the discussion is short.
- • A serverless or auto-pausing database tier for spiky, low-volume workloads, which removes the fixed instance cost that motivates most self-hosting arithmetic.
- • Self-host only the one instance with the unusual requirement, and keep everything else managed — the mixed answer, and often the best one.
- • Question whether a separate database is needed at all: reusing the existing one avoids the choice entirely, at the cost of coupling.
- • A smaller managed instance with a connection pooler in front, when the pressure to self-host is really a cost pressure from over-provisioning.
- • Managed buys operational leverage; costs a premium, restricted configuration and a dependency on the provider's roadmap.
- • Self-hosting buys total control and portability; costs engineer-hours, on-call and the risk that recovery procedures exist only on paper.
- • Managed reduces the number of ways the platform can fail; it does not reduce the number of ways your schema and queries can.
- • Every hour spent building database operations is an hour not spent on the product — which is a legitimate trade in a database company and rarely one elsewhere.
What people believe, and what is true
Managed is always the right choice for a small team.
Almost always — but a hard requirement it cannot satisfy outranks team size, and pretending otherwise leads to a mid-project discovery.
Self-hosting is cheaper.
The infrastructure line is cheaper. Engineer-hours, on-call and the risk of an untested recovery are the rest of the cost, and they do not appear on the invoice.
Managed means we do not need database skills.
It means you do not need database *operations* skills. Schema design, query performance and index strategy are unchanged, and they cause most incidents.