Cloud Database Services: Azure, AWS & GCP Complete Comparison

Why Managed Databases?

Self-hosting a database in production means you own: OS patching, PostgreSQL upgrades, replication setup, failover testing, backup validation, storage scaling, security hardening, and on-call rotation.

Managed services handle all of that. The trade-off is cost and reduced control over internal settings. For most teams, managed is the right default.

Azure Database Services

Azure SQL Database

Engine: SQL Server (PaaS)
Best for: .NET apps, enterprise workloads, BI reporting, existing SQL Server skills

# Create with Azure CLI
az sql server create \
  --name myapp-sql-server \
  --resource-group myRG \
  --location eastus \
  --admin-user sqladmin \
  --admin-password $SQL_PASS

az sql db create \
  --resource-group myRG \
  --server myapp-sql-server \
  --name myapp \
  --edition GeneralPurpose \
  --family Gen5 \
  --capacity 4 \
  --backup-storage-redundancy Geo

Tiers:

• Basic / Standard / Premium — DTU-based (simpler)
• General Purpose — vCore, 5.1GB/vCore RAM — most workloads
• Business Critical — In-memory OLTP, read replica, 3x IOPS — high performance
• Hyperscale — up to 100TB, instant backups, fast scaling — very large databases

Key features: Built-in HA (99.99% SLA), point-in-time restore (35 days), auto-tuning, Query Performance Insight, Entra ID auth, Always Encrypted, Ledger tables.

Azure Database for PostgreSQL Flexible Server

Engine: PostgreSQL 11–16
Best for: New cloud-native apps, open-source preference, cost-optimised PostgreSQL

az postgres flexible-server create \
  --name myapp-pg \
  --resource-group myRG \
  --location eastus \
  --sku-name Standard_D4ds_v5 \
  --tier GeneralPurpose \
  --version 16 \
  --high-availability ZoneRedundant \
  --storage-size 256

Compute tiers: Burstable (B1ms–B4ms), General Purpose (D2s–D96s), Memory Optimized (E2ds–E96ds)
Extensions supported: pgvector, TimescaleDB, PostGIS, pg_cron, pg_partman

Azure Database for MySQL Flexible Server

Engine: MySQL 5.7, 8.0
Best for: LAMP stack apps, WordPress, Laravel, existing MySQL workloads

Similar setup to PostgreSQL. Supports zone-redundant HA, read replicas, and VNet integration.

Azure Cosmos DB

Microsoft's globally distributed, multi-model database. One Cosmos DB account can serve multiple APIs.

# Create account (multi-region, strong consistency)
az cosmosdb create \
  --name myapp-cosmos \
  --resource-group myRG \
  --locations regionName=eastus failoverPriority=0 \
                regionName=westeurope failoverPriority=1 \
  --default-consistency-level Session \
  --enable-multiple-write-locations true

# Create database and container
az cosmosdb sql database create --account-name myapp-cosmos \
  --resource-group myRG --name MyAppDB

az cosmosdb sql container create \
  --account-name myapp-cosmos --resource-group myRG \
  --database-name MyAppDB --name Orders \
  --partition-key-path "/tenantId" \
  --throughput 400

APIs: | API | Use Case | Compatible With | |---|---|---| | NoSQL (SQL) | Document store, Cosmos-native | Cosmos SDK | | MongoDB | Existing MongoDB apps | MongoDB drivers | | Apache Cassandra | Wide-column | CQL / Cassandra drivers | | Table | Key-value, migrate from Azure Table Storage | Azure Table SDK | | Gremlin | Graph database | Apache TinkerPop |

Consistency levels (5 choices):

Strong → Bounded Staleness → Session → Consistent Prefix → Eventual
←  Higher consistency, lower throughput, higher latency  →
→  Higher availability, lower latency, higher throughput →

Pricing: Request Units (RU/s) — 1 RU = 1 read of a 1KB item. Provisioned or serverless.

Azure Cache for Redis

Fully managed Redis. Covered in detail in the Redis guide.
Enterprise tier adds Redis Stack: RediSearch, RedisJSON, RedisTimeSeries.

Azure Managed Instance for Apache Cassandra

Fully managed Cassandra clusters deployed in your VNet. Compatible with Apache Cassandra 3.11 and 4.0.

AWS Database Services

Amazon RDS (Relational Database Service)

Multi-engine managed SQL: PostgreSQL, MySQL, MariaDB, Oracle, SQL Server.

