AWS vs Google Cloud vs Azure databases: PostgreSQL compatibility, HA, and read scaling

October 26, 2026 · 10 min read

Compare RDS for PostgreSQL, Cloud SQL for PostgreSQL, and Azure Database for PostgreSQL by compatibility, standbys, read replicas, regional recovery, connection limits, and total cost. Learn when to expand the evaluation to Aurora or Spanner.

Compare RDS, Cloud SQL, and Azure Database for PostgreSQL on equal terms

An existing PostgreSQL order database is moving to the cloud. Transactions protect order and inventory updates, and one region handles most writes. Start by checking supported versions, extensions, and operating models for RDS for PostgreSQL, Cloud SQL for PostgreSQL, and Azure Database for PostgreSQL flexible server.

Candidate	Fix the deployment first	Key comparison
AWS: RDS for PostgreSQL	DB instance or DB cluster; Single-AZ or Multi-AZ	Multi-AZ names can describe different standby and read architectures
Google Cloud: Cloud SQL for PostgreSQL	Edition; zonal instance or regional HA	Plan HA standby, read replicas, and DR as separate roles
Azure: Database for PostgreSQL flexible server	Compute tier; no HA, same-zone HA, or zone-redundant HA	Same-zone HA does not establish zone-outage resilience

Validate compatibility using real SQL, extensions, connections, and maintenance

PostgreSQL support does not prove that the current application works unchanged. Inventory extensions, tasks requiring administrative privileges, collations, connectivity, major versions, and backup and restore procedures. Reproduce concurrent order updates and lock waits as well as representative queries.

Check required extensions and versions. Estimate replacement implementations and application changes for anything unsupported.
Measure reads, writes, and index maintenance using realistic volumes and skew. Connecting to an empty database does not complete migration validation.
Include maintenance interruptions, reconnection, and certificate and credential changes in operating procedures.

Separate HA standbys from replicas that scale reads

Deployment	Primary purpose	Relationship to reads
RDS Multi-AZ DB instance	Synchronous replication to another AZ and failover	The standby cannot serve reads; evaluate read replicas or other options separately
RDS Multi-AZ DB cluster	One writer and two readers in three AZs	Readers serve reads and are failover targets; this is distinct from Aurora
Cloud SQL regional HA	Improve continuity across different zones in one region	Plan HA and read replica deployments separately
Azure PostgreSQL zone-redundant HA	Fail over to a standby in another zone	The HA standby cannot serve reads

Asynchronous read replicas lag behind writes. Reading an order immediately after creation from a lagging replica can make it appear missing. Read that view from the writer or verify that the replica has reached the write position. More replicas alone do not resolve this behavior or update contention on the writer.

Design availability, regional DR, and accidental-deletion recovery separately

HA for an AZ or zone outage is different from disaster recovery after losing a region. First define the recovery time objective, RTO, and acceptable data-loss window, RPO. Asynchronous cross-region replication can leave writes unapplied. Normal replication lag is not a guarantee of disaster-time RPO.

Assume a 30-minute RTO: detection takes 4 minutes, the recovery decision 3, promotion 8, application cutover 5, and business validation 4. The total is 24 minutes, leaving 6 minutes of margin. This is an illustrative procedure budget, not product recovery performance. An 8-minute promotion does not make end-to-end recovery take 8 minutes.

Illustrative regional DR rehearsal budget in minutes: 24 total, leaving 6 against a 30-minute RTO

Detection: 4 min
Recovery decision: 3 min
Promotion: 8 min
Application cutover: 5 min
Business validation: 4 min

A mistaken DELETE or incorrect application update propagates successfully to replicas. Keep backups and point-in-time recovery separately; test restored-server authentication, connection changes, and reconciliation of valid writes made after the mistake. For DR, prevent the old regional writer from competing if it returns, and define fallback conditions after new writes begin.

Measure connection and write limits before broadening the database choice

Thirty application instances with two processes each and a pool limit of 15 can open 30 × 2 × 15 = 900 connections. Adding read replicas does not remove pools pointed at the writer. Measure the allocated connection budget separately from sustainable concurrent queries, and include deployment overlap.

Connection aggregation such as RDS Proxy is another candidate, subject to compatibility, session dependencies, and wait behavior. More available connections do not necessarily resolve CPU, I/O, or contention on one row. Inspect query plans and workload composition to establish the actual bottleneck.

New requirement	Broaden the evaluation	Validation still needed
Evaluate another architecture while retaining PostgreSQL compatibility	Include candidates such as Aurora PostgreSQL	Recheck versions, extensions, SQL, recovery, and cost
Measurements show one writer cannot meet required scale	Compare distributed SQL, sharding, and data-model changes	Key skew, transaction boundaries, update contention
Consider Spanner	Prototype against distributed transaction and placement requirements	Its PostgreSQL interface is not the PostgreSQL engine; validate SQL, extensions, and drivers

Make the decision using total cost and recovery tests

Include the writer, HA, readers, DR capacity, storage, I/O, backups, communication, connection proxies, and operations. Equal vCPU counts do not imply equal performance; compare configurations that meet targets under representative load. For less compatible options, include migration and exit work.

Validate required SQL, extensions, and transactions, then measure writer and reader behavior separately with representative data.
Test read-after-write behavior, connection bursts, and reconciliation after timeouts. Do not blindly resubmit an order with an unknown outcome as a new order.
Rehearse HA failover, regional DR, and accidental-deletion restoration separately. Measure time to business recovery and lost writes.
Record evidence for compatibility, normal load, recovery objectives, and total cost. Reevaluate when multiple-writer or regional requirements change.