Google Cloud SQL: HA, Replicas, Auth Proxy & Backups

Google Cloud SQL

Cloud SQL is Google Cloud's fully managed relational database service for PostgreSQL, MySQL, and SQL Server. Google handles provisioning, replication, patching, backups, and failover; you work with a standard database engine through the same drivers and ORMs you'd use anywhere else. It integrates tightly with Cloud Run, GKE, App Engine, and Compute Engine, and with Google Cloud IAM for authentication.

Cloud SQL is the default relational choice on Google Cloud. For heavier PostgreSQL workloads, AlloyDB offers higher performance, and for globally distributed, horizontally scalable relational data, Cloud Spanner is the specialist. Cloud SQL is the AWS equivalent of RDS.

TL;DR

Managed PostgreSQL, MySQL, and SQL Server with automated backups, patching, and HA.
Enterprise Plus edition adds faster machines, data cache, near-zero-downtime maintenance, and 99.99% SLA.
High availability uses a standby in another zone of the region with automatic failover.
Read replicas scale reads (including cross-region replicas for DR).
Connect securely with private IP, the Cloud SQL Auth Proxy, or language connectors, plus IAM database authentication.
Enable point-in-time recovery and deletion protection for production.

Quick Example

Create a private, highly available PostgreSQL instance with gcloud:

Connect from a Cloud Run service with the Node.js connector and IAM authentication — no passwords, no IP allowlists:

Core Concepts

Editions and Machine Types

Shared-core tiers (db-f1-micro, db-g1-small) are fine for development but not for production.

High Availability

A regional (HA) instance keeps a standby in a different zone, replicating synchronously to regional persistent disks. If the primary fails, Cloud SQL fails over to the standby and keeps the same connection name and IP. The standby doesn't serve reads.

Replicas

Read replicas handle read traffic and reporting; replication is asynchronous, so expect some lag.
Cross-region replicas support disaster recovery; you can promote one, and newer versions support planned switchover and advanced DR workflows.
Cascading replicas replicate from another replica to reduce load on the primary.

See Database Replication.

Backups and Recovery

Automated daily backups plus transaction logs enable point-in-time recovery to a specific second in the retention window. On-demand backups persist until deleted. Restores and clones create new instances or overwrite a target instance; test both paths. See Database Backups.

Connectivity

IAM database authentication lets users and service accounts log in with short-lived OAuth tokens instead of passwords.

Configuration and Observability

Database flags adjust engine settings (some require restarts). Query Insights shows top queries, wait events, and query plans; Cloud Monitoring tracks CPU, memory, disk, connections, and replication lag.

Best Practices

Use Private IP and Disable Public IP

Keep instances inside your VPC and connect through connectors or the Auth Proxy.

Prefer IAM Authentication

Service accounts with IAM auth remove static database passwords from configuration. Where passwords remain, store them in Secret Manager.

Enable HA, PITR, and Deletion Protection in Production

HA handles zone failures, PITR handles human errors, and deletion protection prevents catastrophic mistakes.

Pool Connections

Cloud Run and GKE can scale to many instances, each opening connections. Use application pools with sensible limits, or PgBouncer / managed connection pooling. See PostgreSQL Connection Pooling.

Set Maintenance Windows and Deny Periods

Choose low-traffic maintenance windows and deny periods around critical business events.

Watch Disk Growth

Enable automatic storage increase with a sensible limit — storage can grow automatically but never shrinks.

Common Mistakes

Public IP With 0.0.0.0/0 Authorized

Opening the instance to the internet invites brute-force attempts and data exposure.

Using Shared-Core Tiers in Production

Shared-core machines have no SLA and limited performance.

Treating Read Replicas as HA

Replicas are asynchronous and not automatic failover targets. Use a regional HA configuration for availability.

Unbounded Connections From Serverless

Hundreds of Cloud Run instances each opening many connections can exhaust max_connections. Cap instances and pool sizes.

Never Testing Restores

A backup you haven't restored is an assumption. Clone to a test instance regularly.

Comparison

FAQ

What is Google Cloud SQL?

A fully managed relational database service on Google Cloud for PostgreSQL, MySQL, and SQL Server that automates backups, replication, patching, and failover.

How do I connect to Cloud SQL securely?

Use private IP within your VPC together with the Cloud SQL language connectors or Auth Proxy, and authenticate with IAM database authentication where possible.

Cloud SQL or AlloyDB?

Cloud SQL is simpler and cheaper for typical workloads and supports three engines. AlloyDB is PostgreSQL-only and targets higher throughput, faster analytics on operational data, and more demanding availability needs.

Does Cloud SQL support point-in-time recovery?

Yes. With PITR enabled, you can restore to any point within the transaction log retention period, up to 7 days on Enterprise and 35 days on Enterprise Plus.