Cloud SQLAuthorCloudBrum editorial teamLast reviewed29 Oct 2026Reading time~12 minLevelBeginner to advanced

• Three enginesMySQL, PostgreSQL and SQL Server run as managed instances, with the usual drivers and tools. Each engine has its own version list and limits, so read the page for yours.
• Two editionsEnterprise is for general use. Enterprise Plus targets heavier workloads with a higher availability commitment, near-zero downtime for planned maintenance, a longer log window for recovery and an optional local SSD data cache.
• A standby in another zoneTurn on high availability and Cloud SQL keeps a standby instance in a second zone of the same Region. If the primary or its zone fails, the standby takes over automatically and keeps the same IP address.
• Backups and point-in-time recoveryDaily automated backups, on-demand backups and a continuous log let you restore to a moment you choose, as a new instance or over the existing one.
• Read replicasAdd replicas in the same Region or another, for read traffic or recovery. A replica can be promoted to a stand-alone instance.
• Safer ways to connectThe Cloud SQL Auth Proxy and the language connectors use IAM to authorise and TLS to encrypt, so you don’t have to maintain IP allow-lists or client certificates.
• IAM sign-inWith IAM database authentication, people and service accounts log in with short-lived tokens, and database access follows the same roles as the rest of Google Cloud.
• Query insightsA built-in tool shows the queries that use the most time and which applications issue them, so slow spots are visible without installing anything.

Instance

One managed database server, with an engine and version, a machine size, storage and a Region.

Edition

Enterprise or Enterprise Plus. It decides the available machine types, the availability commitment, maintenance downtime and some features.

Machine tier

The vCPU and memory of the instance, such as db-custom-2-7680 for 2 vCPUs and 7.5 GB. Enterprise Plus uses its own performance-optimised tiers.

High availability (regional)

A primary and a standby in two zones of one Region, with the data copied synchronously. Failover is automatic, and the standby doesn’t answer queries.

Read replica

An asynchronous copy for read traffic or recovery, in-Region or cross-Region. It lags a little behind and can be promoted.

Automated backup

A daily backup that Cloud SQL keeps for a number of copies that you choose (1 to 365).

Point-in-time recovery

Uses the backups plus the transaction logs, which are kept for a set number of days, to rebuild the database at a chosen moment.

Private IP

An address inside your VPC network, reached through private services access or Private Service Connect, with no route from the internet.

Authorised networks

The list of public IP ranges allowed to connect when the instance has a public address.

Cloud SQL Auth Proxy

A small program that opens an encrypted, IAM-checked tunnel to the instance, so the application connects to localhost.

Language connector

A library (Python, Java, Go, Node.js) that does what the proxy does from inside your code.

IAM database authentication

Logging in with an IAM user or service account and a short-lived token instead of a database password.

Database flag

An engine setting you change through Cloud SQL, such as max_connections or cloudsql.iam_authentication. Some flags restart the instance.

Maintenance window

A weekly slot when updates can be applied, with an optional deny period of up to 90 days during which they’re held back.

Create a PostgreSQL instance in the Google Cloud console

1. Pick the project, enable the API and decide on networkingChoose a project with billing, enable the Cloud SQL Admin API, and decide whether the instance gets a private IP. A private IP needs private services access set up on the VPC network first, which means reserving an address range.
2. Start the create flowOpen SQL, choose Create instance, then PostgreSQL. Give it a name (it can’t be reused for about a week after deletion) and a strong password for the default postgres user, or plan to use IAM sign-in.
3. Choose the editionPick Enterprise for most applications. Choose Enterprise Plus if you need the higher availability commitment, near-zero maintenance downtime or the data cache, and check that your Region and version offer it.
4. Choose the Region and the availabilityPick the Region nearest your application (Mumbai asia-south1 or Delhi asia-south2 for India). Choose Multiple zones (highly available) for production, or a single zone for development.
5. Pick the machine and the storageChoose vCPUs and memory, SSD storage, and turn on automatic storage increases with a limit. Start modest, since you can change the machine later with a short restart.
6. Configure connectivityUntick Public IP and tick Private IP, selecting the network. If you have to use a public IP, leave authorised networks empty and connect through the Auth Proxy instead of opening a range.
7. Set up data protectionTurn on automated backups and point-in-time recovery, choose how many backups to keep and how many days of logs, and turn on deletion protection.
8. Add flags and sign-inSet the flag cloudsql.iam_authentication to on if you want IAM database sign-in, and keep SSL enforcement at Encrypted only.
9. Connect and testConnect with the Auth Proxy or a language connector from a VM or Cloud Run service in the network, create an application user with limited rights, and test a restore to a new instance before you depend on the backups.

