Cloud Compare / Databases compared
Databases compared
Relational and non-relational database services in Google Cloud, AWS and Azure side by side: managed engines, cloud-native and distributed SQL, NoSQL by data model, and recent changes.
Each cloud offers the same families of databases: managed versions of the familiar relational engines, its own cloud-native relational service built for scale, and a set of non-relational (NoSQL) services for documents, key-value data, caching, graphs and time series. The names rarely line up, so this page maps them side by side, first relational, then non-relational.
At a glance
| Category | Google Cloud | AWS | Azure |
|---|---|---|---|
| Relational (SQL) | |||
| Managed MySQL, PostgreSQL, SQL Server | Cloud SQL | Amazon RDS | Azure Database for MySQL / PostgreSQL (Flexible Server); Azure SQL Database and SQL Managed Instance |
| Cloud-native, high-performance relational | AlloyDB for PostgreSQL | Amazon Aurora (MySQL and PostgreSQL compatible) | Azure SQL Database Hyperscale; Azure HorizonDB (PostgreSQL, preview) |
| Globally distributed SQL | Spanner | Aurora DSQL | Azure Cosmos DB for PostgreSQL (retiring) → Azure Database for PostgreSQL elastic clusters |
| Oracle Database | Oracle Database@Google Cloud; Bare Metal Solution | RDS for Oracle; Oracle Database@AWS | Oracle Database@Azure |
| Non-relational (NoSQL) | |||
| Key-value and wide-column | Bigtable | DynamoDB; Amazon Keyspaces (Cassandra) | Azure Cosmos DB (NoSQL, Cassandra, Table APIs); Azure Table Storage |
| Document | Firestore | DynamoDB | Azure Cosmos DB for NoSQL |
| MongoDB-compatible | Firestore with MongoDB compatibility | Amazon DocumentDB | Azure DocumentDB; Azure Cosmos DB for MongoDB (RU) |
| In-memory cache (Redis, Valkey, Memcached) | Memorystore | ElastiCache; MemoryDB (durable) | Azure Managed Redis |
| Graph | Spanner Graph | Amazon Neptune | Azure Cosmos DB for Apache Gremlin |
| Time series | Bigtable; BigQuery | Timestream for InfluxDB | Azure Data Explorer |
| Search and vector | Vertex AI Vector Search; vector support in AlloyDB, Cloud SQL, Spanner, Firestore | Amazon OpenSearch Service; vector support in Aurora, RDS PostgreSQL, DynamoDB via zero-ETL | Azure AI Search; vector support in Cosmos DB, Azure SQL, PostgreSQL |
| For context: analytics | |||
| Data warehouse | BigQuery | Amazon Redshift | Microsoft Fabric (Data Warehouse); Azure Synapse Analytics |
Relational: managed engines
The quickest way to the cloud for an existing database is the same engine, managed: the provider runs patching, backups, high availability and replicas; you keep your schema and drivers.
| Engine | Google Cloud | AWS | Azure |
|---|---|---|---|
| MySQL | Cloud SQL for MySQL | RDS for MySQL; Aurora MySQL | Azure Database for MySQL – Flexible Server |
| PostgreSQL | Cloud SQL for PostgreSQL; AlloyDB | RDS for PostgreSQL; Aurora PostgreSQL | Azure Database for PostgreSQL – Flexible Server |
| SQL Server | Cloud SQL for SQL Server | RDS for SQL Server | Azure SQL Database, Azure SQL Managed Instance, SQL Server on Azure VMs |
| MariaDB | – | RDS for MariaDB | – (Azure Database for MariaDB retired September 2025; use MySQL Flexible Server) |
| Oracle | Oracle Database@Google Cloud (Exadata, Autonomous) | RDS for Oracle; RDS Custom; Oracle Database@AWS | Oracle Database@Azure |
| IBM Db2 | – | RDS for Db2 | – |
| Operations | Cloud SQL | Amazon RDS | Azure (Flexible Server, Azure SQL) |
|---|---|---|---|
| High availability | Regional instance: standby in another zone, automatic failover | Multi-AZ instance or Multi-AZ cluster (two readable standbys) | Zone-redundant HA (Flexible Server); zone-redundant Business Critical / Hyperscale (Azure SQL) |
| Read scaling | Read replicas, including cross-region | Read replicas, including cross-region | Read replicas (Flexible Server); readable secondaries, geo-replicas (Azure SQL) |
| Point-in-time restore | Up to 35 days (Enterprise Plus edition) | Up to 35 days | Up to 35 days |
| Editions or tiers | Enterprise and Enterprise Plus editions | Instance classes; Multi-AZ options | Burstable, General Purpose, Memory Optimized / Business Critical (Flexible); General Purpose, Business Critical, Hyperscale (Azure SQL) |
| Serverless option | – (AlloyDB and Spanner scale more flexibly) | Aurora Serverless v2 | Azure SQL Database serverless |
| Private access | Private IP via private services access or Private Service Connect | In your VPC subnets | VNet integration or private endpoint |
Relational: cloud-native and distributed
Each provider has rebuilt the relational database around its own storage layer, separating compute from storage so it can scale reads, recover faster and fail over in seconds. And each has a database that keeps SQL and transactions while spreading data across regions.
| Google Cloud | AWS | Azure | |
|---|---|---|---|
| Cloud-native engine | AlloyDB for PostgreSQL: columnar engine for analytics on live data; AlloyDB Omni runs the same engine anywhere | Aurora: MySQL and PostgreSQL compatible, shared storage across three AZs, up to 15 read replicas, Global Database | Azure SQL Database Hyperscale (SQL Server engine) today; Azure HorizonDB (PostgreSQL, in preview) as the Aurora/AlloyDB equivalent |
| Globally distributed SQL | Spanner: strongly consistent across regions, up to 99.999% availability; GoogleSQL and PostgreSQL dialects; also graph, full-text and vector search | Aurora DSQL (generally available since May 2025): serverless, PostgreSQL compatible, active-active across regions | Distributed PostgreSQL (Citus): Azure Database for PostgreSQL elastic clusters, replacing Azure Cosmos DB for PostgreSQL (retiring 31 March 2029) |
| When to choose it | PostgreSQL that has outgrown Cloud SQL (AlloyDB); global transactional systems (Spanner) | MySQL or PostgreSQL that has outgrown RDS (Aurora); multi-region active-active (DSQL) | SQL Server workloads at scale (Hyperscale); large PostgreSQL (HorizonDB once generally available) |
| Watch for | Spanner's schema and query patterns differ from a single-node database: design keys to avoid hotspots | DSQL supports a subset of PostgreSQL features and uses optimistic concurrency: test the application | Check HorizonDB's preview limits before production use |
Non-relational: by data model
| Data model | Google Cloud | AWS | Azure | Typical use |
|---|---|---|---|---|
| Key-value / document, serverless | Firestore | DynamoDB | Azure Cosmos DB for NoSQL | User profiles, carts, sessions, mobile and web app back ends |
| Wide-column | Bigtable (HBase API, SQL queries) | Amazon Keyspaces (Cassandra API) | Cosmos DB for Apache Cassandra; Azure Managed Instance for Apache Cassandra | Very high write rates: IoT, telemetry, ad tech, personalisation |
| MongoDB-compatible | Firestore with MongoDB compatibility | Amazon DocumentDB | Azure DocumentDB (formerly vCore-based Cosmos DB for MongoDB); Cosmos DB for MongoDB (RU) | Moving MongoDB applications without rewriting them |
| In-memory | Memorystore for Valkey, Redis Cluster, Redis, Memcached | ElastiCache (Valkey, Redis OSS, Memcached); MemoryDB (durable, multi-AZ) | Azure Managed Redis | Caching, session state, leaderboards, rate limiting |
| Graph | Spanner Graph (ISO GQL) | Amazon Neptune (Gremlin, openCypher, SPARQL); Neptune Analytics | Cosmos DB for Apache Gremlin | Fraud rings, recommendations, network and identity relationships |
| Time series | Bigtable, or BigQuery for analysis | Timestream for InfluxDB | Azure Data Explorer | Metrics, sensor data, logs over time |
| Simple tables at low cost | Firestore in Datastore mode | DynamoDB on-demand | Azure Table Storage; Cosmos DB for Table | Lookups, configuration, small apps |
The flagship NoSQL services compared
| Firestore | DynamoDB | Azure Cosmos DB | |
|---|---|---|---|
| Model | Documents in collections | Items in tables (key-value and document) | Multi-model: NoSQL (JSON), MongoDB, Cassandra, Gremlin, Table APIs |
| Capacity model | Serverless, pay per read, write and storage | On-demand or provisioned capacity | Serverless, provisioned or autoscale request units (RU/s) |
| Multi-region | Multi-region locations, strongly consistent | Global tables (active-active; strong consistency option for multi-region) | Multi-region writes; five consistency levels from strong to eventual |
| Queries | Indexed queries, aggregations; real-time listeners for apps | Key and index lookups; PartiQL; zero-ETL to OpenSearch and Redshift for search and analytics | SQL-like queries over JSON; vector and full-text search |
| Strength | Mobile and web apps with offline sync (Firebase) | Predictable single-digit millisecond latency at any scale | Choice of API and consistency, global distribution |
| Watch for | Hot documents and collection limits on write rate | Design the partition and sort keys around access patterns up front | RU cost grows with poorly partitioned or unindexed queries |
Recent changes to know
| Cloud | Change |
|---|---|
| AWS | Amazon QLDB was discontinued on 31 July 2025 (AWS suggests Aurora PostgreSQL with audit tables). |
| AWS | Timestream for LiveAnalytics closed to new customers on 20 June 2025; new time-series work goes to Timestream for InfluxDB. |
| AWS | Aurora DSQL became generally available in May 2025. |
| Azure | Azure Database for MariaDB retired on 19 September 2025; MySQL Single Server was retired earlier in favour of Flexible Server. |
| Azure | vCore-based Cosmos DB for MongoDB is now Azure DocumentDB (generally available November 2025), built on the open-source DocumentDB project. |
| Azure | Azure Cache for Redis retires: Enterprise tiers on 31 March 2027, Basic/Standard/Premium on 30 September 2028. Move to Azure Managed Redis. |
| Azure | Azure Cosmos DB for PostgreSQL retires on 31 March 2029; move to Azure Database for PostgreSQL elastic clusters. |
| Google Cloud | Firestore with MongoDB compatibility became generally available in 2025. |
| All three | Valkey (the open-source Redis fork) is offered alongside or instead of Redis in managed caches. |
Choosing a database
- Moving an existing database: start with the same engine, managed (Cloud SQL, RDS, Azure Database / Azure SQL). It's the least change and the easiest rollback.
- PostgreSQL or MySQL that needs more: AlloyDB, Aurora, or (for SQL Server) Azure SQL Hyperscale. Same drivers, more scale and faster failover.
- Global, always-on transactions: Spanner or Aurora DSQL. Expect to adapt schema and transactions; the payoff is multi-region writes without building replication yourself.
- New app with simple, high-volume access patterns: Firestore, DynamoDB or Cosmos DB. Model the data around how it's read, not as normalised tables.
- Caching: Memorystore, ElastiCache or Azure Managed Redis in front of any of the above; MemoryDB if the cache must also be the durable store.
- Analytics: keep it out of the transactional database. BigQuery, Redshift and Fabric each have zero-ETL or federated links to their cloud's operational databases.
Whatever you choose, the operational baseline is the same in all three: private connectivity only, automated backups with point-in-time recovery, high availability across zones for production, encryption with customer-managed keys where required, and the backups covered by your backup checks (Google Cloud, AWS, Azure).
Compared as of October 2026. Service names, tiers and retirement dates change; check the provider's documentation before deciding.