Cloud / Google Cloud SQL Interview questions

Cloud SQL is Google Cloud's fully managed relational database service for MySQL, PostgreSQL and SQL Server. You work with a normal database engine, but Google runs the servers, storage and most of the operational chores underneath it.

Google takes care of provisioning, OS and engine patching, automated backups, replication and failover. You still own the schema, indexes, query tuning, database users and network access rules.

It fits OLTP applications, web backends and lift-and-shift migrations where you want standard engine compatibility without babysitting VMs. When a single primary instance is no longer enough, AlloyDB or Spanner are the usual next steps.

Cloud SQL supports three engines, each with several major versions. Check the current version list before you plan an upgrade, because older versions are retired over time.

Features differ a little per engine. For example, some flags, extensions and replication options exist for one engine only, so read the engine-specific docs rather than assuming parity.

Cloud SQL comes in two editions: Enterprise and Enterprise Plus. Enterprise is the general-purpose default. Enterprise Plus targets workloads that need stricter availability and more performance headroom.

You pick the edition when you create the instance, and you can upgrade later. Plus costs more per vCPU, so use it where the SLA or latency actually matters.

The instance connection name is the unique identifier of a Cloud SQL instance, written as PROJECT_ID:REGION:INSTANCE_NAME. For example, shop-prod:us-central1:orders-db.

The Auth Proxy, language connectors and Cloud Run all use it to find the right instance. On Cloud Run the same string becomes the Unix socket path under /cloudsql/.

You can read it from the console or with this command:

gcloud sql instances describe orders-db --format="value(connectionName)"

Mixing up the order of project, region and name is a common cause of 'instance not found' errors.

Machine types decide how many vCPUs and how much memory your instance gets. For MySQL and PostgreSQL on the Enterprise edition you generally choose from these families:

• Shared-core (db-f1-micro, db-g1-small): cheap, for dev and test. Not covered by the SLA.
• Standard (for example db-n1-standard-4): balanced vCPU to memory ratio.
• High-memory (for example db-n1-highmem-8): more memory per vCPU for caching-heavy workloads.
• Custom (db-custom-CPUs-MEMORY_MB): you pick the exact vCPU and memory within allowed ratios.

Enterprise Plus uses its own performance-optimized types. Changing the machine type restarts the instance, so plan it for a quiet period.

Automated backups give you a scheduled safety net. Cloud SQL takes one backup per day inside a four-hour backup window you choose, and you can restore the data after accidental deletes, bad deployments or corruption.

By default the last 7 automated backups are kept, and you can raise that up to 365. Older ones are removed automatically.

Backups are also the base for point-in-time recovery, since PITR replays transaction logs on top of a backup. High availability on MySQL and PostgreSQL depends on them being enabled too.

Automated backups are deleted with the instance, so keep a final backup or an export in Cloud Storage if the data must outlive it.

A read replica is a copy of the primary instance that receives changes asynchronously and serves read-only traffic. It lets you move reporting queries and read-heavy endpoints off the primary.

Replicas can live in the same region, in another region, or even outside Google Cloud as an external replica. You create one with:

gcloud sql instances create orders-db-r1 \
  --master-instance-name=orders-db \
  --region=us-east1

Because replication is asynchronous, a replica can lag behind. Do not send reads there if the user must see their own write instantly.

High availability is turned on by choosing the regional availability type. Cloud SQL then runs a standby in a second zone of the same region.

1. Make sure automated backups are enabled, plus binary logging for MySQL or PITR for PostgreSQL.
2. Set the availability type to REGIONAL at creation, or patch an existing instance.
3. Confirm in the console that a standby zone is shown, and test it with a manual failover.

gcloud sql instances patch orders-db --availability-type=REGIONAL

Enabling it on a running instance can cause a brief interruption, so schedule it for a quiet period. Expect the instance cost to roughly double because a standby is provisioned.

Use gcloud sql instances create with the engine version, tier and region. A typical PostgreSQL example:

