Cloud SQL Overview: What It Is, How It Works, and When to Use It

Cloud SQL is Google Cloud’s managed relational database service. It runs MySQL, PostgreSQL, and SQL Server on Google-managed infrastructure, so you get a familiar database engine without managing the underlying virtual machine, storage, or operating system. You still own your schema, queries, users, and performance tuning. Google handles everything below that line.

Cloud SQL in simple terms

Cloud SQL is a managed relational database. “Managed” means Google handles the infrastructure: the virtual machine the database runs on, the operating system, software patches, automated backups, storage management, and high availability configuration. You interact with the database itself, doing schema design, SQL queries, user management, and index tuning, exactly as you would with any MySQL, PostgreSQL, or SQL Server instance.

The practical result: you can run a production-grade relational database on GCP without hiring a DBA to handle infrastructure operations. It is the right starting point for most application databases that need SQL.

Analogy

Managing your own database on a Compute Engine VM is like renting a raw server and installing everything yourself: you configure the OS, patch the software, set up backups, and fix problems when they arise. Cloud SQL is like a managed server with a full maintenance team included. The database engine is the same one you already know. The difference is who keeps the lights on. You still own the data, the schema, and the queries. You just do not own the maintenance schedule.

What Cloud SQL is

Cloud SQL is a managed relational database, not a globally distributed one and not a serverless one. Each instance runs on a Google-managed virtual machine in a single region. You choose the machine type (CPU and memory), the storage type and size, and the database engine. Google manages the hypervisor, operating system, database software installation, and routine maintenance.

Because Cloud SQL runs a standard MySQL, PostgreSQL, or SQL Server engine, your existing SQL queries, application code, and database tools work without modification. This makes it the natural first choice when migrating an existing relational workload to GCP. If you already have a MySQL or PostgreSQL application running on-premises or on another cloud, Cloud SQL gives you a managed home for it with minimal migration friction.

Cloud SQL is not Cloud Spanner, which is globally distributed and handles horizontal write scaling. It is not Firestore, which is serverless and document-oriented. It is the managed version of a traditional relational database: reliable for transactional workloads, bounded by the capacity of a single instance, and subject to maintenance windows. See Choosing the Right Storage Service for a full comparison across GCP’s database options.

How Cloud SQL works

A Cloud SQL instance is the fundamental unit: a single database server. When you create one, you configure:

  • Database engine: MySQL, PostgreSQL, or SQL Server, with a choice of major version
  • Region: where the instance runs; data is stored in that region
  • Machine type: CPU and memory, ranging from shared vCPU to 96 dedicated vCPUs with proportional memory
  • Storage: SSD (recommended for most workloads) or HDD, with automatic storage increase available
  • High availability: whether to provision a standby instance in a secondary zone for automatic failover
  • Backups: automated daily backups retained for 7 days by default, configurable up to 365
  • Maintenance window: when Google may apply updates; the instance will restart during maintenance

Instances are identified by a connection name in the format project-id:region:instance-id. This connection name is used by the Cloud SQL Auth Proxy and by managed services like Cloud Run and GKE when connecting to Cloud SQL.

What you remain responsible for: schema design, query optimisation, index management, user and privilege management, connection pooling in your application, and capacity planning. Cloud SQL does not tune your queries and does not automatically scale your machine type as workload grows.

When to use Cloud SQL

Quick rule

If you already have a MySQL or PostgreSQL application and want to move it to GCP, Cloud SQL is almost always the right answer. Standard SQL, standard drivers, minimal migration work.

When Cloud SQL is a strong fit

  • Web application backends. User accounts, orders, content, and sessions all benefit from relational structure and ACID transactions.
  • Internal tools and admin panels. Moderate traffic, relational data, and straightforward operational requirements make Cloud SQL a natural fit.
  • CMS and e-commerce platforms. WordPress, Drupal, and most PHP or Python CMSs expect MySQL or PostgreSQL and connect without modification.
  • Lift-and-shift migrations. Moving an existing MySQL or PostgreSQL database from on-premises or another cloud is low-friction because Cloud SQL accepts standard engine connections.
  • Transactional workloads. Multi-table joins, foreign key constraints, and complex write transactions are what relational databases are built for.
  • Teams that know SQL well. No new query paradigm to learn; standard tooling works out of the box.

When Cloud SQL is not the right fit

  • Global horizontal write scaling. Cloud SQL scales reads with replicas but writes go to a single primary. For globally distributed writes, look at Cloud Spanner.
  • Sub-millisecond read latency at petabyte scale. That is Bigtable’s territory.
  • Serverless or variable-traffic workloads. Cloud SQL charges for a running instance whether or not it is busy. Firestore charges per operation and scales to zero.
  • Analytics and large-scale reporting. Cloud SQL can run reporting queries but will struggle under heavy analytical loads. BigQuery is designed for this.
  • Flexible or highly variable document schemas. Firestore handles schema-per-document data more naturally.

Cloud SQL connection options

