Cloud Databases

Definition

Three tiers, increasingly abstracted:

• Managed instances of a familiar engine. You get the engine you know, with backups, patching, replication and failover automated.
• Cloud-native distributed databases with a different architecture — separated storage and compute, automatic sharding, multi-region replication.
• Serverless databases that scale to zero and bill per request or per capacity unit.

What the managed tier genuinely buys

Backups that exist and can be restored. Patching that happens. Failover that has been tested by somebody other than you. Replicas created with a click. For most organisations this is a substantial and honest saving, and self-managing a database to save the premium is a decision that should require evidence rather than instinct — the premium is usually less than one engineer's time.

Where the abstraction leaks

• You lose superuser. Extensions, kernel parameters and some replication topologies become unavailable, and this is discovered mid-project.
• Maintenance windows are the provider's. A forced minor-version upgrade with a brief failover happens on their schedule, so the application must tolerate a connection reset at an arbitrary moment. Applications that assume a stable connection break here.
• Performance debugging is harder, because you cannot see the host and some diagnostics are withheld.
• Failover is not instant. Typically tens of seconds, during which writes fail. That must be an accepted number in the design, not a surprise.
• Cost scales in unfamiliar units. Serverless database billing per request or per I/O operation can make an inefficient query pattern startlingly expensive in a way that instance pricing never would.

Industry example

Fast-growing marketplaces typically pass through a recognisable sequence: one managed relational instance, then read replicas as reads dominate, then functional separation of the heaviest domain onto its own instance, then sharding or a specialised store only for the specific workload that demands it — search being the usual first departure, because relevance ranking over a large inventory is not a relational workload.

The lesson from that trajectory is that each step was forced by a measured constraint rather than anticipated. Teams that jump to the end state early carry the cost of distribution for years before the benefit arrives, and usually shard on the wrong key because they did not yet understand the access patterns.

Failure scenarios

• Connection limits exhausted, because serverless functions or many container replicas each hold a pool. A connection pooler is mandatory, not optional, in that topology.
• Cross-AZ or cross-region data transfer charges from a chatty application placed badly.
• Backups never restore-tested, so the recovery time is unknown until it matters.
• Autoscaling storage that cannot shrink, so a one-off bulk load raises the floor permanently.

Trade-offs

Managed services buy operational capacity — the scarcest resource in most teams — and sell control, some performance ceiling, and portability. The right default is managed, with self-managed reserved for a specific, articulated requirement.

Interview question

"Your managed database fails over for a routine patch and the application returns errors for 40 seconds. Whose problem is that, and what would you change?"