gcloud sql instances create orders-db \
  --database-version=POSTGRES_16 \
  --edition=ENTERPRISE \
  --tier=db-custom-2-7680 \
  --region=us-central1 \
  --storage-type=SSD \
  --storage-size=50GB \
  --storage-auto-increase \
  --backup-start-time=02:00

Here db-custom-2-7680 means 2 vCPUs and 7680 MB of memory. Add --availability-type=REGIONAL for HA, and set the postgres password afterwards with gcloud sql users set-password.

Creation takes a few minutes, and the Cloud SQL Admin API must be enabled in the project first.

The Cloud SQL Auth Proxy is a small client-side program that opens a secure tunnel from your application to a Cloud SQL instance. Your app connects to 127.0.0.1 and the proxy handles the rest.

It authenticates with IAM credentials, encrypts traffic with TLS, and removes the need to allowlist client IP addresses or manage server certificates yourself.

./cloud-sql-proxy --port 5432 shop-prod:us-central1:orders-db
psql "host=127.0.0.1 port=5432 user=app dbname=orders"

The caller needs the Cloud SQL Client role, and the Cloud SQL Admin API must be enabled.

There is no single 'right' way. The choice depends on where the client runs and how strict your network policy is.

In production, most teams combine private connectivity with the proxy or a connector for IAM-based authorization.

A maintenance window is the one-hour slot, chosen by day of week and hour (UTC), in which Cloud SQL prefers to apply updates such as OS patches and engine minor versions.

If you do not set one, maintenance can start at any time. Setting it makes downtime predictable. During maintenance a non-Plus instance restarts, which interrupts connections for a short time.

gcloud sql instances patch orders-db \
  --maintenance-window-day=SUN \
  --maintenance-window-hour=3

You can also pick whether the instance receives updates earlier or later in the rollout, which is handy for putting staging ahead of production.

Database flags are the Cloud SQL way of setting engine parameters, such as max_connections or slow_query_log. They replace editing my.cnf or postgresql.conf, since you have no file system access.

gcloud sql instances patch orders-db \
  --database-flags=max_connections=500,log_min_duration_statement=500

Only supported flags are accepted, and values are validated. Some flags apply immediately while others need a restart, so check the flag's page before changing it in production.

Note that --database-flags replaces the whole set. Include every flag you want to keep.

Both operations go through Cloud Storage. You export a SQL dump or CSV into a bucket, or import one from a bucket. The instance's service account needs access to that bucket.

# export
gcloud sql export sql orders-db gs://shop-backups/orders.sql.gz --database=orders --offload

# import
gcloud sql import sql orders-db gs://shop-backups/orders.sql.gz --database=orders

The --offload flag runs the export on a temporary serverless instance so the primary is not slowed down. For CSV use export csv with a --query.

For very large or continuous moves, Database Migration Service is a better fit than dumps.

Query Insights is the built-in tool for finding slow or heavy queries without installing anything. It shows database load broken down by query, user, database and client address, so you can see which statement is responsible for a CPU spike.

You can drill into a normalized query to view its latency over time and, on PostgreSQL, sample query plans. Adding sqlcommenter tags in your app code links a query back to the application route or controller that issued it.

Enable it from the console or with a flag, and review it first when users report slowness.

Point-in-time recovery (PITR) lets you rebuild an instance's data as it was at a specific second, such as one minute before a bad DELETE ran.

It works by combining a backup with continuous transaction logs: binary logs on MySQL and write-ahead logs on PostgreSQL. You must have automated backups and PITR (log retention) turned on beforehand, because you cannot recover to a time the logs do not cover.

gcloud sql instances clone orders-db orders-db-recovered \
  --point-in-time="2026-10-22T09:14:00Z"

The result is always a new instance. The original is not rolled back.

Stopping is done by setting the activation policy to NEVER, and starting by setting it to ALWAYS.

