Cloud SQL is a fully managed relational database service supporting MySQL, PostgreSQL, and SQL Server. Google handles provisioning, patching, replication, and backups — you manage schema, queries, and connection logic. For most applications, Cloud SQL is the right default before reaching for self-managed databases on Compute Engine or Cloud Spanner for global scale.

Instance Tiers

Tier vCPUs Memory Use Case
Shared-core (db-f1-micro) Shared 0.6 GB Dev/test only
Standard (db-custom) 1–96 0.9–624 GB Production workloads
High Memory 2–96 3.75–624 GB Memory-intensive queries

Storage auto-grows up to configured limits. Choose SSD for production workloads.

Cloud SQL vs. Alternatives

Service Best For Scale Limit
Cloud SQL Standard relational apps ~64 TB, single region HA
AlloyDB PostgreSQL, high performance Larger, faster than Cloud SQL
Cloud Spanner Global, strongly consistent Unlimited horizontal scale
Firestore Document, mobile/web Auto-scaling NoSQL
Self-managed on GCE Full control, custom extensions Your responsibility

Create a PostgreSQL Instance 

  gcloud sql instances create app-db \
  --database-version=POSTGRES_15 \
  --tier=db-custom-2-4096 \
  --region=us-central1 \
  --storage-type=SSD \
  --storage-size=20GB \
  --storage-auto-increase \
  --backup-start-time=03:00 \
  --enable-point-in-time-recovery \
  --retained-backups-count=14 \
  --network=projects/learning-gcp-dev/global/networks/learning-vpc \
  --no-assign-ip

gcloud sql databases create appdb --instance=app-db

gcloud sql users create appuser \
  --instance=app-db \
  --password=SecureP@ssw0rd!

Connect from Application

Use the Cloud SQL Auth Proxy for secure connections without managing IP allowlists:

  # Install proxy
curl -o cloud-sql-proxy https://storage.googleapis.com/cloud-sql-connectors/cloud-sql-proxy/v2.8.0/cloud-sql-proxy.darwin.arm64
chmod +x cloud-sql-proxy

# Connect (private IP via VPC)
./cloud-sql-proxy learning-gcp-dev:us-central1:app-db --private-ip &

Node.js connection:

  const { Pool } = require('pg');

const pool = new Pool({
  host: '127.0.0.1',
  port: 5432,
  user: 'appuser',
  password: process.env.DB_PASSWORD,
  database: 'appdb',
  max: 20,
  idleTimeoutMillis: 30000
});

const result = await pool.query('SELECT * FROM users LIMIT 10');

On GKE, use the Cloud SQL Auth Proxy sidecar or the Cloud SQL connector library with Workload Identity for passwordless auth.

High Availability

Feature Description
HA configuration Standby in another zone, automatic failover (~60s)
Read replicas Scale read traffic, cross-region replicas
Point-in-time recovery Restore to any second within retention window
Automated backups Daily backups with configurable retention

Enable HA:

  gcloud sql instances patch app-db \
  --availability-type=REGIONAL

# Create read replica in another region
gcloud sql instances create app-db-replica \
  --master-instance-name=app-db \
  --tier=db-custom-2-4096 \
  --region=europe-west1

Security 

  # Enable IAM database authentication (PostgreSQL)
gcloud sql instances patch app-db \
  --database-flags=cloudsql.iam_authentication=on

# Create IAM user
gcloud sql users create [email protected] \
  --instance=app-db --type=cloud_iam_user
Practice Implementation
Private IP VPC peering — no public endpoint
Credentials Secret Manager, not env vars in source code
IAM auth Passwordless for PostgreSQL and MySQL
SSL/TLS Required for all connections
Authorized networks Only when public IP is unavoidable

Operations 

  # View operations and maintenance windows
gcloud sql operations list --instance=app-db

# Clone instance for testing
gcloud sql instances clone app-db app-db-clone

# Restore from backup
gcloud sql backups list --instance=app-db
gcloud sql backups restore BACKUP_ID --restore-instance=app-db-restored

# Point-in-time recovery
gcloud sql instances clone app-db app-db-pitr \
  --point-in-time='2024-06-01T10:00:00.000Z'

Real-World Scenario: Production PostgreSQL

A SaaS application runs PostgreSQL for transactional data:

  GKE Pods (Cloud SQL Proxy sidecar)
  → Private IP (VPC peering)
    → Cloud SQL HA (us-central1, regional)
      ├── Primary (zone a)
      └── Standby (zone b, auto-failover)
  1. Regional HA instance with private IP only
  2. Automated backups + PITR with 14-day retention
  3. Read replica in europe-west1 for EU reporting queries
  4. Credentials in Secret Manager; IAM auth for admin access
  5. Connection pooling via PgBouncer sidecar (max 20 connections per pod)

Common Mistakes

Mistake Impact Fix
db-f1-micro in production CPU throttling, crashes Minimum db-custom-2-4096 for prod
Public IP enabled Attack surface Private IP + Auth Proxy
No connection pooling Connection exhaustion PgBouncer or built-in pooler
Passwords in env vars Leaked in logs/images Secret Manager + IAM auth
Skipping maintenance windows Unplanned downtime Schedule during low-traffic hours

Best Practices

  • Use private IP with VPC peering for all production instances
  • Store credentials in Secret Manager
  • Enable IAM database authentication for PostgreSQL
  • Configure automated backups and test restore quarterly
  • Use read replicas for reporting, not primary for analytics
  • Monitor with Cloud Monitoring (cloudsql.googleapis.com/database/cpu/utilization)
  • Set maintenance window during off-peak hours
  • Right-size with Recommender overprovisioned SQL suggestions

Troubleshooting

“Too many connections”:

  gcloud sql instances patch app-db --database-flags=max_connections=200
# Better: add connection pooling (PgBouncer)

Auth Proxy connection refused:

  # Verify instance is running
gcloud sql instances describe app-db --format="get(state)"
# Check VPC peering is active
gcloud services vpc-peerings list --network=learning-vpc

Failover took longer than expected: HA failover typically completes in 60–120 seconds. Application connection pools must handle reconnection. Use exponential backoff in your driver.

High replication lag on read replica: Check primary write volume; consider larger replica tier or dedicated replica for heavy queries.

Cloud SQL delivers managed relational databases with GCP-native networking, identity, and monitoring integrations.

Next: VPC Networking — subnets, firewalls, and load balancing.