Cloud Run + Cloud SQL: The Boring Blueprint That Runs Half My Production Systems

Cloud Run + Cloud SQL is the right choice when all of these are true:

• Your workload is stateless HTTP or event-driven, not long-lived (>60 min) jobs.
• You need Postgres or MySQL semantics, not a NoSQL data model.
• Your peak RPS is under a few thousand — beyond that, GKE + Cloud Spanner or AlloyDB may win.
• You want to scale to zero on nights/weekends to save money.

If any of those don't hold, consider GKE Autopilot, Cloud Functions, or AlloyDB. This article is the boring default, not a universal answer.

resource "google_sql_database_instance" "main" {
  name             = "prod-db"
  database_version = "POSTGRES_16"
  region           = "europe-west1"

  settings {
    tier              = "db-custom-2-7680"
    availability_type = "REGIONAL"   # HA
    disk_autoresize   = true
    backup_configuration {
      enabled                        = true
      point_in_time_recovery_enabled = true
      transaction_log_retention_days = 7
    }
    ip_configuration {
      ipv4_enabled = false           # private only
      private_network = google_compute_network.vpc.id
    }
    database_flags {
      name  = "cloudsql.iam_authentication"
      value = "on"
    }
  }
  deletion_protection = true
}

resource "google_cloud_run_v2_service" "app" {
  name     = "app"
  location = "europe-west1"

  template {
    scaling { min_instance_count = 0; max_instance_count = 20 }
    service_account = google_service_account.app.email

    containers {
      image = "europe-west1-docker.pkg.dev/PROJECT/app/app:${var.image_tag}"
      resources { limits = { cpu = "1"; memory = "512Mi" } }

      env { name = "DATABASE_URL"; value_source {
        secret_key_ref { secret = "database-url"; version = "latest" }
      }}
    }

    containers {
      name  = "cloudsql-proxy"
      image = "gcr.io/cloud-sql-connectors/cloud-sql-proxy:2.11.4"
      args  = ["--structured-logs", "--private-ip", google_sql_database_instance.main.connection_name]
    }
  }
}

Cloud SQL's max_connections is fixed by tier. A db-custom-2-7680 gives you ~100 connections. Cloud Run can spin up 100 instances in seconds, each opening a pool of 10 connections. Math: you're down.

Two-layer pooling is the fix:

1. In-app pool sized to ceil(max_connections / max_instances) — usually 2–5.
2. PgBouncer in transaction mode in front of Cloud SQL, either as a sidecar or a dedicated Cloud Run service.

Never bake secrets into container images. Never commit them to Git. Store them in Secret Manager and reference by secret_key_ref — Cloud Run fetches at container start.

Rotate rules:

• Rotate DB passwords quarterly; automate via Cloud Scheduler → Cloud Function.
• Version secrets — latest is convenient but pin to version = "3" for change control on critical services.
• Grant roles/secretmanager.secretAccessor at the secret level, never project-wide.

Never run migrations at container start — you'll have N containers racing. Two patterns work:

1. Migration job: Cloud Run Jobs task with alembic upgrade head, run before deploy. Fails deploy on error.
2. Sqitch / Flyway in CI/CD before gcloud run deploy.

For expand-contract migrations (add column → backfill → switch reads → drop old column), split across multiple deploys. Never combine schema change and code change in one PR.

# Deploy new revision, keep 0% traffic
gcloud run deploy app --image=... --no-traffic --tag=candidate

# Smoke test against candidate URL
curl https://candidate---app-xyz.a.run.app/health

# Route 10% → 100%
gcloud run services update-traffic app --to-tags=candidate=10
gcloud run services update-traffic app --to-tags=candidate=100

# Rollback if needed
gcloud run services update-traffic app --to-revisions=app-prev=100

• Set min-instances=0 on all non-latency-critical services.
• Use --cpu-boost only for cold-start-sensitive endpoints.
• Cloud SQL: rightsize with Recommender; downgrade tier if CPU < 40% for 30 days.
• Turn on Cloud SQL Query Insights; the top 3 slow queries usually account for >50% of DB CPU.
• Enable Cloud Run CPU always allocated only for background work; otherwise you pay for idle.

Full cost playbook in BigQuery cost control that scales.

• Ship structured JSON logs — Cloud Logging parses severity, trace, message automatically.
• Emit OpenTelemetry traces to Cloud Trace; correlate DB, LLM, and HTTP spans.
• Managed Prometheus for RED metrics (rate, errors, duration).
• Uptime checks + SLO burn-rate alerts, not raw error alerts.

Deep patterns in observability for AI systems.

You've outgrown this blueprint when: sustained RPS exceeds a few thousand, you need multi-region active/active, or your DB working set exceeds ~500GB with hot access. Graduate to GKE Autopilot + AlloyDB or Spanner, and read modern data stack in 2026 to reason about where analytics data goes next.