gcloud sql instances patch dev-db --activation-policy=NEVER   # stop
gcloud sql instances patch dev-db --activation-policy=ALWAYS  # start

While stopped, you do not pay for vCPU and memory, but storage and any reserved static IP are still billed. Data is preserved. Existing connections drop immediately.

This is a common cost saver for development databases, often automated with Cloud Scheduler. Do not use it for production, since a stopped instance serves nothing.

Database Migration Service (DMS) is Google's managed tool for moving databases into Cloud SQL (and AlloyDB) with little downtime. It supports MySQL, PostgreSQL and SQL Server sources, from on-premises, other clouds or Compute Engine.

A migration job first copies a full snapshot, then keeps applying ongoing changes (change data capture) until you are ready to cut over. At that point you stop writes on the source, let the destination catch up, and promote it.

You still need to check source prerequisites, such as binary logging enabled for MySQL and network connectivity between source and destination.

Both run the same engines. The difference is who carries the operational work and how much low-level control you keep.

Pick self-managed only when you need an unsupported extension, custom plugin or OS-level tuning. Otherwise Cloud SQL saves a lot of toil.

They solve different problems. HA protects you from a zone failure. Read replicas help you scale reads and prepare for regional disasters.

Production systems usually combine them: HA on the primary and one or more replicas for reads and DR.

A regional instance has a primary in one zone and a standby in another zone of the same region. Both attach to a regional persistent disk, which synchronously replicates every write across the two zones. A committed transaction is therefore on both zones' storage before it is acknowledged.

Cloud SQL watches the primary through health checks. If it stops responding, or its zone fails, the standby starts the engine on the same data and takes over. Clients keep using the same IP address.

flowchart LR
  A[App] --> B["Primary in zone A"]
  B --> C["Regional persistent disk"]
  C --> D["Replicated copy in zone B"]
  E["Standby in zone B"] -.-> D
  B -. health check fails .-> E
  E --> A

The standby does not serve reads. For read scaling you still need read replicas.

Existing connections are dropped, and any transaction that had not committed is rolled back. Committed transactions are safe because of the synchronous regional disk.

The standby then becomes the primary and the instance becomes reachable again, usually within a minute or two. It keeps the same IP address and connection name, so you do not change configuration.

Your application must handle the interruption:

1. Catch connection errors and retry with exponential backoff.
2. Make writes idempotent so a retry does not duplicate data.
3. Use a connection pool that discards broken connections.

You can rehearse with gcloud sql instances failover orders-db. Once the old zone recovers, the instance can move back, and a manual failback is possible.

Private IP keeps database traffic on Google's internal network. The instance gets an internal address from your VPC's reserved range, so it is never exposed to the public internet.

• Security: no public attack surface and no authorized-network lists to maintain.
• Latency: traffic stays inside Google's network and avoids internet hops.
• Compliance: many policies require databases to have no public address.

It is set up through private services access, which allocates an IP range and creates a VPC peering with Google's service producer network. Two things to remember: private IP cannot be removed from an instance once enabled, and you can still disable the public IP separately.

Private services access (PSA) connects your VPC to the VPC that Google manages for Cloud SQL. You reserve an IP range, then create a peering with servicenetworking.googleapis.com. Cloud SQL carves instance addresses out of that range.

flowchart LR
  A["Your VPC"] -- reserved range --> B["VPC peering"]
  B --> C["Google managed service VPC"]
  C --> D["Cloud SQL instance private IP"]

gcloud compute addresses create google-managed-services \
  --global --purpose=VPC_PEERING --prefix-length=16 --network=prod-vpc

gcloud services vpc-peerings connect \
  --service=servicenetworking.googleapis.com \
  --ranges=google-managed-services --network=prod-vpc

Peering is not transitive. On-premises networks reaching Cloud SQL through a VPN need custom route advertisement, otherwise only the peered VPC can connect.

Both give private connectivity, but through different mechanisms.

