Managed Database Services Comparison

Multi-Cloud Database Landscape

Every cloud provider offers a rich portfolio of managed database services spanning relational, document, key-value, wide-column, graph, and in-memory stores. Choosing the right database service, or combination of services, is one of the most consequential architectural decisions you will make. It affects application performance, data consistency, operational complexity, and long-term vendor lock-in.

AWS offers the broadest database portfolio with RDS, Aurora, DynamoDB, ElastiCache, MemoryDB, Neptune, Timestream, and Keyspaces. Azure provides Azure SQL, Cosmos DB, Azure Cache for Redis, Azure Database for PostgreSQL/MySQL, and Table Storage. Google Cloud offers Cloud SQL, AlloyDB, Spanner, Firestore, Bigtable, Memorystore, and Cloud Datastore. Each service makes different trade-offs in consistency, scalability, pricing, and operational model.

This guide compares managed database services across all three providers, organized by database category. We cover relational databases, NoSQL document stores, key-value stores, caching services, serverless options, global distribution, and migration strategies. Each section includes real CLI commands, configuration examples, and comparison tables.

Relational Database Services

Relational databases remain the default choice for transactional workloads, complex queries, and applications with well-defined schemas. All three providers offer managed versions of popular open-source engines (PostgreSQL, MySQL, MariaDB) plus proprietary offerings that push the boundaries of cloud-native relational databases.

Service Overview

# AWS: Create an Aurora PostgreSQL Serverless v2 cluster
aws rds create-db-cluster \
  --db-cluster-identifier prod-aurora \
  --engine aurora-postgresql \
  --engine-version 15.4 \
  --serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=64 \
  --master-username admin \
  --manage-master-user-password \
  --storage-encrypted \
  --vpc-security-group-ids sg-0123456789abcdef0 \
  --db-subnet-group-name prod-subnet-group

aws rds create-db-instance \
  --db-instance-identifier prod-aurora-instance-1 \
  --db-cluster-identifier prod-aurora \
  --engine aurora-postgresql \
  --db-instance-class db.serverless

# Azure: Create an Azure SQL Database (Hyperscale tier)
az sql server create \
  --name sql-prod-server \
  --resource-group rg-database \
  --location eastus \
  --admin-user sqladmin \
  --admin-password '<password>'

az sql db create \
  --name appdb \
  --server sql-prod-server \
  --resource-group rg-database \
  --edition Hyperscale \
  --capacity 2 \
  --family Gen5 \
  --ha-replicas 1 \
  --zone-redundant true \
  --backup-storage-redundancy Zone

# GCP: Create a Cloud SQL PostgreSQL instance with HA
gcloud sql instances create prod-postgres \
  --database-version=POSTGRES_15 \
  --tier=db-custom-4-16384 \
  --region=us-central1 \
  --availability-type=REGIONAL \
  --storage-type=SSD \
  --storage-size=100GB \
  --storage-auto-increase \
  --enable-point-in-time-recovery \
  --backup-start-time=02:00 \
  --maintenance-window-day=SUN \
  --maintenance-window-hour=03 \
  --database-flags=max_connections=500,shared_buffers=4096MB

NoSQL Document Databases

Document databases store data as flexible JSON-like documents, enabling schema-less development and horizontal scalability. Each provider offers a flagship NoSQL document database with different consistency models, query capabilities, and scaling characteristics.

Core Comparison

# AWS: Create a DynamoDB table with on-demand billing
aws dynamodb create-table \
  --table-name Orders \
  --attribute-definitions \
    AttributeName=PK,AttributeType=S \
    AttributeName=SK,AttributeType=S \
    AttributeName=GSI1PK,AttributeType=S \
    AttributeName=GSI1SK,AttributeType=S \
  --key-schema \
    AttributeName=PK,KeyType=HASH \
    AttributeName=SK,KeyType=RANGE \
  --global-secondary-indexes '[
    {
      "IndexName": "GSI1",
      "KeySchema": [
        {"AttributeName":"GSI1PK","KeyType":"HASH"},
        {"AttributeName":"GSI1SK","KeyType":"RANGE"}
      ],
      "Projection": {"ProjectionType":"ALL"}
    }
  ]' \
  --billing-mode PAY_PER_REQUEST \
  --table-class STANDARD \
  --point-in-time-recovery-specification PointInTimeRecoveryEnabled=true

# Azure: Create a Cosmos DB account with SQL API
az cosmosdb create \
  --name cosmos-prod-db \
  --resource-group rg-database \
  --default-consistency-level Session \
  --locations regionName=eastus failoverPriority=0 isZoneRedundant=true \
  --locations regionName=westus failoverPriority=1 isZoneRedundant=true \
  --enable-automatic-failover true \
  --enable-multiple-write-locations true

