Cloud SQL
Cloud SQL is the managed relational database service for PostgreSQL, MySQL, and SQL Server. Google handles the OS, database installation, security patches, backups, replication, and failover. For most teams needing a relational database on Google Cloud, Cloud SQL is the right starting point.
High Availability
Primaryaccepts reads & writesStandbywarm standby · not servingHA mode creates a synchronous standby in a different zone. The primary writes to both instances before acknowledging a commit. If the primary becomes unavailable, the standby is promoted automatically within about 60 seconds. For any production workload, HA is not optional — a single-node instance is a single point of failure.
Instance Sizing
Cloud SQL offers instances from shared-core for development up to 128 vCPUs and 864 GB RAM on the Enterprise Plus edition (Enterprise edition tops out at 96 vCPUs). Start with the smallest tier that handles baseline load, enable automatic storage increase, and scale up when monitoring shows sustained pressure.
Read Replicas
Asynchronous copies of the primary that serve read traffic. Multiple replicas can be placed in different regions. They are separate from the HA standby and are not failover targets.
Connections
Use the Cloud SQL Auth Proxy or language-specific Connector libraries. The Proxy handles identity verification and encrypted connections automatically, without managing credentials or certificates manually. Never expose Cloud SQL to a public IP in production. Use a connection pooler like pgBouncer (PostgreSQL) or ProxySQL (MySQL) in high-concurrency applications.
Backups and Recovery
Automated backups create daily snapshots retained up to 365 days. Point-in-time recovery uses binary logs or WAL to restore to any moment within the retention window. Enable PITR in production — it enables recovery from accidental deletions and misapplied migrations.
- No high availability for production instances.
- Connecting over public IP instead of using the Auth Proxy.
- Running analytical queries on the primary during peak transactional hours.
- Not enabling point-in-time recovery.
- Not sizing connection pools correctly — either exhausting limits or creating connection latency.
- Automatic storage increase disabled.
- Enable High Availability for every production instance.
- Enable Point-in-Time Recovery.
- Use the Auth Proxy or Connector libraries.
- Use a connection pooler for high-concurrency applications.
- Enable automatic storage increase.
- Direct analytical queries to a read replica.
- Test failover regularly.
Knowledge Check
What does Cloud SQL High Availability mode create?
- An asynchronous read replica in a second region that lowers read latency for geographically distant users
- A synchronous standby in a different zone that is promoted automatically if the primary fails
- A daily snapshot backup of the instance with a 365-day retention window
- A second primary instance that accepts writes simultaneously with the first
What is the relationship between read replicas and the HA standby in Cloud SQL?
- Read replicas and the HA standby are the same instance — failover routes read traffic to it
- Read replicas become failover targets if the primary and HA standby both fail
- Read replicas are separate from the HA standby and are not failover targets
- Read replicas are synchronous; the HA standby is asynchronous
What does the Cloud SQL Auth Proxy handle automatically?
- Connection pooling and query result caching to reduce load on the database instance
- Horizontal read scaling by automatically routing incoming queries across all of the available read replicas
- Identity verification and encrypted connections, without managing credentials or certificates manually
- Automatic failover to the HA standby instance if the primary becomes unavailable
What does Point-in-Time Recovery (PITR) enable?
- Creating a secondary instance in another region from the most recent daily backup snapshot
- Scaling the instance's CPU and RAM up or down without restarting the database
- Restoring the database to any moment within the retention window using binary logs or WAL
- Automatically replicating all writes to a standby instance in real time as they happen
Why should you use a connection pooler like pgBouncer with Cloud SQL?
- pgBouncer encrypts the database connections that the Cloud SQL Auth Proxy otherwise leaves unprotected as they travel over the wire
- Cloud SQL strictly requires a connection pooler to be deployed for all production workloads
- High-concurrency apps can exhaust connection limits — a pooler multiplexes many app connections through fewer database connections
- pgBouncer adds automatic failover logic that promotes a standby when the primary goes down
You got correct