• Choose the machine tier from measurements: CPU, memory and cache hit ratio. Memory-heavy databases usually need more RAM per vCPU than the default.
• Pick SSD storage and size it for the IOPS you need, since throughput and IOPS scale with disk size.
• Consider Enterprise Plus with the data cache for read-heavy workloads where reads from the persistent disk are the bottleneck.
• Use connection pooling (in the application, a pooler, or the managed option where offered) when many short-lived clients connect, for example from Cloud Run.
• Send reporting and read-heavy queries to read replicas, and monitor replica lag.
• Find slow queries with Query insights, add indexes and check plans before upsizing.
• Keep the application in the same Region and zone as the primary to keep latency down.
• Keep transactions short and tune vacuum or purge settings so tables don’t bloat.

FinOps is the habit of managing cloud spend together with engineering. These are the FinOps checks that matter most for Cloud SQL.

• Use single-zone instances for development and test. Regional high availability roughly doubles the instance cost.
• Stop non-production instances when nobody is using them. Compute billing pauses, but storage still bills.
• Prefer the Enterprise edition unless you need what Enterprise Plus adds, since Enterprise Plus costs more per vCPU.
• Right-size from Cloud Monitoring graphs, and move to a smaller machine when the use is low.
• Look at committed use discounts for instances that will run for a year or three.
• Keep the backup count and log retention to what recovery needs, because extra backups cost storage.
• Delete unused replicas, clones and old exports, which keep billing for storage and compute.
• Avoid cross-Region traffic between the app and the database, which adds network charges and latency.
• Turn on storage auto-increase with a limit instead of over-provisioning, remembering that storage can’t shrink.
• Add labels to instances for owner and environment, and set budgets by label.

• Give instances a private IP, turn off the public IP where you can, and reach the database through the Auth Proxy or a language connector.
• Set SSL mode to encrypted only, and verify the server certificate in clients that connect directly.
• Use IAM database authentication for people and service accounts, and keep any built-in user passwords in Secret Manager.
• Grant roles/cloudsql.client and roles/cloudsql.instanceUser to the identities that need to connect, and keep roles/cloudsql.admin for a small team.
• Create separate database roles for owners, migrations and applications, and grant only the privileges each needs.
• Use customer-managed encryption keys (CMEK) where policy requires them, and restrict key access.
• Wrap the project in VPC Service Controls and organisation policies, for example to require private IP and to restrict Regions.
• Turn on audit logs (admin and data access where needed) and database logging, and alert on failed logins and flag changes.
• Turn on deletion protection and keep backups or exports in a separate project.
• Review authorised networks, flags and users regularly, and manage them in code.

Cloud Audit Logs show who changed an instance, Cloud Asset Inventory and Security Command Center track configuration and posture, Dataplex can catalogue data, and the Compliance resource centre holds reports. Duties are divided as usual: Google runs the platform, the patching and the failover machinery, and you are responsible for the data, the roles, the network exposure and how recovery is tested.

• Match the machine to the load. Spare vCPUs and memory draw power around the clock.
• Stop development instances outside working hours, and delete clones and replicas after use.
• Use read replicas only where reads need them.
• Index and cache so queries read less data and the same instance serves more.
• Keep backup and log retention to what recovery needs.
• Pick a Region with lower carbon intensity for work that isn’t tied to a place. Google publishes carbon-free energy percentages for each Region.
• Carbon Footprint in the Cloud Console reports emissions for your account. Check how it counts Cloud SQL before you quote a number from it.

Purchase options

What you actually pay for

• vCPU and memory hours by edition, doubled by regional high availability
• Storage by type and size
• Backup and log storage by size and retention
• Network egress, for example cross-Region replicas or traffic to the internet
• Read replicas and clones, billed like instances

The same orders database on Google Cloud: a PostgreSQL 16 instance with a private IP, a standby in another zone, 14 backups with point-in-time recovery and IAM sign-in, plus a read replica and a clone for a restore test. The gcloud and Terraform tabs build it. The Python tab connects with the Cloud SQL connector, and the C# tab goes through the Auth Proxy. Both place an order in a transaction. The project, network and service account names are examples. Private IP needs private services access on the network first (the Terraform tab shows it), and a high availability instance bills from creation, so delete the test instance afterwards.

