Amazon RDS vs Cloud SQL for Postgres
How Amazon RDS and Google Cloud SQL compare for PostgreSQL: high availability, read replicas, backups, connectivity, the Aurora and AlloyDB tiers above them, pricing and operations.
Amazon RDS for PostgreSQL and Cloud SQL for PostgreSQL are the default managed Postgres services on AWS and Google Cloud. Both take care of installation, patching, backups and failover, and both run standard PostgreSQL, so application code and SQL carry over. The differences are in how high availability and replicas are set up, how the app connects, what sits above them for heavier workloads, and how each fits the rest of its cloud.
RDS vs Cloud SQL at a glance
High availability and replicas
RDS offers two Multi-AZ shapes, the first being a Multi-AZ instance keeps a synchronous standby in another availability zone that takes over on failure but does not serve reads, and a Multi-AZ DB cluster has a writer and two readable standbys in separate zones, with faster failover. Read replicas are added separately, in the same or another region.
Cloud SQL high availability makes an instance regional, with a standby in a second zone and synchronous replication to regional persistent disks, and the standby does not serve reads. Read replicas are separate instances, in-region or cross-region. Enterprise Plus adds a higher availability SLA, shorter planned maintenance downtime and a data cache for read-heavy workloads.
Backups and recovery
Both take automated daily backups and support point-in-time recovery from transaction logs. RDS keeps automated backups for up to 35 days and supports manual snapshots that persist until deleted, which can be copied across regions and accounts. Cloud SQL keeps a configurable number of automated backups, supports on-demand backups, and offers point-in-time recovery within the log retention window. Test a restore on both, since recovery time depends on database size and log volume.
Connectivity
Connectivity is the difference developers notice first, because an RDS instance lives in subnets of your VPC, and the app reaches it on port 5432 when security groups allow it. RDS Proxy pools connections for Lambda and other bursty clients.
Cloud SQL instances live in a Google-managed network, so private IP access uses private services access or Private Service Connect from your VPC, and the Cloud SQL Auth Proxy and language connectors create TLS connections authorized by IAM, which is also the usual way to connect from a laptop. Cloud Run has a built-in Cloud SQL connection.
Aurora vs AlloyDB
When standard Postgres instances reach their limits, each cloud has a Postgres-compatible tier above them. Aurora PostgreSQL uses a distributed storage layer replicated across three zones, with up to 15 readers and Aurora Serverless v2 for capacity that scales in fine-grained steps. AlloyDB adds a columnar engine for analytical queries and fast reads, with read pools and cross-region replication. Both cost more than the standard service at rest, and both keep standard Postgres drivers working. See Aurora vs RDS Postgres for the AWS side.
Pricing
Both bill for the instance's vCPU and memory per hour, storage per GB-month, backup storage beyond a free allowance, and network traffic out of the zone or region, and high availability roughly doubles instance cost. Compare a specific shape on the RDS pricing and Cloud SQL pricing pages, including reserved instances on AWS and committed use discounts on Google Cloud for steady workloads.
Same Postgres code on both with Encore
Encore combines an open source infrastructure SDK with a platform that provisions and deploys into your own AWS or GCP account. The database is declared in the application code, and which managed Postgres it becomes depends on the environment's cloud:
package notes
import (
"context"
"encore.dev/storage/sqldb"
)
// RDS for PostgreSQL on AWS, Cloud SQL for PostgreSQL on GCP,
// and a local Postgres under `encore run`.
var db = sqldb.NewDatabase("notes", sqldb.DatabaseConfig{
Migrations: "./migrations",
})
type Note struct {
ID int64
Body string
}
//encore:api public method=GET path=/notes/:id
func Get(ctx context.Context, id int64) (*Note, error) {
n := &Note{ID: id}
err := db.QueryRow(ctx, `SELECT body FROM notes WHERE id = $1`, id).Scan(&n.Body)
return n, err
}
On AWS, Encore provisions RDS for PostgreSQL in private storage subnets, by default on PostgreSQL 18.3 on db.m5.large with Multi-AZ and seven days of backups, with Aurora as an option, per the AWS infrastructure docs. On GCP it provisions Cloud SQL for PostgreSQL in private subnets with daily backups retained for seven days and point-in-time recovery, per the GCP infrastructure docs. Migrations in the migrations directory are applied on deploy, and on AWS each service gets its own database role. Existing instances can be imported rather than recreated, as described in Import an existing RDS or Aurora database.
encore run starts Postgres locally from the same declaration, and encore db shell notes --env=prod opens a psql session against a deployed environment.
Best fit: teams that want managed Postgres on AWS or GCP provisioned from the code that uses it, with the cloud chosen per environment.
How to choose
Pick the service in the cloud your application runs in, since latency, networking and IAM all favor keeping the database next to the compute. Within that choice, RDS gives you two Multi-AZ shapes and VPC-native networking, and Cloud SQL gives you IAM-based connections through the Auth Proxy and an Enterprise Plus edition for stricter availability targets. Plan the move to Aurora or AlloyDB when read scaling, storage growth or failover time outgrow the standard service.
Related guides
Frequently asked questions
What is the difference between Amazon RDS and Cloud SQL?
Both are managed relational databases that run PostgreSQL with automated backups, point-in-time recovery, a standby in another zone and read replicas. RDS supports more engines and sits inside your VPC, reached through security groups. Cloud SQL is reached over private IP or through the Cloud SQL Auth Proxy with IAM, and comes in Enterprise and Enterprise Plus editions. Each cloud has a higher tier above it: Aurora on AWS and AlloyDB on Google Cloud.
Is Cloud SQL cheaper than RDS?
Instance prices for comparable vCPU and memory are in the same range, and high availability roughly doubles the compute cost on both. Storage, backup storage beyond the free allowance, cross-zone and cross-region traffic and committed use or reserved instance discounts decide the difference for a specific workload.
How do I connect to Cloud SQL from my application?
From inside Google Cloud, use the instance's private IP in a VPC that has private services access, or the Cloud SQL Auth Proxy or language connectors, which handle TLS and IAM-based authorization. Cloud Run can connect through the built-in Cloud SQL connection. From outside, the Auth Proxy avoids opening the instance's public IP to the internet.
Can I use the same Postgres code on RDS and Cloud SQL with Encore?
Yes, the code is identical for both: you declare the database with sqldb.NewDatabase in Go or new SQLDatabase in TypeScript, and the Encore platform provisions RDS for PostgreSQL on AWS or Cloud SQL for PostgreSQL on GCP, in private subnets, and applies your migrations on deploy. encore run starts Postgres locally from the same declaration.
Deploy to your cloud on AWS and Google Cloud
without managing infrastructure
Encore lets developers and agents define application infrastructure directly in code, then automatically provisions it from local development to production in your AWS or GCP account.
