Fully managed MySQL, PostgreSQL, and SQL Server. Regional, up to a few dozen TB, automatic backups, failover replicas, read replicas. This is the default relational answer for standard OLTP web apps (CMS, eCommerce, web frameworks).
The real trade-off is build your own vs use a managed service: you could run a SQL Server image on a Compute Engine VM, but Cloud SQL applies patches and updates for you and provides HA, backups, and replicas out of the box.
You could run your own database on a Compute Engine VM (left), but Google Cloud offers managed storage services instead (right) - Cloud SQL is the managed relational option among them.⚠GotchaCloud SQL does not shard writes
Cloud SQL scales UP (bigger instance) and out only with read replicas - it does NOT shard writes across regions. If the question says "global", "horizontal write scaling", or "strong consistency at scale", that's Spanner, not Cloud SQL.
Patches and updates are applied automatically. But you still administer database users yourself, with the native authentication tools that ship with MySQL / PostgreSQL / SQL Server.
Many clients connect to it: Cloud Shell (gcloud sql), App Engine, and Google Workspace scripts, plus external tools using standard drivers - SQL Workbench, Toad, and any app using standard MySQL drivers.
Supported engine versions: MySQL 5.6, 5.7, 8.0 - PostgreSQL 9.6, 10, 11, 12, 13, 14, 15 - SQL Server 2017 or 2019 (Web, Express, Standard, Enterprise).
Scaling up (a bigger machine) requires a restart; scaling out with read replicas does not. If you need horizontal write scalability, that is Spanner, not Cloud SQL.
A regional HA configuration spans two zones. The primary instance (Zone A) writes to a regional persistent disk that is synchronously replicated to both zones’ disks (01 and 02) before a transaction commits. Clients reach the primary through a single IP address; on a zone or instance failure the disk reattaches to the standby (Zone B), it becomes the new primary, and the IP address reroutes to it - a failover (dotted path).⚠GotchaSynchronous replication is what makes failover safe
Writes are only reported committed after they land on both zones' persistent disks. That is why a failover loses no committed data - the standby's disk is already current. HA is regional (two zones), not global.
The connection type you pick determines how secure, performant, and automated the link is.
Same project and region → Private IP, the most secure and performant path (traffic never touches the public internet). From another region/project or outside Google Cloud, prefer the Cloud SQL Auth Proxy (handles auth, encryption, and key rotation); use manual SSL only if you need to control the certificates yourself, or authorized networks (unencrypted, authorize a specific IP) if you cannot use SSL.?DECISIONWhich connection type?
App in the same project and region→Private IP - most performant + secure, never on the public internet
Another region/project, or outside Google Cloud→Cloud SQL Auth Proxy - handles auth, encryption, key rotation for you
Need to control the SSL certificates yourself→Manual SSL - you generate and rotate certs
Cannot use SSL→Authorized networks - unencrypted, authorize a specific IP over the external IP
⚠GotchaSame-region Private IP is a recommendation, not a requirement
Connecting to the Private IP from VMs in the same region is a performance recommendation - not a hard requirement. You can still reach the instance from other regions; it just won't be as fast.
The proxy is a small binary you run on the client VM. The app connects to a local address and the proxy does the encryption and authentication for it - so the app config only ever names a localhost address.
Two ways in, both encrypted. The Wordpress-proxy instance runs the proxy locally: the app connects to 127.0.0.1, and the proxy relays over the external IP to Cloud SQL (orange). The Wordpress-private-ip instance skips the proxy and reaches Cloud SQL directly over the internal/private IP (green). Same project and VPC either way.CommandsStarting the Auth Proxy on a VM
# download the proxy binary and make it executable
The app then uses 127.0.0.1 as its database host - not the instance IP.
⚠GotchaThe proxy needs the instance connection name, and it only exists once running
The proxy is keyed by the instance connection name (project:region:instance), not an IP. That value does not appear until the instance finishes creating and shows a green check, so the proxy cannot start until the instance is running.
⚠GotchaPrivate IP is enabled at create time via VPC peering
Choosing Private IP connectivity prompts you to enable the Service Networking API and then Allocate and Connect a peered range for the VPC - this allocation can take three to five minutes. Once done, a VM in that VPC connects straight to the instance's private IP, with no proxy.
Cloud SQL is the answer for relational, non-analytical data that does not need global scale or five-nines availability.
Follow the branches from Start: the green path (not in-memory → relational → not analytics → not five-nines availability) lands on Cloud SQL. Choose Spanner instead when you do need 99.999% availability or global scale, BigQuery for analytics, Memorystore for an in-memory store, and Bigtable/Firestore for non-relational data.
