What Is Cloud SQL?
Cloud SQL is Google Cloud's fully managed relational database service, supporting MySQL, PostgreSQL, and SQL Server engines. Google handles OS patching, database version upgrades, storage capacity expansion, and backup scheduling, so engineering teams focus on schema design and query performance instead of server maintenance. Applications on Compute Engine, GKE, App Engine, or Cloud Run connect to a Cloud SQL instance over a private IP or through the Cloud SQL Auth Proxy, which handles encrypted, IAM-authorized connections without managing SSL certificates manually.
Cricket analogy: Just as the BCCI ground staff at the Wankhede Stadium prepare and maintain the pitch so Rohit Sharma's team only has to worry about batting and bowling, Cloud SQL maintains the underlying server so developers only worry about queries.
Instance Types, Storage, and Connectivity
A Cloud SQL instance is defined by its machine type (vCPUs and memory), storage type (SSD or HDD), and storage capacity, which can be configured to auto-resize as data grows so write operations never fail due to a full disk. Instances can be exposed via a public IP protected by authorized networks, or more securely via a private IP inside a VPC, reachable only from resources in that network or peered networks. The Cloud SQL Auth Proxy is the recommended connection method because it wraps the connection in TLS and enforces IAM database authentication without requiring the application to manage certificate files directly.
Cricket analogy: Choosing between public and private IP is like choosing between an open trial where any club scout can watch a net session versus a closed, invite-only nets session for the Indian team ahead of a World Cup, restricted to team staff only.
High Availability, Read Replicas, and Backups
Enabling high availability creates a standby instance in a different zone within the same region, with data replicated synchronously; if the primary zone fails, Cloud SQL automatically fails over to the standby, typically within a minute or two. Read replicas, by contrast, use asynchronous replication and are used to scale read-heavy workloads or run analytics queries without impacting the primary, and can even be promoted to a standalone instance if needed. Automated backups run daily during a configurable maintenance window, and enabling binary logging (MySQL) or write-ahead log archiving (PostgreSQL) allows point-in-time recovery to any second within the retention period, not just to the last daily snapshot.
Cricket analogy: HA failover is like a team having Rishabh Pant ready as backup wicketkeeper so if MS Dhoni gets injured mid-match, the team barely misses a beat, while a read replica is like a net bowler who trains separately and only steps in for a specific role.
# Create a Cloud SQL PostgreSQL instance with HA and auto-resizing storage
gcloud sql instances create orders-db \
--database-version=POSTGRES_15 \
--tier=db-custom-2-7680 \
--region=us-central1 \
--availability-type=REGIONAL \
--storage-auto-increase \
--backup-start-time=02:00 \
--enable-point-in-time-recovery
# Connect locally using the Cloud SQL Auth Proxy
./cloud-sql-proxy --port 5432 my-project:us-central1:orders-db &
psql "host=127.0.0.1 port=5432 dbname=orders user=app_user"Cloud SQL supports IAM database authentication for MySQL and PostgreSQL, letting you grant a service account the cloudsql.instances.connect role instead of managing long-lived database passwords, which pairs naturally with the Cloud SQL Auth Proxy.
Exposing a Cloud SQL instance on a public IP without tightly scoped authorized networks is a common misconfiguration; prefer private IP plus the Auth Proxy, and if a public IP is unavoidable, restrict authorized networks to specific CIDR ranges rather than 0.0.0.0/0.
- Cloud SQL is a fully managed service for MySQL, PostgreSQL, and SQL Server that handles patching, upgrades, and backups.
- Instances are sized by machine type and storage, with storage able to auto-increase as data grows.
- The Cloud SQL Auth Proxy provides encrypted, IAM-authorized connections without manual certificate management.
- High availability uses synchronous replication to a standby in another zone with automatic failover.
- Read replicas use asynchronous replication to scale read traffic and can be promoted to standalone instances.
- Automated daily backups combined with binary logging or WAL archiving enable point-in-time recovery.
- Private IP is the recommended network configuration; public IP should always be paired with restricted authorized networks.
Practice what you learned
1. What replication method does Cloud SQL high availability (regional) use between the primary and standby instance?
2. Which connection method wraps Cloud SQL connections in TLS and supports IAM database authentication without manual certificate handling?
3. What is required, beyond daily automated backups, to enable point-in-time recovery to an arbitrary second?
4. What is the primary purpose of a Cloud SQL read replica?
5. Why is exposing a Cloud SQL instance with authorized networks set to 0.0.0.0/0 considered risky?
Was this page helpful?
You May Also Like
Firestore and Bigtable Basics
A comparison of Google Cloud's two flagship NoSQL databases: Firestore for flexible document data and Bigtable for massive-scale wide-column workloads.
IAM in GCP
How Google Cloud's Identity and Access Management system controls who can do what on which resources, using roles, policies, and the principle of least privilege.
Service Accounts Explained
How GCP service accounts give identity to workloads instead of humans, and best practices for keys, impersonation, and workload identity.