Choose PSC when many VPCs or projects need access, or when peering limits and IP planning are painful. PSA remains simple for a single VPC.

The proxy secures a connection in three steps, none of which you manage by hand.

1. It reads IAM credentials (a service account or user) and asks the Cloud SQL Admin API for a short-lived client certificate, valid for about an hour.
2. It opens a TLS connection to the instance's proxy port (3307 on the server side) and verifies the server identity against the instance's CA.
3. It refreshes the certificate before it expires, so long-running apps stay connected.

Because authorization is based on IAM, you do not need authorized networks or hand-installed SSL certificates. The client IP can change freely.

The tunnel only protects the transport. You still log in with a database user, unless you also enable IAM database authentication.

With IAM database authentication, a Google identity logs in to the database using a short-lived OAuth 2.0 access token as the password instead of a stored secret.

1. Turn on the flag: cloudsql.iam_authentication=on for PostgreSQL or cloudsql_iam_authentication=on for MySQL.
2. Add the IAM user or service account as a database user of type IAM.
3. Grant the identity Cloud SQL Instance User (to log in) and Cloud SQL Client (to connect).
4. Connect with the Auth Proxy using --auto-iam-authn, or a language connector with IAM auth enabled.

Tokens last about an hour, which is why the proxy or connector refreshes them for you. Then access is revoked centrally through IAM, and there are no passwords to rotate in app config.

The simplest path uses the built-in Cloud SQL connection on Cloud Run, which mounts a Unix socket into the container.

gcloud run deploy orders-api \
  --image=us-docker.pkg.dev/shop-prod/app/orders:latest \
  --add-cloudsql-instances=shop-prod:us-central1:orders-db \
  --service-account=orders-sa@shop-prod.iam.gserviceaccount.com

The service account needs Cloud SQL Client. In your code, connect to the socket path /cloudsql/shop-prod:us-central1:orders-db (for PostgreSQL, use it as the host).

Alternatively, use private IP with Direct VPC egress or a serverless VPC connector, or the language connector inside the app. Keep each instance's connection pool small, since many Cloud Run instances multiply the total connection count.

The standard pattern is to run the Auth Proxy as a sidecar container in the same pod and authenticate it with Workload Identity, so no key files are stored in the cluster.

1. Create a Google service account with the Cloud SQL Client role.
2. Bind it to the Kubernetes service account used by the pod via Workload Identity.
3. Add the proxy as a sidecar and point the app at localhost.

containers:
  - name: app
    image: orders-api:1.4
    env:
      - name: DB_HOST
        value: "127.0.0.1"
  - name: cloud-sql-proxy
    image: gcr.io/cloud-sql-connectors/cloud-sql-proxy:VERSION
    args:
      - "--private-ip"
      - "--port=5432"
      - "shop-prod:us-central1:orders-db"
    securityContext:
      runAsNonRoot: true

Pin a current 2.x version of the image. For Kubernetes Jobs, use the proxy's --quitquitquit endpoint, otherwise the sidecar keeps the Job from finishing.

A good habit is to take an on-demand backup just before a migration or deployment, so you have a precise rollback point. For anything that must outlive the instance, export to Cloud Storage or take a final backup before deleting it.

gcloud sql backups create --instance=orders-db --description="before v2.3 schema change"

Cloud SQL does not rewind your running instance. It builds a new instance containing data as of the timestamp you pick.

flowchart TD
  A["Choose recovery timestamp"] --> B["Pick latest backup before that time"]
  B --> C["Create new instance from backup"]
  C --> D["Replay binary logs or WAL up to the timestamp"]
  D --> E["New instance ready"]
  E --> F["Cut over app or copy back lost rows"]

The timestamp must fall inside the log retention period (up to 7 days on Enterprise and up to 35 on Enterprise Plus) and cannot be in the future. The new instance gets its own IP and name, and read replicas are not carried over.

A practical tip: if only a few rows were lost, recover to a new instance and copy those rows back, rather than switching the whole application.