# Names are examples. Mumbai is the example Region. Private IP needs private services access on the VPC first:
#   gcloud compute addresses create google-managed-services-default --global --purpose=VPC_PEERING --prefix-length=16 --network=default
#   gcloud services vpc-peerings connect --service=servicenetworking.googleapis.com --ranges=google-managed-services-default --network=default
PROJECT=my-project
REGION=asia-south1
APP_SA=orders-app@$PROJECT.iam.gserviceaccount.com

gcloud services enable sqladmin.googleapis.com servicenetworking.googleapis.com --project=$PROJECT

# A private, highly available PostgreSQL 16 instance with IAM sign-in
gcloud sql instances create orders-db --project=$PROJECT --region=$REGION \
  --database-version=POSTGRES_16 --edition=ENTERPRISE --tier=db-custom-2-7680 \
  --availability-type=REGIONAL \
  --storage-type=SSD --storage-size=100 --storage-auto-increase \
  --network=projects/$PROJECT/global/networks/default --no-assign-ip \
  --ssl-mode=ENCRYPTED_ONLY \
  --backup-start-time=21:00 --retained-backups-count=14 \
  --enable-point-in-time-recovery --retained-transaction-log-days=7 \
  --database-flags=cloudsql.iam_authentication=on \
  --deletion-protection

gcloud sql databases create orders --instance=orders-db --project=$PROJECT

# An IAM-authenticated database user for the application's service account (note: no .gserviceaccount.com)
gcloud sql users create orders-app@$PROJECT.iam --instance=orders-db --project=$PROJECT --type=cloud_iam_service_account
gcloud projects add-iam-policy-binding $PROJECT --member=serviceAccount:$APP_SA --role=roles/cloudsql.client
gcloud projects add-iam-policy-binding $PROJECT --member=serviceAccount:$APP_SA --role=roles/cloudsql.instanceUser

# A read replica for reporting
gcloud sql instances create orders-db-replica --project=$PROJECT --region=$REGION \
  --master-instance-name=orders-db --tier=db-custom-2-7680

# Practise the restore: clone the instance as it was at a chosen moment (UTC)
gcloud sql instances clone orders-db orders-db-restore-test --project=$PROJECT \
  --point-in-time=2026-10-29T08:30:00Z

# Clean up the test copy
gcloud sql instances delete orders-db-restore-test --project=$PROJECT --quiet

# Assumes the google provider version 5 or later and the default VPC network
variable "project" { type = string }
variable "region"  { default = "asia-south1" }

provider "google" {
  project = var.project
  region  = var.region
}

resource "google_project_service" "services" {
  for_each           = toset(["sqladmin.googleapis.com", "servicenetworking.googleapis.com"])
  service            = each.value
  disable_on_destroy = false
}

data "google_compute_network" "default" {
  name = "default"
}

# Private services access: a reserved range plus the private connection to Google's services
resource "google_compute_global_address" "private_range" {
  name          = "google-managed-services-default"
  purpose       = "VPC_PEERING"
  address_type  = "INTERNAL"
  prefix_length = 16
  network       = data.google_compute_network.default.id
}

resource "google_service_networking_connection" "private" {
  network                 = data.google_compute_network.default.id
  service                 = "servicenetworking.googleapis.com"
  reserved_peering_ranges = [google_compute_global_address.private_range.name]
  depends_on              = [google_project_service.services]
}

resource "google_service_account" "app" {
  account_id   = "orders-app"
  display_name = "Orders application"
}

resource "google_project_iam_member" "app_client" {
  for_each = toset(["roles/cloudsql.client", "roles/cloudsql.instanceUser"])
  project  = var.project
  role     = each.value
  member   = "serviceAccount:${google_service_account.app.email}"
}

resource "google_sql_database_instance" "orders" {
  name                = "orders-db"
  region              = var.region
  database_version    = "POSTGRES_16"
  deletion_protection = true

  settings {
    tier              = "db-custom-2-7680"
    edition           = "ENTERPRISE"
    availability_type = "REGIONAL"
    disk_type         = "PD_SSD"
    disk_size         = 100
    disk_autoresize   = true

    backup_configuration {
      enabled                        = true
      start_time                     = "21:00"
      point_in_time_recovery_enabled = true
      transaction_log_retention_days = 7

      backup_retention_settings {
        retained_backups = 14
        retention_unit   = "COUNT"
      }
    }

    ip_configuration {
      ipv4_enabled    = false
      private_network = data.google_compute_network.default.id
      ssl_mode        = "ENCRYPTED_ONLY"
    }

    database_flags {
      name  = "cloudsql.iam_authentication"
      value = "on"
    }

    insights_config {
      query_insights_enabled = true
    }

    user_labels = { owner = "orders-team" }
  }

  depends_on = [google_service_networking_connection.private]
}