az cosmosdb sql database create \
  --account-name cosmos-prod-db \
  --resource-group rg-database \
  --name appdb

az cosmosdb sql container create \
  --account-name cosmos-prod-db \
  --resource-group rg-database \
  --database-name appdb \
  --name orders \
  --partition-key-path /customerId \
  --throughput 4000 \
  --idx @indexing-policy.json

# GCP: Create a Firestore database in Native mode
gcloud firestore databases create \
  --location=nam5 \
  --type=firestore-native

# GCP: Create composite index for Firestore
gcloud firestore indexes composite create \
  --collection-group=orders \
  --field-config field-path=customerId,order=ASCENDING \
  --field-config field-path=createdAt,order=DESCENDING

Key-Value & Wide-Column Stores

Key-value stores provide the simplest and fastest data access patterns: put a value by key, get a value by key. Wide-column stores extend this with column families that enable efficient range scans and time-series queries. These databases excel at high-throughput, low-latency workloads like session management, caching, IoT time- series, and real-time personalization.

Cloud Bigtable deserves special attention. It is the same technology that powers Google Search, Maps, and Gmail internally. It provides single-digit millisecond latency at massive scale and integrates natively with BigQuery, Dataflow, and Dataproc for analytics. Bigtable is ideal for workloads that require consistent sub-10ms reads at petabyte scale, a capability that neither DynamoDB nor Cosmos DB match for wide-column access patterns.

In-Memory & Caching Services

Caching layers reduce latency and database load by storing frequently accessed data in memory. All three providers offer managed Redis services, and AWS additionally offers managed Memcached and a Redis-compatible durable store (MemoryDB).

# AWS: Create an ElastiCache Serverless Redis cluster
aws elasticache create-serverless-cache \
  --serverless-cache-name prod-cache \
  --engine redis \
  --cache-usage-limits "DataStorage={Maximum=100,Unit=GB},ECPUPerSecond={Maximum=15000}" \
  --security-group-ids sg-0123456789abcdef0 \
  --subnet-ids subnet-abc123 subnet-def456

# Azure: Create an Azure Cache for Redis (Premium tier with clustering)
az redis create \
  --name redis-prod-cache \
  --resource-group rg-database \
  --location eastus \
  --sku Premium \
  --vm-size P1 \
  --shard-count 3 \
  --enable-non-ssl-port false \
  --minimum-tls-version 1.2 \
  --zones 1 2 3

# GCP: Create a Memorystore Redis instance
gcloud redis instances create prod-cache \
  --region=us-central1 \
  --tier=standard \
  --size=5 \
  --redis-version=redis_7_0 \
  --enable-auth \
  --transit-encryption-mode=SERVER_AUTHENTICATION \
  --network=vpc-prod \
  --connect-mode=PRIVATE_SERVICE_ACCESS

Serverless Database Options

Serverless databases eliminate capacity planning by automatically scaling compute and storage based on demand. They are ideal for variable workloads, development environments, and applications with unpredictable traffic patterns. Each provider has taken a different approach to serverless databases:

Serverless Comparison

Global Distribution & Multi-Region

For applications serving users across multiple regions, global database distribution reduces read latency and provides disaster recovery. Each provider approaches global distribution differently:

Global Distribution Patterns

• DynamoDB Global Tables: Multi-region, multi-active replication with eventual consistency across regions. Writes to any region are replicated to all others within seconds. Conflict resolution uses last-writer-wins based on timestamps.
• Aurora Global Database: One primary writer region with up to five read-only secondary regions. Cross-region replication lag is typically under 1 second. Planned failover promotes a secondary to writer in under 1 minute.
• Cosmos DB multi-region writes: True multi-master with configurable conflict resolution (last-writer-wins, custom stored procedures, or merge). Five consistency levels from strong to eventual. The most flexible global distribution model among all providers.
• Spanner multi-region: Strong consistency across regions with TrueTime-based synchronization. The only database that provides linearizable reads and writes across continents. Higher latency for writes (due to cross-region consensus) but guaranteed consistency.
• Firestore multi-region: Automatic replication across region pairs (e.g., nam5 = US multi-region). Strong consistency for reads following writes. No multi-master; single write region with global reads.

# AWS: Enable DynamoDB Global Tables (replicate to eu-west-1)
aws dynamodb update-table \
  --table-name Orders \
  --replica-updates '[{"Create":{"RegionName":"eu-west-1"}}]'

# AWS: Create Aurora Global Database
aws rds create-global-cluster \
  --global-cluster-identifier prod-global \
  --source-db-cluster-identifier arn:aws:rds:us-east-1:123456789012:cluster:prod-aurora \
  --engine aurora-postgresql

