The question this answers
When I use a managed database, which operational work has actually gone away — and which work is still mine?
The application needs a PostgreSQL instance that survives a host failure, has restorable backups, and receives security patches. The team is four engineers and none of them wants to be paged at 03:00 to promote a replica by hand.
A running database engine with provider-operated backups, minor-version patching, replication, automated failover and metrics — reachable at an endpoint whose address survives the instance behind it being replaced.
The boundary, stated explicitly
The single most expensive misunderstanding in this module is the belief that "managed" means "handled". It does not. It means a specific, enumerable list of tasks moved to the provider, and an equally specific list stayed with you. Teams get into trouble when nobody has read the second list out loud.
The provider's half is the undifferentiated machinery: provisioning the host, attaching and growing storage, taking backups on a schedule, applying minor engine patches in a maintenance window, keeping a standby in another zone in sync, and executing a failover when the primary stops responding. That is genuinely valuable work, it is work you would do badly at four engineers, and outsourcing it is usually correct.
Your half is everything that requires knowing what the data means. Schema design. Query shapes. Which indexes exist and which are dead weight. Connection limits and pooling. Who and what may connect, and with which privileges. Whether the instance class is right. What the backup retention should be, and whether anyone has ever restored one. And the bill, which nobody at the provider will tell you is too high.
A useful test: after an incident, ask which half it came from. Failover took 90 seconds — provider's half, and it worked. A missing index made the table scan and the CPU pinned at 100% — your half, and no managed service was ever going to catch it. Connections exhausted because a serverless function opened one per invocation — your half, and it is Serverless and Database Connections.
| Concern | Provider owns | You own |
|---|---|---|
| Host and hypervisor | Provisioning, replacement, hardware failure | Choosing the instance class — and paying for it |
| Storage | Durability, replication, online growth | Capacity ceiling, IOPS tier, and noticing when it fills |
| Engine patching | Minor versions in a maintenance window | Major version upgrades, and testing them against your queries |
| Backups | Scheduled snapshots and point-in-time recovery machinery | Retention policy, and having actually tested a restore — see Restore Testing |
| Replication | Keeping the standby in sync, promoting on failure | Understanding replica lag and whether your reads tolerate it |
| Failover | Detection and promotion | Client retry behaviour and connection re-establishment during those seconds |
| Schema | Nothing | Everything — tables, types, constraints, migrations |
| Queries and indexes | Nothing | Everything, including the missing index that causes your next outage |
| Access control | The network primitives and the IAM integration | Which roles exist, what they may read, and who holds the password |
| Cost | Metering | Every decision that moves the meter |
What the endpoint actually hides
Your application connects to a DNS name, not to a machine. Behind it sits a primary instance with an attached volume, a synchronous standby in a second availability zone, and a control plane watching both. When the primary fails, the control plane promotes the standby and repoints the endpoint. Your connection is severed and your client must reconnect — which is why "automated failover" still shows up in your error logs as a burst of connection failures lasting tens of seconds.
That is the part worth internalizing. Managed failover converts a multi-hour human recovery into a sub-minute automated one. It does not convert it into zero. Applications that do not retry, or that cache a resolved IP address past its TTL, turn a 40-second failover into a 20-minute outage entirely inside their own code.
Read replicas are the other thing the endpoint hides, and they hide it less well. A replica has its own endpoint, it is asynchronous, and its lag is a number your application must have an opinion about. Sending a read to a replica immediately after a write is the single most common source of "the user saved it and then it disappeared" — a Database Engineering topic (Replication and Read Scaling) that becomes an infrastructure decision the moment you provision the replica.
The bill has a shape, and it is mostly fixed
A managed database is the clearest example in the domain of a *fixed-shaped* cost. The instance bills by the hour whether it serves ten queries or ten million. Storage bills for what is provisioned. The standby in the second zone roughly doubles the instance line — which is the honest price of automated failover, and it should be presented that way rather than hidden inside a "high availability" checkbox.
Two line items surprise people. Backup storage beyond the included allowance grows with retention and with write churn, and a 35-day point-in-time window on a high-churn database can rival the primary storage cost. And cross-zone data transfer between the application and a database in another zone is metered on some providers, which quietly taxes an availability decision.
The structural consequence: a managed database is the workload that punishes over-provisioning hardest, because none of it scales down with traffic. It is also the workload where under-provisioning is most dangerous, because the failure mode is not slowness but connection exhaustion. That tension is the whole of Right-Sizing Without Causing an Outage.
Bars are relative weights, not currency. Real rates depend on provider, region, commitment and volume.
Key points
- Managed service does not mean zero operational responsibility. It relocates a specific list of tasks and leaves an equally specific list with you.
- Provider: host, storage durability, backups, minor patching, replication, failover. You: schema, queries, indexes, access control, capacity and cost.
- Automated failover is fast, not instant — your clients still see dropped connections and must reconnect and retry.
- A read replica is asynchronous. Its lag is an application correctness concern that provisioning it does not solve.
- The cost shape is almost entirely fixed, so it punishes over-provisioning and does not shrink when traffic does.
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.
- • The provider runs the engine on a host you never log into, with storage attached and replicated beneath it.
- • A control plane monitors health, takes scheduled snapshots, streams the write-ahead log for point-in-time recovery, and applies minor patches in your maintenance window.
- • A synchronous standby in a second availability zone receives writes; on primary failure the control plane promotes it and repoints the endpoint DNS name.
- • Read replicas receive changes asynchronously and expose their own endpoints, with lag as an observable metric.
- • You reach it through a private network path governed by a security group or firewall rule, authenticating with database credentials or a provider identity integration.
- • Own the schema, the migrations and their compatibility with a rolling deploy — see Rolling Deployment and the Compatibility It Demands.
- • Own query performance and indexes. No managed service will find the sequential scan that pins your CPU.
- • Own connection management: the instance class sets a connection ceiling, and a pooler is your responsibility, not the provider's.
- • Own access control: which database roles exist, what they may touch, and where the credential lives — see Secrets in Infrastructure.
- • Own restore testing. The provider guarantees the backup exists; only you can prove it restores into something the application accepts.
- • Own major version upgrades, which are your project, on your schedule, with your test suite.
- • Connection exhaustion: the instance class caps connections, a traffic spike or a connectionless-per-invocation runtime blows past it, and every new request fails while CPU sits at 20%.
- • Failover reconnect storms — the standby is promoted in under a minute and then every client reconnects at once, saturating the new primary.
- • Storage full on a database whose autogrowth was never enabled: writes stop, the instance stays "available", and the health check is happy.
- • Replica lag under write load, producing reads that do not contain the write the user just made.
- • A maintenance-window patch restarting the instance at a time nobody on the team had noticed was configured.
- • A restore that produces a database the application cannot use, because nobody ever tried it before the day it mattered.
- • Vertical first: a bigger instance class buys CPU, memory and a higher connection ceiling, and it is a restart.
- • Read scaling via replicas, bounded by your tolerance for lag and by the fact that writes still all go to one primary.
- • Write scaling is where managed stops helping — partitioning and sharding are application and schema decisions (Partitioning and Sharding), not a provider feature.
- • Connections usually run out before CPU does, which is why a pooler often buys more headroom than a bigger instance.
- • Storage grows online; it generally does not shrink, so growth is a one-way commitment.
- • Put it in a private subnet with no public address. A managed database reachable from the internet is the textbook finding — see Public Exposure, Read With Context.
- • A private subnet is not authentication. Restrict ingress to the application security group, and still use strong credentials and least-privilege database roles.
- • Prefer provider identity integration over a static password where it exists; it turns a long-lived secret into a short-lived token — see Roles vs Static Keys.
- • Encryption at rest and in transit are near-free and should both be on; the question worth asking is who can decrypt a snapshot.
- • Snapshots are full copies of production data with their own sharing settings. A publicly-shared snapshot is a breach with no server involved.
- • Audit who can perform control-plane actions: whoever can delete the instance can end the company, and that is a different permission from
SELECT.
- • Instance-hours dominate and are fixed: a database at 4% utilization costs the same as one at 80%.
- • The multi-zone standby roughly doubles the instance line and is the real price of automated failover.
- • Backup storage grows with retention window and write churn, and is the most commonly underestimated item.
- • Cross-zone transfer between application and database is metered on some providers — a hidden tax on a reliability decision.
- • Reserved or committed-use pricing meaningfully changes the total for a workload that is genuinely permanent, at the cost of flexibility.
- • Connection count against the instance limit — the number that predicts the outage nobody sees coming.
- • Replica lag, in seconds and in bytes, alerted rather than dashboarded.
- • Free storage and its growth rate; the derivative gives you days of warning that the absolute number does not.
- • Failover events and their duration, plus client-side reconnect errors around them.
- • Backup success and, separately, the date of the last successful *restore test*.
- • The signal that lies: instance CPU. It looks fine during connection exhaustion, storage-full and lock contention alike.
- • Self-host the engine on a virtual machine, when you need an extension, a version or a configuration the managed offering refuses — and you have the expertise to run it. See Managed vs Self-Hosted.
- • A smaller managed offering or a serverless database tier for low, spiky traffic, where a permanently-sized instance is mostly idle.
- • SQLite or an embedded store for a single-instance application with modest data. It is a real answer, it has no network, no credential and no bill, and it is correct more often than infrastructure culture admits.
- • No second database at all: use the one you already run. A new managed instance per service is a real cost in money, credentials and operational surface — see Cost per Service and the Attribution Problem.
- • Buys back most operational toil — patching, backups, failover — and costs a premium over raw compute plus storage for the same hardware.
- • Buys automated recovery; costs configuration flexibility, since extensions, parameters and superuser access are restricted.
- • Buys a fast, tested failover path; costs a doubled instance line and clients that must handle reconnection correctly.
- • Buys provider expertise for the layers below the schema; costs nothing at all for the layers above it, which is where most incidents actually originate.
What people believe, and what is true
It is managed, so backups are handled.
Backups are taken. Retention is your policy, and a backup you have never restored is not proven recovery — see Restore Testing.
Multi-zone means no downtime.
It means a promotion measured in tens of seconds instead of an hour of human work. Your clients still see dropped connections and must reconnect.
A read replica solves our scaling problem.
It solves read scaling and introduces asynchronous lag. Every read routed to it must tolerate seeing slightly stale data.
The provider will tell us if something is wrong.
The provider watches its half. A missing index, a lock storm and a connection leak all live entirely in yours.