List the backups, then restore one into a target instance. The target's current data is overwritten, so be sure you picked the right one.

gcloud sql backups list --instance=orders-db

gcloud sql backups restore 1698000000000 \
  --backup-instance=orders-db \
  --restore-instance=orders-db-staging

• The target must use the same engine, and a compatible database version.
• Its storage must be at least as large as the source's.
• The target is unavailable while the restore runs.
• Restoring across projects is possible with the right permissions.

For a safer approach, restore into a freshly created instance so production data is never at risk. Refreshing a staging database this way is a common use.

A cross-region replica keeps an asynchronously updated copy of your data in a different region. If the primary's region goes down, you promote that replica to a standalone primary and point the application at it.

Two points matter in an interview. First, replication is asynchronous, so your recovery point objective is not zero. A few seconds of recent writes may be missing. Second, promotion is a manual, one-way step unless you use the advanced DR features of Enterprise Plus, which add planned switchover and replica failover with the original replica relationship restored afterwards.

1. Detect the regional outage and stop traffic to the old primary.
2. Promote the cross-region replica.
3. Update application endpoints or DNS.
4. Enable backups and HA on the new primary, then create new replicas.

Cross-region traffic also adds some egress cost and latency, so size the replica for the full production load, not only reads.

Promotion detaches the replica from its primary and turns it into a standalone, writable instance. It is irreversible: the instance never becomes a replica of the old primary again.

gcloud sql instances promote-replica orders-db-r1

1. Stop or pause writes on the primary, if it is still running.
2. Wait for replica lag to reach zero to avoid losing data.
3. Run the promote command.
4. Update your application to use the promoted instance.
5. Turn on automated backups and HA, and create new replicas.

Typical reasons are disaster recovery, a region migration, or creating an independent copy for testing.

Start by watching the metric database/replication/replica_lag, then look for the cause. Typical fixes:

• Size the replica properly. It should be at least as powerful as the primary. An undersized replica cannot apply changes fast enough.
• Break up huge writes. One massive update or delete creates a big transaction the replica applies serially. Do it in batches.
• Add primary keys. On MySQL, row-based replication of tables without a primary key is very slow.
• Enable parallel replication. On MySQL, increase parallel replica workers using the relevant flags.
• Watch long replica queries. On PostgreSQL, queries conflicting with replay can stall it. Review max_standby_streaming_delay and hot_standby_feedback, and weigh their trade-offs.
• Check the network. Cross-region replicas depend on inter-region latency and bandwidth.

Alert on lag so you notice before users read stale data.

Work from the symptom to the query, not the other way round.

1. Confirm the spike in Cloud Monitoring (database/cpu/utilization) and note when it began. Correlate with a deployment or traffic change.
2. Open Query Insights and sort by load to find the heaviest queries.
3. Inspect live activity to catch runaway sessions.
4. Use EXPLAIN on the suspects. Look for sequential scans, missing indexes and bad joins.
5. Check connection counts. A connection storm or a retry loop burns CPU.
6. Fix the query or index first. Scale up only if the workload is legitimately larger, and push reads to a replica.

-- PostgreSQL
SELECT pid, state, now() - query_start AS runtime, query
FROM pg_stat_activity WHERE state <> 'idle' ORDER BY runtime DESC;

-- MySQL
SHOW FULL PROCESSLIST;

Throwing a bigger machine at an unindexed query only delays the problem.

The error means the instance reached its max_connections limit, which depends on the instance's memory. First find out who is holding connections.

-- PostgreSQL
SELECT state, count(*) FROM pg_stat_activity GROUP BY state;

-- MySQL
SHOW STATUS LIKE 'Threads_connected';

• Many idle connections point to missing pooling or leaked connections in the application.
• Cloud Run or GKE autoscaling can multiply pools. Pool size times instance count must stay under the limit.
• A pooler such as PgBouncer or ProxySQL lets thousands of clients share a few database connections.
• Raising max_connections helps only if memory allows, since each PostgreSQL connection costs memory.
• Scaling up the instance raises the default limit.