# Azure: Add a region to Cosmos DB
az cosmosdb update \
  --name cosmos-prod-db \
  --resource-group rg-database \
  --locations regionName=eastus failoverPriority=0 isZoneRedundant=true \
  --locations regionName=westeurope failoverPriority=1 isZoneRedundant=true \
  --locations regionName=southeastasia failoverPriority=2 isZoneRedundant=true

# GCP: Create a multi-region Spanner instance
gcloud spanner instances create prod-spanner \
  --config=nam-eur-asia1 \
  --processing-units=1000 \
  --description="Global production instance"

Migration & Portability

Database migration between cloud providers is one of the most challenging aspects of multi-cloud strategy. The difficulty varies dramatically based on the database type: relational databases using standard SQL engines (PostgreSQL, MySQL) are relatively portable, while proprietary NoSQL services (DynamoDB, Cosmos DB, Firestore) create deep lock-in.

Portability Matrix

Cost Comparison & Optimization

Database costs are driven by compute, storage, I/O operations, data transfer, and backup storage. The pricing models differ significantly across providers and database types, making direct comparison challenging. Below are key cost considerations for each category:

Relational Database Cost Comparison

For a typical production workload (4 vCPUs, 16 GB RAM, 500 GB storage, Multi-AZ/HA), approximate monthly costs are:

Cost Optimization Strategies

• Reserved instances / committed use: All providers offer 1-year and 3-year reservations with 30–60% savings. Use reserved capacity for stable production workloads.
• Right-size instances: Monitor CPU and memory utilization. Many database instances are over-provisioned. Use Performance Insights (AWS), Query Performance Insight (Azure), or Query Insights (GCP) to identify right-sizing opportunities.
• Serverless for variable workloads: Use Aurora Serverless v2, Azure SQL Serverless, or DynamoDB On-Demand for development environments and workloads with unpredictable traffic.
• Storage tiering: Archive old data to cheaper storage. DynamoDB supports infrequent access table class (60% lower storage cost). Cosmos DB supports analytical store for cold data. Use partitioning and archival strategies.
• Connection pooling: Use connection poolers like PgBouncer (RDS/Aurora), built-in connection pooling (Azure SQL), or PgBouncer on AlloyDB to reduce the need for larger instances.

Choosing the Right Database Strategy

Database selection should be driven by data access patterns, consistency requirements, scalability needs, and portability goals, not just provider preference. Understanding the NoSQL cost landscape is important for making informed decisions.

NoSQL Cost Comparison

NoSQL pricing models vary significantly across providers. DynamoDB charges per read and write capacity unit, Cosmos DB charges per request unit (RU), and Firestore charges per document operation. The following table estimates costs for a typical workload with 10 million reads and 2 million writes per day:

# AWS: Estimate DynamoDB costs with on-demand pricing
# 10M reads x $0.25 per 1M read request units = $2.50/day
# 2M writes x $1.25 per 1M write request units = $2.50/day
# Total: ~$5/day for operations + storage

# Azure: Estimate Cosmos DB costs
# 1 RU = 1 point read (1 KB item by ID)
# Complex queries: 5-50 RUs per query
# Approximate: 400 RU/s baseline with autoscale to 4000 RU/s
# Cost: 400 RU/s x $0.008 per 100 RU/s per hour x 24h = $0.77/day baseline

# GCP: Estimate Firestore costs
# 10M reads x $0.036 per 100K reads = $3.60/day
# 2M writes x $0.108 per 100K writes = $2.16/day
# Total: ~$5.76/day for operations + storage

Here is a decision framework organized by key selection criteria:

By Access Pattern

• Complex queries with joins: Relational database (Aurora, Azure SQL, Cloud SQL, AlloyDB, Spanner)
• Key-based lookups with flexible schema: Document database (DynamoDB, Cosmos DB, Firestore)
• High-throughput time-series: Wide-column store (Bigtable, Keyspaces) or time-series database (Timestream)
• Sub-millisecond caching: In-memory store (ElastiCache, Azure Cache for Redis, Memorystore)
• Graph traversals: Graph database (Neptune on AWS, Cosmos DB Gremlin API on Azure, or self-managed Neo4j)

By Multi-Cloud Strategy

• Maximum portability: Use PostgreSQL (available as managed service on all three clouds) for relational and MongoDB-compatible APIs (Cosmos DB, DocumentDB) for document data.
• Best-of-breed per cloud: Use DynamoDB on AWS, Cosmos DB on Azure, and Firestore on GCP with a data access abstraction layer in your application.
• Global consistency: Cloud Spanner is the only option for strongly consistent, globally distributed relational data. CockroachDB (self-managed) is a multi-cloud alternative.

Related Resources

Explore provider-specific database guides for deeper coverage:

• AWS DynamoDB Data Modeling Guide
• Azure Cosmos DB Consistency Models Guide
• GCP Firestore Data Modeling Guide