Cloud SQL for MySQL: Setup, Security, and Production Patterns

What Cloud SQL for MySQL really is

If you have used MySQL before, Cloud SQL will feel familiar almost immediately. You connect with the same client, write the same SQL, and manage schemas the same way. The MySQL engine is genuine, not emulated.

The managed part means Google handles: provisioning the underlying VM, applying OS and database patches, running automated backups, managing storage growth, and responding to hardware failures. You never SSH into the database server, and you never edit my.cnf directly. Database flags are how you tune the server.

What you still manage: your schemas, users, data, access permissions, connection handling, and query performance. The managed service draws a line at the database engine itself. Everything above that line is your responsibility.

How Cloud SQL for MySQL works

A Cloud SQL instance is a managed VM running the MySQL process. You choose the machine type (CPU and RAM), storage size and type, the region, and whether you want high availability. Cloud SQL provisions the VM, attaches the storage, installs the correct MySQL version, and makes it accessible according to your connection settings.

Storage is separate from the VM and can grow automatically when you enable storage auto-increase. Daily automated backups are stored in Cloud Storage. Point-in-time recovery (PITR) builds on those backups using continuous binary logs, which lets you restore to any second within the retention window. Binary logging must be explicitly enabled at instance creation.

Read replicas stream changes from the primary continuously and can handle read-heavy queries, but they do not provide automatic failover. A high-availability instance uses a synchronous standby in a different zone and fails over automatically if the primary zone has a problem.

When to use Cloud SQL for MySQL

Cloud SQL for MySQL fits well when your data is relational, your access patterns involve SQL queries, and you want a managed service rather than running a database server yourself. Good fits include:

• Web applications with a relational data model. User accounts, orders, products, sessions, content: anything that maps naturally to tables with relationships is a reasonable fit. If your ORM or framework expects MySQL, Cloud SQL is the lowest-friction path.

• Migrating an existing MySQL application. Your schema, queries, and application code all transfer with minimal changes. Cloud SQL is designed to be compatible with standard MySQL, so most migrations involve configuration changes rather than application rewrites.

• Teams that want managed database operations. If you do not have a dedicated DBA and do not want to manage patching, backups, and failover manually, the managed model is a meaningful advantage over running MySQL yourself on a VM.

• Transactional workloads. If your workload depends on ACID transactions, foreign key constraints, or complex multi-table queries, Cloud SQL is the right service in the GCP storage family. Firestore, BigQuery, and Bigtable serve different patterns.

• Applications running on Cloud Run or GKE. Cloud Run integrates with Cloud SQL via the Auth Proxy sidecar, making it a common pairing for containerised web applications. See Cloud Run Overview for how that deployment model works.

When Cloud SQL for MySQL may not be the right fit

Not every workload belongs on a relational database. Before choosing Cloud SQL, consider whether the data shape and access patterns are actually a good match. The Choosing the Right GCP Storage Service guide walks through the full decision flow across all GCP storage options.

• Document-shaped or schema-flexible data. If your data does not fit into fixed rows and columns, or if different records in a collection have different shapes, Firestore may be a better choice. It is serverless, scales automatically, and handles real-time sync for mobile and web clients without you provisioning instance sizes.

• Analytical or reporting workloads over large datasets. Cloud SQL is an OLTP database built for transactional reads and writes. Running large analytical queries over hundreds of millions of rows will be slow and expensive compared to BigQuery, which is built for exactly that kind of workload.

• Globally distributed writes with strong consistency. Cloud SQL is a regional service. If you need a globally distributed relational database with strong consistency across multiple continents, Cloud Spanner is designed for that. Cloud SQL cannot synchronously replicate across regions.

• Workloads requiring deep OS-level MySQL control. If your workload requires custom MySQL plugins, specific kernel-level tuning, or MySQL features that Cloud SQL restricts, you can run MySQL yourself on Compute Engine. You lose the managed service benefits but gain full control over the stack.

Creating a MySQL instance

Use gcloud sql instances create to provision an instance. The command below sets a reasonable production baseline: SSD storage, automatic storage growth, automated daily backups, and binary logging for point-in-time recovery.

gcloud sql instances create my-mysql-instance \
  --database-version=MYSQL_8_0 \
  --tier=db-n1-standard-2 \
  --region=europe-west2 \
  --storage-type=SSD \
  --storage-size=20GB \
  --storage-auto-increase \
  --backup-start-time=03:00 \
  --enable-bin-log

A few decisions worth understanding before you run this:

• Version. Use MySQL 8.0 for new instances. It is the current active major version and receives ongoing maintenance. Earlier major versions are available but approaching end-of-life. Check the Cloud SQL documentation for the current supported MySQL version list before choosing, as minor versions are updated over time.

• Machine type. The —tier flag controls CPU and RAM. Use db-f1-micro for development and non-critical staging. For production, choose a tier based on your expected connection count and query throughput. Undersized instances are one of the most common causes of production slowdowns.

• Region. Pick the region closest to your application. Cloud SQL is a regional service, so cross-region latency adds up on every query. Think about this alongside where your application is deployed.

Managing users and databases

Cloud SQL creates a default root user on every instance. Secure it immediately, then create a dedicated application user. Root should be reserved for administrative tasks only.

# Set the root password
gcloud sql users set-password root \
  --instance=my-mysql-instance \
  --host=% \
  --password=your-secure-password

