Cloud Database Services: AWS vs Azure vs Google Cloud
Managed relational, distributed SQL, NoSQL and caching: what each database family is for and how RDS, Azure SQL, Cloud SQL, DynamoDB, Cosmos DB and others compare.
The fastest way to lose a weekend in the cloud is to run your own database on a VM and discover, during an outage, that the backups were never tested. Managed databases fix that problem, but they bring a new one: every provider offers a dozen of them, and choosing the wrong family (a document store for heavily relational data, a single-region SQL engine for a global app) is expensive to undo. This post sorts cloud databases into four families, explains what each is for, and compares the AWS, Azure and Google Cloud options.
What managed databases give you
A managed database service takes over the undifferentiated work: provisioning, patching, backups and point-in-time restore, replication and failover, monitoring, and often scaling. You keep schema design, query tuning, access control and capacity choices.
That doesn’t mean “no DBA”. It means your DBA time goes on data modelling and performance instead of applying patches at 2 am. Unless you need an engine or extension the cloud doesn’t offer, or have very specific tuning or licensing reasons, use the managed service.
The families:
| Family | Data model | Best for | Watch out for |
|---|---|---|---|
| Managed relational | Tables, SQL, transactions | Most business applications | Vertical scaling limits, single region |
| Distributed relational | SQL across many nodes or regions | Global scale with strong consistency | Cost, latency of global writes |
| NoSQL | Key-value, document, wide-column | Massive scale, simple access patterns, flexible schema | Designing for queries up front |
| In-memory cache | Key-value in RAM | Sub-millisecond reads, sessions, rate limits | It’s a cache: plan for loss |
Managed relational databases
This is where most applications should start. You get MySQL, PostgreSQL, SQL Server (and on AWS, Oracle and Db2) with the provider handling backups, high availability across zones, read replicas and minor version patching.
PostgreSQL has become the default choice for new workloads on all three clouds. It’s open source, has a huge extension ecosystem (PostGIS, pgvector for AI embeddings, TimescaleDB), and every provider runs a strong managed version. SQL Server shops will find Azure the most natural home: Azure SQL Database for new apps, SQL Managed Instance for lift-and-shift.
Amazon RDS Soon
Managed MySQL, PostgreSQL, MariaDB, SQL Server, Oracle and Db2. Automated backups, patching, Multi-AZ failover and read replicas. RDS Proxy pools connections for serverless and bursty clients.
Fully managed SQL Server engine as a single database or elastic pool, in provisioned or serverless compute (auto-pause when idle). Always on the latest engine, with built-in high availability and geo-replication.
Near-100% compatibility with on-premises SQL Server, including SQL Agent, cross-database queries and CLR, inside your VNet. The usual lift-and-shift target for SQL Server estates.
Flexible Server runs community PostgreSQL with zone-redundant high availability, read replicas, extensions such as pgvector, and stop/start to save cost. Azure Database for MySQL Flexible Server is the MySQL equivalent.
Cloud SQL Soon
Managed MySQL, PostgreSQL and SQL Server with regional high availability, read replicas, automated backups and point-in-time recovery. The Enterprise Plus edition adds a data cache and near-zero-downtime maintenance.
Test a restore, not just a backup. Restore last night’s backup to a new instance once a quarter and time it. That number is your real recovery time.
Cloud-native and distributed relational
When one primary node can’t keep up, or you need writes in several regions with strong consistency, classic managed databases hit a wall. This family rethinks the architecture: storage separated from compute, distributed across zones or regions, and scaled horizontally.
Aurora and AlloyDB keep the familiar MySQL and PostgreSQL interfaces but swap in a distributed storage layer, giving faster failover, more replicas and better throughput. Spanner (and AWS’s newer Aurora DSQL) go further with horizontally scalable, strongly consistent SQL across regions. They’re the right answer for global financial ledgers, inventory and gaming backends, and overkill for most line-of-business apps.
Amazon Aurora Soon
MySQL- and PostgreSQL-compatible engines on a distributed storage layer with six copies across three AZs. Up to 15 low-latency replicas, Global Database for cross-region reads and failover, and Aurora Serverless v2 for fine-grained autoscaling. Aurora DSQL adds active-active multi-region.
The Hyperscale tier separates compute and log/page storage for databases up to 128 TB, fast backups and restores, and up to 30 named replicas. Cosmos DB for PostgreSQL (Citus) covers distributed PostgreSQL.
Spanner Soon
Globally distributed relational database with strong consistency and up to 99.999% availability in multi-region configurations. Scales horizontally without sharding; supports GoogleSQL and a PostgreSQL interface.
AlloyDB for PostgreSQL
PostgreSQL-compatible database with a disaggregated storage layer and a columnar engine for fast analytical queries on transactional data. Google’s answer to Aurora PostgreSQL.
NoSQL databases
NoSQL databases trade relational flexibility for predictable performance at massive scale. You model data around access patterns (“get all orders for customer X, newest first”) rather than normalised tables, and in return reads and writes stay fast whether you have a thousand items or a hundred billion.
The flavours:
- Key-value and document (DynamoDB, Cosmos DB, Firestore). JSON-like items with flexible schemas. Great for user profiles, carts, catalogues, IoT state and mobile backends.
- Wide-column (Bigtable, Cassandra API on Cosmos DB, Amazon Keyspaces). Huge sparse tables keyed by row, ideal for time series and very high write rates.
The hardest part of NoSQL is design, not operations. DynamoDB single-table design and Cosmos DB partition keys reward careful up-front modelling and punish guesswork with hot partitions and throttling. If you can’t list your access patterns yet, a relational database is probably the safer start.
Amazon DynamoDB Soon
Serverless key-value and document database with single-digit-millisecond latency at any scale. On-demand or provisioned capacity, global tables for multi-region active-active, streams for change data capture, and DAX for microsecond caching.
Globally distributed multi-model database with turnkey multi-region writes and five consistency levels. APIs for NoSQL, MongoDB (including vCore), Cassandra, Gremlin and Table. Serverless or provisioned throughput billed in request units.
Firestore Soon
Serverless document database with real-time listeners, offline sync for mobile and web clients, and strong consistency. Firestore with MongoDB compatibility lets existing MongoDB drivers connect.
Bigtable Soon
Wide-column NoSQL database for very large, high-throughput workloads (time series, IoT, ad tech, ML features). HBase API compatible, with replication across clusters and regions.
In-memory caching
A cache sits in front of a database (or a slow API) and serves repeated reads from memory in well under a millisecond. It’s also the standard home for session state, rate-limit counters, leaderboards and pub/sub signalling.
Two industry shifts are worth knowing. After Redis changed its licence in 2024, AWS and Google adopted Valkey, the open-source fork, as their default cache engine. And Microsoft is retiring Azure Cache for Redis in favour of Azure Managed Redis.
Amazon ElastiCache Soon
Managed Valkey, Redis OSS and Memcached, in node-based clusters or ElastiCache Serverless that scales automatically. Valkey is the lower-cost default for new clusters. Amazon MemoryDB offers a durable Redis-compatible primary database.
Microsoft is retiring Azure Cache for Redis (Basic/Standard/Premium by September 2028, Enterprise tiers by March 2027) in favour of Azure Managed Redis, built on Redis Enterprise. New deployments should use Azure Managed Redis.
Memorystore Soon
Managed Valkey, Redis and Memcached. Memorystore for Valkey and Redis Cluster scale out with zero-downtime resharding and high availability across zones.
Azure Cache for Redis is closed to new customers, and from 1 October 2026 existing customers can’t create new instances either. Basic, Standard and Premium retire on 30 September 2028, and the Enterprise tiers in March 2027. Plan the move to Azure Managed Redis now.
Comparing the providers
- AWS has the broadest catalogue: every major engine on RDS, Aurora, DynamoDB, plus specialist services (Neptune for graphs, Timestream for time series, DocumentDB, Keyspaces). If you need something specific, it’s probably there.
- Azure is the natural home for SQL Server, and Cosmos DB is the most flexible globally distributed NoSQL service, with multiple APIs and tunable consistency.
- Google Cloud leads on distributed SQL with Spanner, and AlloyDB is a strong PostgreSQL option. BigQuery also blurs the line between database and warehouse (see the analytics post).
Common pitfalls
- Connection storms. Serverless functions and autoscaled containers can open thousands of connections and exhaust a relational database. Use connection pooling (RDS Proxy, PgBouncer, built-in poolers).
- Over-provisioning for peaks. Use serverless or autoscaling tiers for spiky workloads, and stop non-production databases outside working hours where the service allows it.
- Single-AZ production. It’s cheaper until the zone has a bad day. Enable zone-redundant HA for anything that matters.
- Choosing NoSQL for flexibility. “Schemaless” doesn’t mean “no design”. Unclear access patterns plus NoSQL usually means expensive scans later.
- Public endpoints. Put databases on private networking and disable public access. See the networking post on private endpoints.
Conclusion
Default to a managed PostgreSQL (or SQL Server on Azure) for business applications. Reach for Aurora, AlloyDB or Hyperscale when a single node strains, Spanner when you truly need global strongly consistent writes, NoSQL when you know your access patterns and need massive scale, and a cache when reads are hot and repeated. A useful next step: for each database you run, write down its recovery time and recovery point objectives, then check whether the current configuration actually meets them. The side-by-side list is in the Databases comparison.