Google Cloud SQL: Fully Managed MySQL, PostgreSQL, and SQL Server on GCP
Running a relational database involves more operational work than running the database itself: OS patching, storage expansion, backup scheduling, replication setup, failover testing, SSL certificate rotation, performance monitoring. Cloud SQL handles all of it. You choose the engine, size, and configuration; Google handles the rest.
This guide covers the three supported engines, how high availability works, read replicas, the Cloud SQL Proxy connection model, and IAM-based authentication.
Supported Engines and Their Trade-offs
┌──────────────┬─────────────────────────────────────────────────────────────┐│ MySQL │ Most widely used open-source RDBMS. Excellent for web apps, ││ │ content management, e-commerce backends. Versions 5.7, 8.0. │├──────────────┼─────────────────────────────────────────────────────────────┤│ PostgreSQL │ Feature-rich with strong standards compliance. Supports ││ │ JSONB, PostGIS, full-text search, window functions, CTEs, ││ │ and custom types. Versions 12-16. Best for complex queries ││ │ and analytical workloads that don't warrant BigQuery. │├──────────────┼─────────────────────────────────────────────────────────────┤│ SQL Server │ For .NET applications, legacy enterprise software, and ││ │ anything tightly integrated with the Microsoft ecosystem. ││ │ Versions 2017, 2019, 2022 (Standard, Enterprise, Web). │└──────────────┴─────────────────────────────────────────────────────────────┘High Availability: How Failover Works
A Cloud SQL HA instance runs a primary instance and a standby instance in a different zone within the same region. The standby is not a regular replica — it does not serve reads. It uses synchronous replication to maintain an identical copy of the primary’s data.
Region: us-central1┌─────────────────────────────────────────────────────────────────┐│ ││ Zone: us-central1-a Zone: us-central1-f ││ ┌────────────────────┐ ┌────────────────────┐ ││ │ Primary instance │ ────────► │ Standby instance │ ││ │ (serves traffic) │ sync │ (no traffic) │ ││ └────────────────────┘ repl. └────────────────────┘ ││ │ │ ││ pd-ssd (zone a) pd-ssd (zone f) ││ ││ On primary failure: ││ ├── Cloud SQL detects failure (30-60 seconds) ││ ├── Standby promoted to primary ││ ├── DNS updated to point to new primary ││ └── Applications reconnect (connection pooling handles this) │└─────────────────────────────────────────────────────────────────┘Enable HA at creation time or toggle it on an existing instance:
gcloud sql instances create prod-db \ --database-version=POSTGRES_15 \ --tier=db-n1-standard-4 \ --region=us-central1 \ --availability-type=REGIONAL
# Or enable HA on an existing instancegcloud sql instances patch prod-db \ --availability-type=REGIONALRead Replicas: Scaling Read Throughput
Read replicas use asynchronous replication from the primary and serve SELECT queries, offloading read traffic. Unlike the HA standby, replicas are fully accessible for reads.
Use cases for read replicas:
- Reporting and analytics queries that would slow down the production primary
- Search indexing jobs that scan large tables
- Geographic distribution — a replica in another region reduces read latency for users in that region
# Create a read replica in another regiongcloud sql instances create prod-db-replica \ --master-instance-name=prod-db \ --region=europe-west1Read replicas can themselves be promoted to primary if you need to migrate to a different region or recover from a primary failure outside of the HA failover path. Promotion permanently breaks the replication link.
Connecting Securely: Cloud SQL Proxy vs Direct Connection
Exposing your database to the internet is inadvisable. Cloud SQL Proxy is the standard secure connection method. It runs as a local process, authenticates using your GCP service account or user credentials, and establishes an encrypted tunnel to the database. Your application connects to localhost.
Application │ │ connects to 127.0.0.1:5432 ▼Cloud SQL Proxy (local process) │ │ IAM-authenticated, TLS-encrypted tunnel ▼Cloud SQL Instance (private IP in VPC, or public IP with whitelist)Running the proxy:
# Download and run the proxy (Cloud SQL Auth Proxy v2)./cloud-sql-proxy my-project:us-central1:prod-db \ --port=5432 \ --auto-iam-authnThen connect your application to 127.0.0.1:5432 using normal PostgreSQL or MySQL credentials.
For GKE, the proxy runs as a sidecar container in the same pod:
containers: - name: myapp image: gcr.io/my-project/myapp env: - name: DB_HOST value: "127.0.0.1" - name: cloud-sql-proxy image: gcr.io/cloud-sql-connectors/cloud-sql-proxy:2 args: - "--port=5432" - "my-project:us-central1:prod-db"IAM Database Authentication
Cloud SQL for PostgreSQL and MySQL supports IAM authentication, which lets database users authenticate using their GCP identity rather than a static password. This eliminates password rotation overhead and integrates database access with your GCP IAM policies.
# Grant IAM user database accessgcloud sql users create \ myuser@myproject.iam.gserviceaccount.com \ --instance=prod-db \ --type=CLOUD_IAM_SERVICE_ACCOUNT
# Connect using IAM auth (proxy handles token exchange automatically)./cloud-sql-proxy prod-db --auto-iam-authn &psql "host=127.0.0.1 user=myuser@myproject.iam dbname=mydb"The service account authenticates to GCP with its key or Workload Identity (for GKE), and Cloud SQL Proxy exchanges that for a short-lived database token. No stored passwords.
Automated Backups and Point-in-Time Recovery
Cloud SQL takes automated backups on your configured schedule. Point-in-time recovery (PITR) uses binary log (MySQL) or WAL (PostgreSQL) to restore to any second within your retention window — not just to the most recent backup.
# Enable PITR and configure backup schedulegcloud sql instances patch prod-db \ --backup-start-time=02:00 \ --retained-backups-count=14 \ --retained-transaction-log-days=7
# Restore to a specific point in timegcloud sql instances restore-backup prod-db \ --restore-instance=prod-db-restored \ --backup-instance=prod-db \ --restore-source-type=PITR \ --restore-timestamp=2025-03-15T14:30:00.000ZPITR restoration creates a new instance. You validate data there before cutting over traffic, which prevents accidentally overwriting a production instance.
Choosing the Right Tier
Cloud SQL tiers map to machine types with predefined CPU and memory combinations:
- Shared-core tiers (db-f1-micro, db-g1-small): development and testing only
- Standard tiers (db-n1-standard-N): balanced CPU/RAM ratio for typical workloads
- High-memory tiers (db-n1-highmem-N): more RAM per vCPU for query-heavy or caching workloads
Storage scales from 10 GB to 64 TB and grows automatically when you enable the storage auto-increase setting. IOPS scale with storage size on pd-ssd.
Real-World Pattern: Web Application Database
A typical three-tier application uses Cloud SQL as its persistence layer:
Cloud Run service (stateless API) │ │ Cloud SQL Auth Proxy (sidecar) ▼Cloud SQL PostgreSQL 15 (us-central1) ├── HA standby (us-central1-f) ├── Read replica (europe-west1) ─── reporting service ├── Automated backup: 02:00 UTC, 14-day retention └── PITR: 7-day log retentionThe Cloud Run service uses Workload Identity to authenticate to the proxy, which connects to the Cloud SQL instance. No passwords stored in environment variables or secrets — just IAM roles.
Summary
Cloud SQL removes the operational overhead of running MySQL, PostgreSQL, or SQL Server yourself. High availability with a synchronous standby in another zone reduces outage risk. Read replicas distribute query load. Cloud SQL Proxy secures connections without VPN or IP whitelisting. IAM authentication eliminates static database passwords. Point-in-time recovery provides fine-grained restoration for accidental data loss. The combination makes Cloud SQL suitable for production workloads that need a relational database without a dedicated DBA team.