If you're studying for the Professional Cloud Architect exam, Cloud SQL machine types are one of those topics that looks like a Compute Engine question but isn't. The shape of the question is different, and so is the answer. I'll walk through what's actually different about Cloud SQL machine types and what you should remember when a scenario asks you to size or rescale a managed relational database.
Cloud SQL runs on the same underlying infrastructure as Compute Engine, but the machine types you pick when you provision an instance are not the same general-purpose shapes you'd choose for a web server or a stateless worker. They are optimized for relational database workloads, which means two specific things.
First, the memory-to-CPU ratio is higher than what you'd typically pick on Compute Engine. Relational query engines spend a lot of time holding working sets, indexes, and buffer pools in memory. If memory is undersized relative to CPU, the engine spills to disk and your latency falls off a cliff. Cloud SQL's machine types lean toward more RAM per vCPU so that the buffer pool can stay hot.
Second, the storage layer is provisioned for high IOPS. Cloud SQL is designed around frequent reads and writes hitting persistent disk, and the IOPS budget scales with the size of the disk you allocate. This matters on the exam because a question that says "queries are fast in isolation but slow under load" is often pointing at IOPS pressure, not CPU.
This is the single most important behavioral fact about Cloud SQL machine types for the Professional Cloud Architect exam. Cloud SQL does not autoscale CPU or memory. If your workload outgrows the machine type you picked, you change the machine type manually, which is an offline operation that requires the instance to restart.
Storage is the exception. Cloud SQL can automatically grow storage when you enable that setting, so you don't have to wake up to a full disk. But the compute side of the instance is fixed at the size you provisioned until you intervene.
The exam exploits this in two common ways. One pattern is a scenario describing a workload with predictable spikes, asking what to do. The instinct from Compute Engine land is to reach for autoscaling, and that instinct is wrong here. The right answer is either to size the instance for the peak, to use read replicas to absorb read traffic, or to plan a maintenance window for a manual machine type change. The other pattern is a scenario describing a workload that has grown over time and is now CPU bound. The expected answer is a manual machine type upgrade, not a configuration change to enable autoscaling that doesn't exist.
When you scale up the number of CPU cores or the amount of RAM allocated to a Cloud SQL instance, the relationship between resources and utilization is non-linear. Going from a small instance to a moderately larger one can produce a sharp drop in CPU utilization or memory pressure. Going from a moderately large instance to a very large one produces much smaller incremental gains.
This matters operationally because oversizing a Cloud SQL instance is expensive and doesn't always give you the headroom you think you're paying for. Beyond a point, adding cores doesn't proportionally reduce utilization, and the same is true for RAM once the working set fits comfortably in the buffer pool. The architectural takeaway is to size for the working set and the concurrency you actually have, then validate with monitoring rather than buying a bigger box and hoping.
On the Professional Cloud Architect exam, this rarely shows up as a calculation question. It shows up as the reason why the right answer is "add a read replica" or "shard the workload" rather than "double the machine type". Once a Cloud SQL instance is already sized reasonably for its working set, scaling further usually means scaling out, not scaling up.
Three things carry most of the weight on Professional Cloud Architect questions about Cloud SQL machine types. Cloud SQL machine types are memory-heavy and IOPS-heavy compared to general-purpose Compute Engine shapes. There is no CPU or memory autoscaling, only manual machine type changes and automatic storage growth. And scaling up has diminishing returns past a certain point, so scenarios that imply "we need more capacity" often want a read replica or an architecture change rather than a bigger instance.
My Professional Cloud Architect course covers Cloud SQL machine types alongside the rest of the databases material.