There are three ways to connect to a Cloud SQL instance. For production, the decision is between private IP and the Auth Proxy. Public IP is for development only.

Cloud SQL Auth Proxy

The Auth Proxy is a binary that runs alongside your application. It authenticates using an IAM service account, establishes an encrypted TLS tunnel to Cloud SQL, and listens on a local port. Your application connects as if talking to a local database. The proxy handles encryption and authentication transparently.

Use the Auth Proxy when your application runs on Compute Engine, Cloud Run, GKE, or Cloud Functions and you want IAM-managed authentication without manually managing SSL certificates. For Cloud Run, you declare the instance connection name in the service configuration and Cloud Run starts the proxy automatically. For GKE, run the proxy as a sidecar container and use Workload Identity for credentials.

Recommended default

If you are unsure which connection method to use, start with the Auth Proxy. It works reliably from any GCP compute service, requires no VPC configuration, and handles encryption and IAM authentication for you. Switch to private IP later if you have high connection throughput or specific latency requirements.

Private IP

You can assign a Cloud SQL instance a private IP address within a VPC network. Applications in that VPC connect directly to the private IP using standard database drivers, without the Auth Proxy. This is the preferred pattern for high-throughput workloads where direct TCP connections are needed.

Private IP requires VPC peering between your project’s network and the service-managed VPC where Cloud SQL runs, configured via Private Service Connection. Configure this once per VPC before creating private IP instances. The full setup is covered in Connecting to Cloud SQL Securely.

Public IP with authorised networks

Cloud SQL instances can have a public IP address with an allowlist of permitted IP ranges. Connections are only accepted from listed addresses. This is the easiest way to connect from a development laptop and is fine for that purpose.

Warning

Do not use public IP with an open authorised network (0.0.0.0/0) for production databases. This exposes the database port to the entire internet. A valid password becomes your only line of defence. Use private IP or the Auth Proxy for production. If you do use public IP for development, restrict the allowlist to your actual IP address.

For a complete walkthrough of all three connection methods including setup steps, see Connecting to Cloud SQL Securely.

Creating a Cloud SQL instance

# Create a PostgreSQL 15 instance with private IP and high availability
gcloud sql instances create my-app-db \
  --database-version=POSTGRES_15 \
  --tier=db-g1-small \
  --region=europe-west2 \
  --availability-type=REGIONAL \
  --network=projects/my-project/global/networks/my-vpc \
  --no-assign-ip

# Create a database within the instance
gcloud sql databases create app_production \
  --instance=my-app-db

# Create a dedicated application user
gcloud sql users create app_user \
  --instance=my-app-db \
  --password=REPLACE_WITH_SECURE_PASSWORD

# Start the Auth Proxy and connect via psql
./cloud-sql-proxy my-project:europe-west2:my-app-db &
psql "host=127.0.0.1 port=5432 dbname=app_production user=app_user"

# View instance details
gcloud sql instances describe my-app-db
Note

The db-g1-small tier is suitable for development and testing. For production, size your instance based on expected connection count, query volume, and dataset size. You can resize vertically later, but it requires an instance restart.

High availability, backups, and recovery

Cloud SQL takes automated backups daily by default and retains them for 7 days (configurable up to 365). Point-in-time recovery (PITR) lets you restore to any second within the retention window. For MySQL, PITR requires binary logging to be explicitly enabled at instance creation. For PostgreSQL, PITR is automatic when backups are enabled.

High availability vs read replicas

Key distinction

High availability is about uptime during failure. Read replicas are about scaling read throughput. They are separate features that solve different problems and can be used together.

High availability (enabled with —availability-type=REGIONAL) provisions a standby instance in a secondary zone within the same region. The standby does not serve traffic under normal conditions. Its only job is to take over automatically if the primary zone becomes unavailable. HA instances cost approximately twice as much as single-zone instances. Enable HA for all production databases. The Backups and High Availability page covers this in detail.

Read replicas are separate Cloud SQL instances receiving continuous replication from the primary and accepting read-only queries. They scale read capacity for read-heavy workloads. Read replicas do not provide automatic failover. That is the HA standby’s job. A production database might reasonably have both HA enabled and one or more read replicas.

IAM database authentication

By default, Cloud SQL uses native database authentication: a username and password stored in the database engine itself. Cloud SQL also supports IAM database authentication for MySQL and PostgreSQL, where service accounts authenticate using their GCP IAM identity rather than a password.

IAM database authentication is worth enabling for service-to-database connections in production. It eliminates stored database passwords for service accounts, integrates access management with your existing IAM policies, and surfaces database authentication events in Cloud Audit Logs. For human users connecting via a SQL client, native database credentials remain the common pattern.

Cloud SQL vs other GCP database options

Cloud SQL is not the right choice for every database workload. Here is how it compares to the options you are most likely to consider.

Cloud SQL vs Firestore

