Learn Cloud Computing - Relational Managed Databases (RDBMS)

#Introduction

In episode 6 you learned to run and pay for VMs, in episode 7 to store data, and in episode 8 to make applications always available and scalable. But all of it comes down to the most sensitive component: the database. An application can crash and be restarted, but losing data is a disaster that can't be undone.

Episode 9 covers relational managed databases: why choose managed over self-managed, how multi-AZ high availability works (synchronous replication and automatic failover), what cloud-native distributed SQL is, and a comparison map of the services on AWS, GCP, and Azure.

#Managed vs Self-Managed Databases

There are two ways to run a relational database in the cloud. The first: install PostgreSQL or MySQL yourself on a VM (self-managed). The second: use a managed service like RDS or Cloud SQL (managed).

Aspect	Self-managed	Managed database
Patching and updates	Manual, must be scheduled	Automatic by the provider
Backup and restore	Manual setup and testing	Automatic, supports point-in-time recovery
High availability	Manual setup (mirror, replication)	Built-in, just one setting (e.g. Multi-AZ)
Cost	Cheap upfront, expensive in operational cost	There's a premium, but it saves time and risk

Tip

It's like buying a car versus taking a taxi. Buying a car (self-managed) gives full control, but you're the one handling maintenance, taxes, and repairs. Taking a taxi (managed) means you focus on the journey — in this context, on the application. For production, start with a managed database; self-managed is only for learning, labs, or genuinely extreme customization needs.

What people often forget when comparing costs is the operational cost of self-managed: time for patching, being on-call when the database goes down at midnight, and the risk of losing backups. A managed database adds a small price premium but removes almost all those hidden costs.

#Multi-AZ High Availability: Synchronous Replication and Automatic Failover

The main advantage of a managed database is high availability that you "just turn on". The concept: one primary database in one AZ, one standby replica in another AZ, connected with synchronous replication.

plaintext

            Client application
                 |  (connected to a single endpoint)
                 v
         [ Endpoint / DNS ]
                 |
    +------------+------------+
    |                         |
    v                         v
PRIMARY (AZ-a)             STANDBY (AZ-b)
PostgreSQL                 PostgreSQL
    +------ synchronous replication ------+

Synchronous replication means every transaction must be written to the primary and the standby before it's considered successful. If the primary fails — a crash, or the entire AZ-a goes down — the same endpoint is automatically redirected to the standby within minutes. The application doesn't need to know a switch happened; it just needs to reconnect to the same endpoint.

Important

Note one detail that's often misunderstood: in RDS Multi-AZ, the standby is not a "read replica". All read traffic is still served by the primary; the standby only stores a copy for failover. If you want to spread read load, create a separate read replica — that's a different purpose, enabled with a different setting.

This is why managed databases can achieve high uptime: automatic failover, automatic backups, and automatic replica repair are provided by the provider, so you no longer wake up at midnight to promote a replica manually.

#Cloud-Native Distributed SQL

Beyond classic relational databases, a new class has emerged: cloud-native distributed SQL, designed from the start for cloud scale. Its representatives are Amazon Aurora (MySQL and PostgreSQL compatible), Google Cloud Spanner (global SQL with strong consistency), and Azure SQL Database (including the Hyperscale tier).

Its characteristics:

Storage is automatically split across many nodes, while applications still interact through standard SQL and get ACID guarantees.
Capacity grows without downtime and without swapping to a bigger instance.
Cross-region replication can be done with guaranteed consistency — Spanner can even span multiple continents at once.

Note

When should you use distributed SQL? Not automatically. For applications whose data fits in one instance plus read replicas, RDS or Cloud SQL is already more than adequate and simpler. Automatic distribution only pays off when your application has global read-write traffic, very high uptime requirements, or data growing beyond a single instance's limits.

#Comparing Managed Relational Database Services

The service map across the three major providers:

Need	AWS	GCP	Azure
Managed PostgreSQL/MySQL	RDS	Cloud SQL	Azure Database for PostgreSQL/MySQL
Cloud-native distributed SQL	Aurora	Spanner	Azure SQL Database (Hyperscale)
Supported engines	MySQL, PostgreSQL, MariaDB, Oracle, SQL Server	PostgreSQL, MySQL, SQL Server	SQL Server, PostgreSQL, MySQL

The good news is that RDS, Cloud SQL, and Azure Database for PostgreSQL support the open-source engines you already know. That means you can move between providers without changing your ORM or rewriting queries — migration is just exporting data and importing it into the new service.

#Creating a Database with the AWS CLI

Hands-on practice: aws rds create-db-instance creates a managed PostgreSQL database:

Creating an RDS PostgreSQL instance

aws rds create-db-instance \
  --db-instance-identifier prod-postgres \
  --db-instance-class db.t3.medium \
  --engine postgres \
  --engine-version 16.1 \
  --allocated-storage 100 \
  --multi-az \
  --master-username admin \
  --master-user-password 'S3cure!Pass' \
  --db-subnet-group-name prod-db-subnets \
  --vpc-security-group-ids sg-0abc123

A brief explanation of the important flags:

--multi-az turns on high availability in one go — primary and standby are automatically spread across two AZs.
--db-subnet-group-name points to a subnet group spanning several AZs; this is where the standby replica will live.
--vpc-security-group-ids restricts who can connect — ideally only the application's security group, not the internet.

Caution

--master-user-password 'S3cure!Pass' in the example above is only an illustration. Never put database credentials in a command line, script, or repository. Store them in Secrets Manager or a parameter store, then let the application fetch them at runtime with temporary credentials — exactly the IAM principle we covered in episode 4.

#Conclusion

In this episode 9, you understood why a managed database makes more sense for production than a self-managed one, how multi-AZ high availability works through synchronous replication and automatic failover, and what cloud-native distributed SQL is and when it's worth using. You also saw the service map for RDS, Aurora, Cloud SQL, Spanner, Azure SQL, and Azure Database for PostgreSQL, along with the aws rds create-db-instance command example.

The keys to take away:

Managed databases save hidden operational costs — patching, backup, failover, and monitoring are handled by the provider.
Multi-AZ means automatically enabled synchronous replication — the standby isn't for reading, it's for taking over when the primary fails.
Distributed SQL (Aurora, Spanner) is for extreme scale and uptime — not the default need.

Relational data is only one form of data. In episode 10, we'll discuss NoSQL & In-Memory Databases — DynamoDB, Redis, and friends — for needs that don't fit rigid tables: flexible schemas, millisecond latency, and caches that speed applications up thousands of times.