Databases in the Cloud

Deliberately brief, by design: this chapter doesn't re-teach SQL or NoSQL query writing — this site's own mysql2/mysql3 and mongodb1/mongodb2 courses already cover that in real depth. This chapter is specifically about what changes when a database becomes a managed cloud service rather than something installed and operated by hand.

What "Managed" Actually Means for a Database

A managed database service sits at the PaaS layer of Chapter 1's IaaS/PaaS/SaaS spectrum, even when it's used alongside plain IaaS compute elsewhere in the same architecture. The provider handles patching, backup scheduling, replication setup, and failover — but per Chapter 1's shared responsibility model, schema design, query writing, and the data itself remain entirely the customer's responsibility.

Managed Relational Databases

RDS (AWS), Azure SQL Database, and Cloud SQL (GCP) run the exact same database engines already covered elsewhere on this site — MySQL, PostgreSQL, SQL Server — just operated by the provider. This has a genuinely direct practical consequence: every bit of mysql2/mysql3's SQL knowledge transfers completely unchanged. Only the operational layer changes — who handles backups, patching, and scaling — not the query language or schema design underneath.

Two genuinely useful managed features: automated backups with point-in-time recovery, and Multi-AZ/high-availability deployments — a standby replica maintained in a different availability zone (Chapter 5), with automatic failover if the primary instance fails.

Managed NoSQL Databases

DynamoDB (AWS), Cosmos DB (Azure), and Firestore (GCP) are not simply "MongoDB, but managed." DynamoDB and Cosmos DB are each proprietary services with their own distinct data models and APIs — though Cosmos DB does offer a genuine MongoDB-compatible API mode worth knowing about. Firestore is Google's own document-database service, conceptually close to mongodb1-1's document model (documents, collections, embedding vs. referencing) but not the same product or API as MongoDB itself.

The document-model concepts from mongodb1-1 — schema flexibility, embedding vs. referencing trade-offs — remain broadly useful thinking tools across all of these services, even though the specific query API differs from provider to provider.

Read Replicas & Scaling Reads

A read replica is a read-only copy of a database used to offload read traffic away from the primary instance handling writes — a scaling tool. This is genuinely easy to confuse with the Multi-AZ/HA standby replica described above, which exists specifically for failover, not scaling, even though the underlying replication mechanism is often similar. A standby typically isn't meant to serve regular application read traffic; a read replica typically isn't automatically promoted on primary failure the way an HA standby is. Some providers do offer configurations blending both roles — but the two purposes are distinct by default and worth keeping separate.

Connection Management — A Common Support Issue

"Connection refused" and "too many connections" are genuinely frequent real tickets, usually from one of two causes:

• Connection pool exhaustion — a managed database instance has a maximum connection limit based on its size. An application opening connections without properly pooling or closing them can exhaust that limit, causing failures for other legitimate connections too, not just its own.
• A blocking security group — directly echoing Chapter 5's networking chapter: a database sitting in a private subnet, unreachable from outside it, is very often working exactly as designed, not broken.

Choosing Managed vs. Self-Managed on a VM

Managed is the right default recommendation most of the time — less operational burden, at the cost of somewhat less control and sometimes fewer configuration options or supported engine versions. Self-managing a database on a plain VM (Chapter 3) makes sense specifically when a required configuration, extension, or engine version genuinely isn't supported by the managed offering — a real, occasionally legitimate reason, not simply a preference for more control.

Hands-On Exercises