Managed Postgres (primary + optional replica)
Plenty of customers want a fast, reliable database and absolutely none of the work of running one. With managed database you run the box -- patches, backups, the lot -- and the customer just gets a connection string that always works. They never think about the server; that's the whole product.
Every managed database takes automatic backups, so a bad deploy or a fat-fingered DELETE isn't the end of the world. Customers who can't afford downtime pay extra for a hot replica: a second copy that's kept in sync and ready to take over the instant the main one dies. That handover is failover -- a few minutes of bumpy service instead of a dead database.
Databases live and die on disk speed (IOPS). Pack a hungry tenant onto the same server and the database's queries crawl while it fights for the disk -- and a slow database is a customer halfway out the door. Give your database tenants room to breathe.
Detailed explanation
A managed DB is a primary VM (e.g. 4-8 vCPU / 16-32 GB) with a block volume sized for the dataset at a target IOPS (5k-8k typical). with_replica=true provisions a second replica VM on a different host. Automatic backups run at the configured DurabilityTier; High/Mission backups raise the replication factor of the snapshot store.
On primary-host failure with a replica present: a 5-minute failover window with ~50% request failure (DB_FAILOVER_FAIL_RATIO) before the replica promotes. No replica = full unavailability until host recovery. The dominant quality risk in steady state is noisy-neighbor IOPS contention on the shared SSD -- a host whose IOPS draw exceeds ~85% of capacity penalises every VM on it, and a database is the tenant that screams first.