# Create a dedicated application user
gcloud sql users create app-user \
  --instance=my-mysql-instance \
  --host=% \
  --password=app-user-password

# Create a database
gcloud sql databases create my-app-db \
  --instance=my-mysql-instance

# List databases on the instance
gcloud sql databases list --instance=my-mysql-instance

Granting only the permissions the application requires follows the principle of least privilege and limits what an attacker can do with a compromised connection. The application user does not need CREATE TABLE, DROP, or access to other databases on the same instance.

Connecting to your instance

How you connect depends on where your application runs and what security model you need. There are three main patterns, and choosing correctly matters more for databases than for most services.

• Cloud SQL Auth Proxy. Authenticates using your IAM identity or a service account, establishes an encrypted tunnel to the instance, and listens on a local port. Your application connects to 127.0.0.1:3306 as if connecting to a local database. The proxy handles all authentication and encryption. This is the standard approach for local development and for workloads on Compute Engine or Cloud Run where private IP is not in use.

• Private IP. Places your Cloud SQL instance on your VPC, reachable from other resources in the same network without going over the public internet. Preferred for production workloads on GKE, Compute Engine, or Cloud Run with VPC access configured. See VPC Networks Explained for how VPC connectivity works in GCP.

• Public IP with authorised networks. Exposes the database on a public IP, restricted to a specific list of IP ranges. Acceptable for developer laptops in controlled settings. Not suitable for production workloads. See Private vs Public IP Addresses for a fuller explanation of the tradeoffs between these models.

# Run the Cloud SQL Auth Proxy
./cloud-sql-proxy my-project:europe-west2:my-mysql-instance

# In a second terminal, connect with the mysql client
mysql -u app-user -p --host=127.0.0.1 --port=3306 my-app-db

For a thorough walkthrough of each connection method, including Kubernetes sidecar setup and IAM database authentication, see Connecting to Cloud SQL Securely.

Configuring MySQL with database flags

On a self-managed MySQL instance, you would edit my.cnf to tune server settings. Cloud SQL does not give you OS access, so database flags are the only mechanism for changing server configuration. The flag system maps Cloud SQL flag names to the underlying MySQL system variables.

# Enable slow query logging with a 1-second threshold
gcloud sql instances patch my-mysql-instance \
  --database-flags=slow_query_log=on,long_query_time=1

# Check the current flags on an instance
gcloud sql instances describe my-mysql-instance \
  --format="value(settings.databaseFlags)"

Some flags require a restart to take effect. The gcloud output will indicate when this is the case. Schedule restarts during a maintenance window for production instances. Not every MySQL system variable has a corresponding Cloud SQL flag, so check the supported flags list in the Cloud SQL documentation before building anything that depends on a specific flag being available.

Read replicas, backups, and availability

Cloud SQL offers several overlapping features that address different concerns. Understanding what each one does independently prevents a common class of production mistakes.

Automated backups are daily snapshots of your instance stored in Cloud Storage. They allow restoration to the state at any backup point. Backups alone do not give you second-level recovery granularity.

Point-in-time recovery (PITR) combines daily backups with continuous binary logs to let you restore to any second within the retention window. Binary logging must be explicitly enabled with —enable-bin-log. Without it, PITR is unavailable and your recovery point is the most recent daily backup.

Read replicas are separate Cloud SQL instances that continuously replicate from the primary. Send read-heavy traffic to a replica to reduce load on the primary. Replicas do not provide automatic failover.

High availability provisions a synchronous standby in a different zone within the same region. If the primary zone has a failure, Cloud SQL automatically promotes the standby and updates the connection endpoint. This is automatic failover. Read replicas are not.

For configuration details, retention window settings, and a worked example of PITR setup, see Cloud SQL Backups, PITR, and High Availability.

# Create a read replica in the same region
gcloud sql instances create my-mysql-replica \
  --master-instance-name=my-mysql-instance \
  --region=europe-west2 \
  --tier=db-n1-standard-2

# Promote a replica to a standalone instance (breaks replication permanently)
gcloud sql instances promote-replica my-mysql-replica

Cloud SQL for MySQL vs self-managed MySQL

Choosing between Cloud SQL and running MySQL yourself on Compute Engine is a question of operational simplicity versus control. Cloud SQL is the right default for the vast majority of application databases. Self-managed MySQL makes sense only when a specific technical requirement cannot be satisfied by the managed service.

What Cloud SQL handles for you: OS and database patching, automated daily backups, PITR setup, high availability failover, storage management, and minor version upgrades within a major version. You do not need to schedule, test, or think about any of these in most cases.

What you give up: full my.cnf control, the SUPER privilege for runtime SQL, custom MySQL plugins, and any configuration outside the supported database flags list.

Where self-managed MySQL wins: when you genuinely need a custom plugin, specific kernel-level tuning, or a MySQL feature that Cloud SQL restricts. If you make that choice, be clear-eyed about the operational cost. You own patching, backup testing, and failover configuration. None of it is free.

Cost: Cloud SQL instances are priced per hour plus storage. Self-managed MySQL on Compute Engine may cost less for very large instances if you have strong database operations capability in-house. For most teams, the managed service is the more economical choice once you account for operational effort.

If you are evaluating PostgreSQL alongside MySQL, see PostgreSQL on Cloud SQL for the key differences in how each engine behaves on the managed service.