Long-term, fix the application's pooling and cap concurrency rather than only raising the limit.

When it is enabled, Cloud SQL watches free disk space and, once it falls below an internal threshold, adds storage automatically without downtime. The threshold scales with the current disk size.

There are some important points:

• The increase is permanent. Cloud SQL cannot shrink a disk afterwards, and you pay for the larger size.
• You can set a ceiling with --storage-auto-increase-limit to stop runaway growth.
• If the limit is reached or auto-increase is off, a full disk makes writes fail.
• Alert on database/disk/utilization at about 80%.

gcloud sql instances patch orders-db --storage-auto-increase --storage-auto-increase-limit=500

If you need to reduce disk size, the only route is migrating the data to a new, smaller instance with export and import or DMS.

Choose Enterprise Plus when downtime and latency have a clear business cost. The upgrade makes sense in these situations:

• You need a 99.99% SLA that includes maintenance, rather than 99.95% excluding it.
• Planned maintenance must be near-zero downtime, under a second for the switch.
• The workload is read-heavy and its working set exceeds memory, so the Data Cache pays off.
• You need longer PITR, up to 35 days of log retention.
• You want advanced disaster recovery, such as planned switchover between regions.
• You need higher-performance machine types for steady heavy load.

For internal tools, dev environments and moderate workloads, Enterprise is usually enough and cheaper. Compare the monthly cost difference against the cost of an hour of downtime.

Data Cache adds a layer of local SSD between memory and the persistent disk. Hot data pages that no longer fit in RAM are kept on the local SSD, so reads avoid the slower network-attached disk.

It helps most for read-heavy workloads whose working set is bigger than memory but smaller than the whole database. You choose the cache size, and it is part of the instance, so it works on the primary and on replicas where configured.

• Lower read latency for hot data.
• Fewer reads hitting the persistent disk, so more stable performance.
• No application change is needed.

It does not help write-heavy workloads or a working set that already fits in memory, so measure the cache hit ratio and read latency before paying for it.

You cannot eliminate maintenance, but you can control when it hits and how much it hurts.

• Set a maintenance window in your quietest hour so updates do not surprise you.
• Use a deny maintenance period, up to 90 days, to block updates around events like a sale or year-end close.
• Choose the rollout timing so staging receives updates before production.
• Watch the maintenance notifications and use self-service reschedule when a window is inconvenient.
• Use Enterprise Plus, where planned maintenance means near-zero downtime.
• Make clients resilient with retries and connection pool validation.

Deny periods only delay updates, so you cannot skip them forever. Test the application behavior against a restart in staging.

By default Google encrypts all Cloud SQL data with Google-managed keys. With CMEK, you control the key in Cloud KMS.

1. Create a key ring and key in Cloud KMS, in the same region as the instance.
2. Create the Cloud SQL service identity for the project.
3. Grant that service identity the Cloud KMS CryptoKey Encrypter/Decrypter role on the key.
4. Create the instance with the key.

gcloud beta services identity create --service=sqladmin.googleapis.com

gcloud sql instances create orders-db \
  --database-version=POSTGRES_16 --region=us-central1 --tier=db-custom-2-7680 \
  --disk-encryption-key=projects/shop-prod/locations/us-central1/keyRings/sql/cryptoKeys/orders

CMEK must be chosen when the instance is created, so existing instances cannot be switched over. You would migrate data into a new one. Replicas need a key in their own region. Disabling or destroying the key makes the data unreadable, so protect it.

Auditing has two layers, and interviewers like to hear both.

For PostgreSQL, enable the flag cloudsql.enable_pgaudit=on, set pgaudit.log (for example ddl,write), then create the extension:

CREATE EXTENSION pgaudit;

Entries go to Cloud Logging, where you can route them to BigQuery or a SIEM. Using IAM database authentication makes the audit trail attributable to real identities rather than a shared app user.

