- Cloud SQL runs MySQL, PostgreSQL or SQL Server on a Google-managed virtual machine with network storage, and handles backups, failover, patching, monitoring and logging.
- Two editions: Enterprise (99.95% SLA excluding maintenance) and Enterprise Plus (99.99% SLA including maintenance, sub-second maintenance downtime, data cache, 35-day point-in-time recovery).
- You pay per vCPU, per GiB of memory and per GiB of provisioned storage, plus a per-core licence for SQL Server; high availability doubles the instance cost.
- Choose Cloud SQL for standard MySQL, PostgreSQL or SQL Server workloads in one region; look at AlloyDB for heavier PostgreSQL work and Spanner for global scale.
What is Google Cloud SQL?
Cloud SQL is Google's fully managed relational database service for MySQL, PostgreSQL and SQL Server. Google describes it as a cloud-based alternative to running those databases yourself, aimed at teams who want to spend less time managing a database and more time using it. It is the Google Cloud counterpart of Amazon RDS and of Azure's managed MySQL, PostgreSQL and SQL Database services.
Under the hood, each Cloud SQL instance is a virtual machine running the database engine plus Google's service agents for logging and monitoring. The data sits on a network-attached persistent disk, and a static IP address in front of the VM keeps the connection address stable for the life of the instance. If you enable high availability, a standby VM runs in a second zone.
Cloud SQL handles backups, high availability and failover, network connectivity, export and import, maintenance and updates, monitoring and logging. It is not a database administration tool: you still create schemas, tune queries and manage users with clients such as pgAdmin, MySQL Workbench or SSMS. Because it is the engine you already know, existing SQL, drivers and tools carry over, with a few restrictions on superuser-level features described in the engine guides.
Cloud SQL database engines and versions
Cloud SQL supports three engines, each with several major versions. Google keeps minor versions patched automatically. When a major version reaches end of life in its community, Cloud SQL enrols it in extended support for three years, which is charged extra, and then deprecates it.
| Engine | Major versions supported | Enterprise Plus versions | Maintenance downtime (Enterprise edition) |
|---|---|---|---|
| MySQL | 5.6, 5.7, 8.0, 8.4 (default), 9.7 | 8.0, 8.4, 9.7 | Under 60 seconds |
| PostgreSQL | 9.6, 10, 11, 12, 13, 14, 15, 16, 17, 18 (default) | 12 to 18 | Under 30 seconds |
| SQL Server | 2017, 2019, 2022 and 2025 (Standard, Enterprise, Express; Web up to 2022) | 2019, 2022 and 2025 Enterprise | Under 120 seconds |
Google Cloud SQL for SQL Server
SQL Server instances add a licence charged per vCPU, and Cloud SQL does not accept licences you already own. Enterprise Plus for SQL Server offers N2 and memory-optimised N2 machines. If you are weighing SQL Server across clouds, see Azure SQL vs Google Cloud SQL.
Cloud SQL editions: Enterprise vs Enterprise Plus
Since July 2023, every Cloud SQL instance belongs to one of two editions. Google calls editions a tier-based pricing model: Enterprise provides the core capabilities, and Enterprise Plus adds performance, availability and observability features at a higher vCPU and memory rate. You can mix editions in one project and move an instance between them with an in-place upgrade.
| Feature | Enterprise | Enterprise Plus |
|---|---|---|
| Availability SLA | 99.95%, excluding maintenance | 99.99%, including maintenance |
| Machine series | Shared core, general purpose dedicated core, N4 | N2, C4A, C4 |
| Largest machine | Up to 96 vCPU and 624 GB RAM (dedicated core) | Up to 128 vCPU and 864 GB RAM (N2) |
| Maintenance downtime | Under 30 to 120 seconds depending on engine | Under 1 second |
| Point-in-time recovery log retention | Up to 7 days | Up to 35 days |
| Data cache (local SSD) | No | Yes |
| Read pools, managed connection pooling, advanced DR | No | Yes |
| Query insights retention | 7 days | 30 days |
High availability, backups and read replicas
High availability. An HA (regional) instance has a primary and a standby in two zones of the same region. Writes are synchronously replicated to disks in both zones before a transaction commits, and if the primary or its zone fails, Cloud SQL fails over to the standby. Google says to expect the instance to be unavailable for about sixty seconds during a failover; applications reconnect with the same connection string. HA costs twice as much as a standalone instance.
Backups and recovery. Cloud SQL takes automated backups on a schedule and on-demand backups whenever you ask. Backups are incremental after the first, and you can choose between standard backups stored in your project and enhanced backups managed by Google's Backup and DR service. Point-in-time recovery uses transaction logs, retained for up to 7 days on Enterprise and up to 35 days on Enterprise Plus. You can also take a final backup when deleting an instance.
Read replicas. Cloud SQL supports in-region, cross-region and cascading read replicas. Replicas are read-only, are billed like stand-alone instances, and do not provide failover by themselves; a replica can be promoted to a primary for disaster recovery or migration. Google recommends ten or fewer direct replicas per primary.
Connecting to Cloud SQL and the Cloud SQL Auth Proxy
An instance can have a public IP address, a private IP address on a VPC network, or both. Google recommends private IP unless you need access from the internet. With a public IP you either list authorised networks or use a Cloud SQL connector.
The Cloud SQL Auth Proxy is a small client you run next to your application. It uses IAM permissions to decide who can connect, encrypts traffic with TLS 1.3, and refreshes short-lived certificates for you, so you do not manage SSL certificates or authorised IP lists. It needs outbound access on ports 443 and 3307 and does not pool connections. For Java, Python and Go, Google recommends its language connectors instead. Cloud Run and App Engine use an embedded proxy automatically when they connect over a public IP address. For private IP connections, Google's general recommendation is a direct connection with SSL enforced.
How to set up a Cloud SQL instance
Google's quickstarts describe the minimum path in the Google Cloud console. This is a summary of the documented steps, not a walkthrough we have performed:
- Select or create a Google Cloud project and make sure billing is enabled. You need the Cloud SQL Admin role.
- Open the Cloud SQL Instances page, click Create instance, choose New instance, then choose MySQL, PostgreSQL or SQL Server.
- Enter an instance ID and a password for the default user (
postgresfor PostgreSQL,rootfor MySQL), pick the edition, region and machine type, then click Create instance. The quickstart default includes a public IP address. - Copy the instance connection name from the Overview page; it has the form
projectID:region:instanceID. - Start the Cloud SQL Auth Proxy with that connection name, then connect your usual client (psql, the mysql client or a GUI such as DBeaver) to
127.0.0.1on the engine's port.
A project can hold up to 1,000 instances on the current network architecture, and read replicas count towards that limit. When you are finished experimenting, delete the instance to stop charges.
When to choose Cloud SQL, and the alternatives
Choose Cloud SQL when you want a standard MySQL, PostgreSQL or SQL Server database in one Google Cloud region with backups, patching and optional HA handled for you. It suits web applications, internal systems, SaaS back ends and lift-and-shift migrations where engine compatibility matters more than extreme scale.
Its limits are those of a single-primary database: writes go to one instance, storage tops out at 64 TB per instance, you cannot install your own PostgreSQL extensions or MySQL plugins, and features that need full superuser rights are unavailable. The Enterprise edition has short maintenance restarts, and HA doubles the cost.
Alternatives on Google Cloud: AlloyDB for PostgreSQL workloads that need more throughput, read pools or analytics on live data; Spanner when you need horizontal write scaling or multi-region consistency; and the wider options in Google Cloud database services compared. Across clouds, see AWS RDS vs Google Cloud SQL and Google Cloud SQL vs AlloyDB.
Pricing
Prices from the provider's official pricing pages, checked 8 October 2026, region Iowa (us-central1), in USD, excluding tax. List prices only; discounts, commitments and your actual usage change the bill.
Cloud SQL has no flat plans. The main on-demand rates are below; the Cloud SQL pricing guide covers egress, licences, committed use discounts and four worked monthly estimates. Google's free features page offers a 30-day Cloud SQL free trial instance, and new Google Cloud customers get 300 USD in credits.
| Item | Enterprise | Enterprise Plus (N2) |
|---|---|---|
| vCPU | 0.0413 per hour | 0.0537 per hour |
| Memory | 0.007 per GiB-hour | 0.0091 per GiB-hour |
| HA vCPU | 0.0826 per hour | 0.1074 per hour |
| SSD storage (single zone) | 0.000232877 per GiB-hour | 0.000232877 per GiB-hour |
| Smallest shared-core machine (db-f1-micro) | 0.0105 per hour | Not offered |
| SQL Server Standard licence | 0.13 per core hour (4-core minimum) | 0.13 per core hour (4-core minimum) |
Frequently asked questions
What is Cloud SQL used for?
Cloud SQL hosts relational databases for applications running on Google Cloud or elsewhere: MySQL, PostgreSQL or SQL Server, with Google handling backups, failover, patching and monitoring. Google notes that many applications on Compute Engine, App Engine and other Google Cloud services use it for database storage.
Which databases does GCP Cloud SQL support?
Three engines: MySQL (5.6 to 9.7), PostgreSQL (9.6 to 18) and SQL Server (2017 to 2025). End-of-life versions remain available under paid extended support for three years before deprecation.
Is Cloud SQL the same as BigQuery?
No. Cloud SQL is a transactional database for application reads and writes. BigQuery is a serverless analytics platform billed by data processed per query or by reserved slot capacity. Many teams use both: Cloud SQL for the application and BigQuery for reporting. See BigQuery vs PostgreSQL.
Is Cloud SQL serverless?
No. Each instance is a provisioned virtual machine that you size by vCPUs and memory, and it is billed per second while it runs. For a serverless option on Google Cloud, Firestore is the closest match for operational data; for analytics, BigQuery.
Do I need the Cloud SQL Auth Proxy?
Not always. It is recommended for public IP connections because it handles IAM authorisation and encryption without authorised networks or certificates. For private IP connections Google recommends a direct connection with SSL enforced, and App Engine and Cloud Run connect without you running the proxy.
Can I get superuser access on Cloud SQL?
No. On PostgreSQL the highest role is cloudsqlsuperuser, which can create supported extensions; on MySQL some statements and plugins that need advanced privileges are blocked. This is the usual trade-off of a managed service.
Sources
- Cloud SQL overview
- Cloud SQL editions overview
- Cloud SQL editions overview (SQL Server)
- Cloud SQL editions overview (PostgreSQL)
- Cloud SQL for MySQL: database versions
- Cloud SQL for PostgreSQL: database versions
- Cloud SQL: About high availability
- Cloud SQL: Backups overview
- Cloud SQL: About replication
- Cloud SQL: Choose how to connect
- Cloud SQL: About the Cloud SQL Auth Proxy
- Cloud SQL quickstart: connect using the Auth Proxy (PostgreSQL)
- Cloud SQL: Create instances (PostgreSQL)
- Cloud SQL: Instance settings (PostgreSQL)
- Cloud SQL pricing
- Google Cloud Free Trial and Free Tier
- Cloud SQL: Configure PostgreSQL extensions
- Cloud SQL for MySQL features
- BigQuery pricing
Checked 8 October 2026.
How we research cloud database guides: our editorial method. CodeWithSQL earns nothing from the providers mentioned.