resource "google_sql_database" "orders" {
  name     = "orders"
  instance = google_sql_database_instance.orders.name
}

# IAM database user for the app (for Postgres the service account name drops ".gserviceaccount.com")
resource "google_sql_user" "app" {
  name     = trimsuffix(google_service_account.app.email, ".gserviceaccount.com")
  instance = google_sql_database_instance.orders.name
  type     = "CLOUD_IAM_SERVICE_ACCOUNT"
}

# A read replica for reporting
resource "google_sql_database_instance" "orders_replica" {
  name                 = "orders-db-replica"
  region               = var.region
  database_version     = "POSTGRES_16"
  master_instance_name = google_sql_database_instance.orders.name
  deletion_protection  = false

  settings {
    tier    = "db-custom-2-7680"
    edition = "ENTERPRISE"

    ip_configuration {
      ipv4_enabled    = false
      private_network = data.google_compute_network.default.id
    }
  }
}

# pip install "cloud-sql-python-connector[pg8000]"
# Runs as the service account (or your own account with application default credentials). No password is stored.
import time

import pg8000
from google.cloud.sql.connector import Connector, IPTypes

INSTANCE = "my-project:asia-south1:orders-db"      # project:region:instance
DB_USER = "orders-app@my-project.iam"              # the IAM user, without .gserviceaccount.com
DB_NAME = "orders"

connector = Connector(refresh_strategy="lazy")     # "lazy" suits Cloud Run and other CPU-throttled hosts


def connect():
    """The connector checks IAM, encrypts the connection and sends an access token as the password."""
    return connector.connect(
        INSTANCE, "pg8000", user=DB_USER, db=DB_NAME,
        enable_iam_auth=True, ip_type=IPTypes.PRIVATE)


def place_order(conn, customer_id, total_cents):
    """Insert one order in a transaction and return its id."""
    cur = conn.cursor()
    try:
        cur.execute(
            "INSERT INTO orders (customer_id, total_cents) VALUES (%s, %s) RETURNING id",
            (customer_id, total_cents))
        order_id = cur.fetchone()[0]
        conn.commit()
        return order_id
    except Exception:
        conn.rollback()
        raise
    finally:
        cur.close()


def with_retry(action, attempts=3):
    """Retry on connection failures, which is what a failover or a maintenance restart looks like to the app."""
    for attempt in range(1, attempts + 1):
        conn = None
        try:
            conn = connect()
            return action(conn)
        except (pg8000.exceptions.InterfaceError, OSError):
            if attempt == attempts:
                raise
            time.sleep(2 * attempt)
        finally:
            if conn is not None:
                conn.close()


if __name__ == "__main__":
    try:
        print("Created order", with_retry(lambda c: place_order(c, 42, 129900)))
    finally:
        connector.close()

// Program.cs: connect through the Cloud SQL Auth Proxy and insert an order in a transaction
// NuGet package: Npgsql
// Start the proxy first (it signs in with IAM and encrypts the connection to the instance):
//   ./cloud-sql-proxy --private-ip --auto-iam-authn my-project:asia-south1:orders-db
using Npgsql;

var builder = new NpgsqlConnectionStringBuilder
{
    Host = "127.0.0.1",                   // the proxy listens here; it handles TLS and the IAM token
    Port = 5432,
    Database = "orders",
    Username = "orders-app@my-project.iam",
    SslMode = SslMode.Disable,            // only the hop to the local proxy is unencrypted
    Timeout = 5
};

await using var dataSource = NpgsqlDataSource.Create(builder.ConnectionString);
await using var connection = await dataSource.OpenConnectionAsync();
await using var transaction = await connection.BeginTransactionAsync();

const string sql = "INSERT INTO orders (customer_id, total_cents) VALUES (@customerId, @totalCents) RETURNING id";
await using var insert = new NpgsqlCommand(sql, connection, transaction);
insert.Parameters.AddWithValue("customerId", 42L);
insert.Parameters.AddWithValue("totalCents", 129900);

var orderId = (long)(await insert.ExecuteScalarAsync())!;
await transaction.CommitAsync();
Console.WriteLine($"Created order {orderId}");

Short walkthrough videos for this service are being prepared. They will appear here and load only when you press play. Until then, follow CloudBrum on YouTube for new videos.

Cloud SQL is the closest match to a single-writer managed database. When you outgrow one writer, Google points to Cloud Spanner for global scale and AlloyDB for faster PostgreSQL, while Firestore and Bigtable cover non-relational data. Applications that use it often run on Compute Engine or Cloud Run functions.