aws rds create-db-instance \
  --db-instance-identifier myapp-postgres \
  --db-instance-class db.r6g.xlarge \
  --engine postgres \
  --engine-version 16.2 \
  --master-username pgadmin \
  --master-user-password $PG_PASS \
  --allocated-storage 200 \
  --storage-type gp3 \
  --storage-encrypted \
  --multi-az \
  --backup-retention-period 14 \
  --deletion-protection

RDS Proxy: Serverless connection pooler — essential for Lambda-based apps.

Amazon Aurora

AWS's proprietary engine, MySQL/PostgreSQL-compatible but 3–5x faster.

aws rds create-db-cluster \
  --db-cluster-identifier myapp-aurora \
  --engine aurora-postgresql \
  --engine-version 16.1 \
  --master-username pgadmin \
  --master-user-password $PG_PASS \
  --db-subnet-group-name myapp-subnet-group \
  --vpc-security-group-ids sg-xxxxxxxx \
  --serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=16

Aurora vs RDS: Aurora auto-scales storage (up to 128TB), has faster replication, Aurora Serverless v2 scales to zero, Global Database for cross-region with sub-1s RPO.

Amazon DynamoDB

Fully covered in the Cassandra & DynamoDB guide.

Quick reference:

• On-demand mode — pay per request, instant scaling — development or unpredictable traffic
• Provisioned mode — reserved RCU/WCU, cheaper at stable load
• DynamoDB Accelerator (DAX) — in-memory cache, reduces read latency to microseconds

Amazon DocumentDB

MongoDB-compatible document database (wire protocol 5.0, but different internals).

aws docdb create-db-cluster \
  --db-cluster-identifier myapp-docdb \
  --engine docdb \
  --master-username admin \
  --master-user-password $DOCDB_PASS \
  --engine-version 5.0.0

# Add 3 instances for HA
aws docdb create-db-instance \
  --db-cluster-identifier myapp-docdb \
  --db-instance-identifier myapp-docdb-1 \
  --db-instance-class db.r6g.large \
  --engine docdb

⚠ Compatibility note: DocumentDB does not implement all MongoDB operators. Test $lookup, $facet, and complex aggregation stages before migrating.

Amazon Keyspaces

Serverless Cassandra-compatible service.

# Create keyspace
aws keyspaces create-keyspace --keyspace-name myapp

# Tables defined in CQL files — applied via CLI or SDK
aws keyspaces create-table \
  --keyspace-name myapp \
  --table-name sensor_readings \
  --schema-definition '{"allColumns":[...],"partitionKeys":[...],"clusteringKeys":[...]}'

Point-in-time recovery (35 days), at-rest encryption, and IAM-based access control included.

Amazon Neptune

Managed graph database supporting Gremlin and SPARQL.

Use cases: Fraud detection, social networks, recommendation engines, knowledge graphs.

aws neptune create-db-cluster \
  --db-cluster-identifier myapp-neptune \
  --engine neptune \
  --db-subnet-group-name myapp-subnet-group

# Gremlin query
g.V().hasLabel('User').has('id', 'u_99')
  .out('FOLLOWS').out('FOLLOWS')
  .dedup()
  .values('name')
  .limit(10)

Amazon ElastiCache

Managed Redis and Memcached. Covered in the Redis guide.

Amazon Timestream

Purpose-built serverless time series database.

# Perfect for IoT, metrics, DevOps telemetry
aws timestream-write create-database --database-name IoTMetrics

aws timestream-write create-table \
  --database-name IoTMetrics \
  --table-name SensorReadings \
  --retention-properties "MemoryStoreRetentionPeriodInHours=24,MagneticStoreRetentionPeriodInDays=365"

Auto-tiering: hot data in memory (24h), warm in SSD (days–weeks), cold in magnetic (months–years).

Amazon OpenSearch Service

Managed Elasticsearch / OpenSearch clusters.

aws opensearch create-domain \
  --domain-name myapp-search \
  --engine-version OpenSearch_2.11 \
  --cluster-config InstanceType=r6g.large.search,InstanceCount=3 \
  --ebs-options EBSEnabled=true,VolumeType=gp3,VolumeSize=100 \
  --encrypt-at-rest-options Enabled=true

Google Cloud Platform Database Services

Cloud SQL

Managed PostgreSQL (14–16), MySQL (5.7/8.0), SQL Server.

gcloud sql instances create myapp-pg \
  --database-version=POSTGRES_16 \
  --region=us-central1 \
  --tier=db-custom-4-15360 \
  --availability-type=REGIONAL \
  --backup-start-time=02:00 \
  --retained-backups-count=14 \
  --storage-auto-increase

