Managed Databases: Picking One Across Clouds

Same engine — PostgreSQL — on three managed services: Amazon RDS for PostgreSQL, Azure Database for PostgreSQL (Flexible Server), and Cloud SQL for PostgreSQL. Comparing the same engine everywhere is what makes this a fair comparison instead of a features list — the SQL is identical; what differs is the operational layer wrapped around it.

Provisioning an equivalent instance

4 vCPU / 16 GB RAM, single-zone (no HA yet), 100 GB storage, on each:

aws rds create-db-instance \
  --db-instance-identifier orders-db \
  --engine postgres --engine-version 16.4 \
  --db-instance-class db.m6g.xlarge \
  --allocated-storage 100 \
  --master-username admin --master-user-password '********'

az postgres flexible-server create \
  --resource-group learn-rg --name orders-db \
  --location eastus --version 16 \
  --sku-name Standard_D4ds_v5 --tier GeneralPurpose \
  --storage-size 100 --admin-user admin --admin-password '********'

gcloud sql instances create orders-db \
  --database-version=POSTGRES_16 \
  --cpu=4 --memory=16GB \
  --storage-size=100 --storage-type=SSD \
  --region=us-central1

List prices, single region, single-AZ — a real quote will differ by region and changes over time, but the spread between the three (under 5%) has held for years and is worth trusting more than any single number in this table.

Failover behavior

All three use the same underlying technique — a synchronously replicated standby, promoted on failure, with the client-facing endpoint repointed rather than the client needing to know a new address.

aws rds failover-db-cluster --db-cluster-identifier orders-db-cluster

$ aws rds describe-events --source-identifier orders-db --source-type db-instance --duration 5
{
    "Events": [
        {"Message": "Multi-AZ instance failover started", "Date": "2026-09-13T10:12:01Z"},
        {"Message": "Multi-AZ instance failover completed", "Date": "2026-09-13T10:12:47Z"}
    ]
}

RDS Multi-AZ failover here: 46 seconds. RDS keeps the same endpoint DNS name and flips the CNAME target during failover — the application reconnects to the same hostname and gets the new primary once DNS propagates (usually within the client’s connection retry window).

Azure’s zone-redundant HA and Cloud SQL’s regional HA follow the same shape: a synchronous standby in a second zone, promoted on health-check failure, with the connection string unchanged. Published targets put Azure Flexible Server HA failover in the tens-of-seconds range and Cloud SQL HA typically under a minute — in the same order of magnitude as RDS, with the actual number depending more on what triggered the failover (a planned test vs. a real zone outage) than on which cloud it is. Benchmark your own failover with a real client connection before trusting any vendor’s published average; run-to-run variance is usually larger than the gap between clouds.

Backup and restore

aws rds describe-db-instances --db-instance-identifier orders-db \
  --query "DBInstances[0].{Retention:BackupRetentionPeriod,Window:PreferredBackupWindow}"

$ aws rds describe-db-instances --db-instance-identifier orders-db --query "DBInstances[0].{Retention:BackupRetentionPeriod,Window:PreferredBackupWindow}"
{
    "Retention": 7,
    "Window": "07:00-07:30"
}

aws rds restore-db-instance-to-point-in-time \
  --source-db-instance-identifier orders-db \
  --target-db-instance-identifier orders-db-restored \
  --restore-time 2026-09-13T09:45:00Z

RDS restores to a new instance, never in place — this is true of Azure and GCP too, and is the detail that catches teams off guard during an actual incident: “restore the database” means “stand up a second instance and cut traffic to it,” not “roll this one back,” on all three clouds.

Cloud SQL’s 365-day ceiling on automated retention is the one real spread in this table — useful if a compliance requirement forces long PITR windows without a manual snapshot-management process on top.

Practice

aws rds modify-db-instance --db-instance-identifier orders-db --backup-retention-period 14 --apply-immediately

az postgres flexible-server parameter set --resource-group learn-rg --server-name orders-db --name backup_retention_days --value 14

gcloud sql instances patch orders-db --backup-start-time=03:00 --retained-backups-count=14

aws rds modify-db-instance --db-instance-identifier orders-db --multi-az --apply-immediately

az postgres flexible-server update --resource-group learn-rg --name orders-db --high-availability ZoneRedundant

gcloud sql instances patch orders-db --availability-type=REGIONAL

aws rds describe-db-instances --db-instance-identifier orders-db --query "DBInstances[0].StorageType"

Next: an actual monthly cost — not a features comparison — for 1M invocations on Lambda, Azure Functions, and Cloud Run.