Cloud SQL is relational; Firestore is a serverless NoSQL document database. Use Cloud SQL when your data is structured with relationships, you need SQL joins and transactions, or you are migrating an existing relational application. Use Firestore when your data is document-shaped, schemas vary between records, or you need real-time sync with mobile and web clients. Firestore scales to zero and charges per operation. Cloud SQL charges for a running instance. See the full Cloud SQL vs Firestore comparison.

Cloud SQL vs Bigtable

Bigtable is a wide-column NoSQL database for petabyte-scale time-series, IoT, and analytics workloads. It is designed for massive throughput at low latency, not for relational queries or transactional data. If your dataset is under 1 TB, Bigtable is not justified; the cluster costs alone make it expensive at small scale. Cloud SQL is the right choice for standard application databases. Bigtable is the right choice when you are processing telemetry, sensor data, or event streams at very high volume. See the Cloud SQL vs Bigtable comparison.

Cloud SQL vs BigQuery

BigQuery is a serverless analytical data warehouse, not an operational database. It is optimised for large-scale aggregate queries over historical data, not for frequent small updates and transactional reads. Use Cloud SQL for application data that changes frequently. Use BigQuery for analysis, reporting, and data exploration at scale. The two are often used together: Cloud SQL holds live transactional data, which is exported or streamed to BigQuery for analytics. See BigQuery vs Cloud SQL for a detailed breakdown.

Cloud SQL vs running a database on Compute Engine

You can run MySQL or PostgreSQL on a Compute Engine VM yourself, which gives you full control: any configuration, any extension, full OS access, and no restrictions on what you install. The trade-off is that you own every operational concern: OS patching, database updates, backups, HA setup, storage management, and monitoring. Cloud SQL handles all of that for you. For most application databases, Cloud SQL is the correct default. Running on Compute Engine is justified when you need a custom extension, a configuration parameter Cloud SQL does not expose, or a database engine other than MySQL, PostgreSQL, or SQL Server.

Common beginner mistakes

  1. Leaving the authorised networks list open to 0.0.0.0/0. This exposes your database port to the entire internet. A valid password becomes your only protection. Use private IP or the Auth Proxy for production. If you use public IP for development, restrict the allowlist to specific IP ranges.

  2. Skipping high availability for production databases. A single-zone instance has no automatic failover. If the zone running your instance has an outage, your database is unavailable until that zone recovers. Enable —availability-type=REGIONAL for all production databases.

  3. Under-sizing the instance. A db-g1-small is suitable for development but will struggle under production OLTP workloads. Size based on expected connection count, query throughput, and dataset size, not on the minimum that passes a basic test.

  4. Not handling dropped connections in application code. Cloud SQL maintenance events, failovers, and restarts close all existing connections. Applications without connection pooling and retry logic will fail when this happens. Use a connection pooler and test your application’s behaviour when the database connection drops.

  5. Treating read replicas as failover targets. Read replicas are for scaling reads, not for automatic failover. If the primary fails, a read replica does not take over automatically; you would need to manually promote it. High availability (the standby instance) is the correct mechanism for automatic failover. See Backups and High Availability for the distinction.

Related guides

These pages go deeper on the specific topics introduced here.

Frequently asked questions

What databases does Cloud SQL support?

Cloud SQL supports MySQL, PostgreSQL, and SQL Server. Each engine is available in multiple major versions, and you choose at instance creation time. You cannot switch engines after the fact, though you can upgrade to a newer major version of the same engine with some downtime. Oracle is not supported; for that you would need to run it yourself on a Compute Engine VM.

Is Cloud SQL serverless?

No. Cloud SQL is a managed service, not a serverless one. Each instance runs on a Google-managed virtual machine that you size when you create it. You pay for the instance whether it is handling queries or idle. If you need a database that scales to zero and bills per request, look at Firestore instead, though it is a NoSQL document database rather than a relational one.

When should I use Cloud SQL instead of Firestore?

Use Cloud SQL when your data is relational: you have tables with foreign keys, you need joins, you are running transactional workloads, or you are migrating an existing MySQL or PostgreSQL application. Use Firestore when your data is document-shaped, your schema varies between records, or you need real-time sync with mobile and web clients. The two are designed for different kinds of data.

What is the difference between high availability and read replicas?

High availability (HA) provisions a standby instance in a second zone within the same region. Its only job is to take over if the primary zone fails; it does not serve traffic normally. A read replica is a separate instance that receives continuous replication from the primary and accepts read-only queries. Read replicas scale read capacity but do not provide automatic failover. HA handles failover. You can use both together.

Is public IP safe for production?

Not as a default. A public IP instance exposes the database port to the internet, which means a valid password becomes your only protection. For production workloads, use private IP when your app is in the same VPC, or the Cloud SQL Auth Proxy when you want IAM-authenticated encrypted connections. Public IP with a tightly restricted authorised networks list is acceptable for laptop-based development access, but should not be used for production databases holding real data.

Last verified: 23 March 2026 Cloud services change frequently. Verify details against official documentation before making infrastructure decisions.