AlloyDB is a PostgreSQL-compatible service built for heavier workloads, whereas Cloud SQL is the simpler general-purpose choice.

Pick Cloud SQL for typical OLTP, or when you need MySQL or SQL Server. Pick AlloyDB when a PostgreSQL workload needs more throughput, mixed analytics, or faster scaling of reads.

Choose Spanner when the database must scale horizontally or span regions. Cloud SQL is built around a single primary that scales vertically.

If a single well-sized primary and a few replicas do the job, stay on Cloud SQL. Move to Spanner for global users, extreme write volume or five-nines requirements.

For anything larger than a small database, use Database Migration Service with continuous replication, so downtime is limited to the cutover.

flowchart LR
  A["Assess source"] --> B["Create Cloud SQL destination"]
  B --> C["Create connection profile"]
  C --> D["Create and test migration job"]
  D --> E["Full copy then change replication"]
  E --> F["Stop writes and let lag reach zero"]
  F --> G["Promote and switch app"]

1. Assess: check versions, storage engines and unsupported features.
2. Prepare the source: enable binary logging in row format, create a replication user, and open connectivity (VPN, IP allowlist or reverse tunnel).
3. Create the destination and the migration job, and run the test.
4. Start the job, then monitor lag.
5. Cut over: stop writes, wait for zero lag, promote, repoint the application.
6. Validate row counts and application behavior before decommissioning the source.

For a small database where downtime is acceptable, a plain mysqldump and import is simpler.

Most savings come from matching the instance to the real workload and cleaning up what is idle.

• Right-size vCPU and memory using monitoring data and the recommender suggestions.
• Stop non-production instances at night, for example with Cloud Scheduler. Storage is still billed.
• Use shared-core machines for dev and test, but never production, since they have no SLA.
• Buy committed use discounts for steady production instances.
• Skip HA and Enterprise Plus where the SLA is not needed.
• Delete unused replicas, old on-demand backups and abandoned clones.
• Set a storage auto-increase limit and clean up big tables. Disks cannot shrink.
• Keep replicas and clients in the same region to avoid egress charges.

Review the bill by SKU monthly. Storage and replicas often hide the surprises.

Cloud SQL scales mostly up, and it scales reads out. It does not scale writes horizontally.

• Vertical: change the machine type with gcloud sql instances patch --tier. This restarts the instance, so do it in a quiet period.
• Storage: disk can be increased without downtime (and automatically). It cannot be reduced.
• Read scaling: add read replicas and route read-only queries to them in the application.
• Caching and pooling: put Memorystore in front of hot reads and use a connection pooler.
• Data design: add indexes, partition large tables, and archive old data.

gcloud sql instances patch orders-db --tier=db-custom-8-32768

When a single primary no longer keeps up with writes, the options are application-level sharding or moving to AlloyDB or Spanner.

Cloud SQL trades control for convenience. The main restrictions to remember:

• No OS or shell access. You cannot SSH in or touch the file system.
• No true superuser. MySQL has no SUPER privilege, and PostgreSQL uses the cloudsqlsuperuser role.
• Limited extensions and plugins. Only supported ones can be installed, and custom ones cannot.
• Supported flags only. Some engine parameters cannot be changed.
• Single primary. There is no multi-primary writing, and HA is within one region.
• Size limits. Storage and connection counts have caps that depend on the machine.
• Some changes restart the instance, for example machine type changes and certain flags.

If a requirement collides with these, self-managed on Compute Engine, AlloyDB or Spanner may fit better. Check restrictions early, before committing a migration plan.

Cloud SQL publishes metrics under cloudsql.googleapis.com automatically. Build a dashboard and alert policies around the metrics that predict trouble first.

Combine metrics with Cloud Logging for error logs and slow query logs (enabled by flags such as log_min_duration_statement), and Query Insights for query-level detail. Route alerts to email, Slack or PagerDuty with notification channels.