gcloud sql databases create myapp --instance=myapp-pg
gcloud sql users create pgadmin --instance=myapp-pg --password=$PG_PASS

Cloud Spanner

Google's globally distributed, strongly consistent relational database. The only database that combines SQL, ACID, and infinite horizontal scale.

gcloud spanner instances create myapp-spanner \
  --config=nam6 \
  --description="MyApp Spanner" \
  --processing-units=1000

gcloud spanner databases create myapp \
  --instance=myapp-spanner \
  --ddl="CREATE TABLE Orders (
    OrderId STRING(36) NOT NULL,
    UserId STRING(36) NOT NULL,
    Status STRING(20),
    TotalCents INT64,
    CreatedAt TIMESTAMP OPTIONS (allow_commit_timestamp=true),
  ) PRIMARY KEY (OrderId)"

When to use Spanner: When you need SQL + global strong consistency + 99.999% SLA. Cost is high (~$65/month per processing unit). Used by Google, Snap, Toyota, Wayfair.

Firestore

Serverless document database (Firebase lineage). Excellent for mobile/web real-time apps.

// Real-time listener — perfect for collaborative apps
const unsub = db.collection("rooms").doc("room-99")
  .onSnapshot((doc) => {
    console.log("Live update:", doc.data())
  })

// Transactions
await db.runTransaction(async (tx) => {
  const orderRef = db.collection("orders").doc("ORD-001")
  const order = await tx.get(orderRef)
  tx.update(orderRef, { status: "shipped", shippedAt: Timestamp.now() })
})

Firestore vs Realtime Database:
Use Firestore (newer) unless you specifically need the Realtime Database's 1ms latency. Firestore has better query support, offline sync, and no 1MB document limit.

Bigtable

HBase-compatible wide-column store. Petabyte-scale, millisecond latency.

gcloud bigtable instances create myapp-bt \
  --cluster=myapp-bt-c1 \
  --cluster-zone=us-central1-a \
  --cluster-num-nodes=3

gcloud bigtable tables create sensor-readings \
  --instance=myapp-bt \
  --column-families=data,meta

Row key design is everything — prefix with a reversed timestamp or use composite keys to avoid hot spots.

AlloyDB for PostgreSQL

PostgreSQL-compatible, 4x faster OLTP than Cloud SQL, 100x faster analytics via columnar engine.

gcloud alloydb clusters create myapp-alloydb \
  --region=us-central1 \
  --password=$PG_PASS

gcloud alloydb instances create myapp-alloydb-primary \
  --instance-type=PRIMARY \
  --cluster=myapp-alloydb \
  --region=us-central1 \
  --cpu-count=4

At-a-Glance Comparison

| Need | Azure | AWS | GCP | |---|---|---|---| | Managed PostgreSQL | Flexible Server | RDS / Aurora PG | Cloud SQL / AlloyDB | | Managed MySQL | Flexible Server MySQL | RDS / Aurora MySQL | Cloud SQL MySQL | | Managed SQL Server | Azure SQL Database | RDS for SQL Server | Cloud SQL for SQL Server | | Document NoSQL | Cosmos DB (Mongo API) | DocumentDB | Firestore | | Key-Value | Cosmos DB (Table) | DynamoDB | Firestore | | Wide-Column | Cosmos DB (Cassandra) / Managed Cassandra | Keyspaces / DynamoDB | Bigtable | | In-memory cache | Azure Cache for Redis | ElastiCache (Redis) | Memorystore | | Graph | Cosmos DB (Gremlin) | Neptune | — | | Search | Azure AI Search | OpenSearch Service | Vertex AI Search | | Time series | Azure Data Explorer | Timestream | Bigtable | | Globally distributed SQL | Cosmos DB (SQL API) | Aurora Global | Cloud Spanner |

Key Decision Rules

1. Already on Azure/.NET? → Azure SQL or PostgreSQL Flexible Server + Cosmos DB for document needs.
2. Already on AWS / serverless? → Aurora PostgreSQL + DynamoDB + ElastiCache.
3. Already on GCP / Firebase? → Cloud SQL (PostgreSQL) + Firestore + Memorystore.
4. Need global strong consistency at any scale? → Cloud Spanner (and pay the premium).
5. Migrating MongoDB to cloud? → Atlas (any cloud) is most compatible; DocumentDB has gaps.
6. IoT / telemetry billions/day? → AWS Keyspaces, Bigtable, or Azure Managed Cassandra.