---
cuppy_hub: gcp
cuppy_path: reference/databases/cloud-sql.md
cuppy_section: docs
cuppy_doc: 530R-TFRT
cuppy_doc_uuid: b8060516-fae0-4bfe-a2eb-5fe42b7044ca
cuppy_permalink: https://cuppy.io/gcp/d/530R-TFRT
cuppy_version: 1
cuppy_updated: 2026-10-23T16:16:52.575Z
cuppy_canonical: https://cuppy.io/gcp/docs/reference/databases/cloud-sql
cuppy_mcp: https://cuppy.io/mcp
cuppy_body_sha256: 6a4c1e89a59fbf09191022db8451fbd74ec46e95e2206de5ba3ec21663ec8a38
# cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks.
---


# Cloud SQL

## 1. Three engines, two editions

Engines: **MySQL**, **PostgreSQL**, **SQL Server**.

**"Cloud SQL Enterprise Plus edition"** is named for PostgreSQL and MySQL. The difference the overview actually
states is about **downtime**, not raw performance: Enterprise Plus can achieve **"sub-second downtime"** during
maintenance.

## 2. The update categories, and the one that restarts the instance

System updates come in three kinds: **hardware**, **online**, and **maintenance**.

> "Maintenance updates" require an **"instance restart"** — which causes downtime.

Two things follow, and they belong in any migration plan rather than in an incident review:

1. **You can schedule it.** The overview says to "schedule maintenance to occur at a time that is the least
   disruptive". Set the window at creation; a default window is a production outage at an arbitrary hour.
2. **The edition changes the cost of the restart.** If the application cannot tolerate a restart-shaped gap,
   that is an Enterprise Plus argument, and it is the clearest one the overview makes.

## 3. High availability

The HA configuration uses **a standby VM in another zone**. So HA here is zone-level, within one region — the
same shape as a regional Persistent Disk (`reference/storage/persistent-disk-and-hyperdisk.md` §3) and **not**
cross-region. Cross-region needs read replicas or a different product
(`reference/databases/alloydb.md`, `reference/databases/spanner.md`).

## 4. Four ways to connect, in the order to prefer them

| Method | Use when |
|---|---|
| **private IP** | the default for anything inside Google Cloud. The instance is reachable only from the VPC network |
| **Cloud SQL Auth Proxy** | a client that cannot be in the VPC, or needs IAM-based connection authorisation without managing certificates |
| **IAM database authentication** | you want the *database user* to be an IAM principal, so there is no database password to hold |
| **public IP** | last resort. Reachable from the internet, with authorised networks as the only perimeter |

**Combine private IP with IAM database authentication** and the design has no database credential at all — the
connection is authorised by the workload's own identity. That is the shape
`patterns/cloud-run-to-cloud-sql-with-iam.md` builds, and it is the single biggest security improvement
available when a self-managed database moves to Cloud SQL.

## 5. An absence, recorded

**The overview states no version end-of-support information.** Database major-version retirement is a real
and dated thing on every managed-database service, and it is one of the highest-value facts a migration plan
can carry. It is not on this page, so it is not stated here: read the engine-specific version-policy page
before planning a move onto a particular major version.

Next: `reference/databases/errors.md`, `guides/databases/connect-to-cloud-sql-with-iam-auth.md`, and
`guides/parity/databases.md` for RDS/Aurora and Azure Database for PostgreSQL/MySQL and Azure SQL.


---
<!-- cuppy -->
You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 91 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/gcp/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.
<!-- /cuppy -->