A Cloud SQL instance is the fundamental unit of the service. It is a managed database running on a VM with attached persistent disk storage, and almost everything you provision in Cloud SQL builds out from that one instance. The Professional Cloud Database Engineer exam tends to test the limits and trade-offs of that provisioning rather than the click path for creating an instance, so it helps to be precise about how the pieces fit together. When your application grows, you add read replicas, which are copies of the primary instance that distribute read operations and reduce load on the main instance. To protect against zonal failures, a high availability configuration adds a standby VM in another zone with an identical setup. High availability is available for both primary instances and read replicas, and a cross-region read replica can carry its own high availability pair in a second region for global read traffic.
Cloud SQL machine types are similar to those in Compute Engine, but they are optimized for database workloads. They typically have a higher memory-to-CPU ratio, which matters for handling queries efficiently, and they are designed for high input and output operations per second, or IOPS, to support frequent reads and writes. One detail worth committing to memory is that Cloud SQL does not support autoscaling for CPU and memory. If an instance needs more compute, you scale up to a larger machine type manually when CPU or RAM approach their limits. There is no mechanism that grows the cores or memory of a running instance on its own.
Sizing those resources is not a matter of simply adding as much CPU and memory as the budget allows. For a fixed workload, adding cores reduces CPU utilization sharply at first, but the curve flattens. Past a certain point, more cores bring diminishing returns and have only a minor effect on utilization. Memory behaves the same way against RAM allocation, with a steep early drop in utilization that slows as you keep adding capacity. The practical takeaway is that increasing CPU and memory indefinitely does not produce proportional performance gains, and an exam scenario may frame a right-sizing decision around exactly that trade-off rather than around raw capacity.
The maximum storage capacity for a single Cloud SQL instance is 64 terabytes. That ceiling is a common decision point, because the right answer to a growth problem is sometimes to leave Cloud SQL rather than to keep scaling it. If your data has to exceed 64 terabytes, the choice among alternatives comes down to your consistency, compliance, and workload requirements. Spanner is the option when you still need strong consistency and full ACID compliance, with the caveat that it is more expensive, and it is built for large-scale, globally distributed data with consistency guarantees. Bigtable fits when NoSQL is acceptable and you still need strong consistency, since it is a highly scalable NoSQL database suited to analytics and high-throughput work but without full relational capabilities. BigQuery is the choice when your needs are analytical and you do not require strong consistency or ACID compliance, because it is built for OLAP workloads such as data warehousing and complex analytical queries.
Automatic storage increase is a Cloud SQL feature that lets an instance expand its storage capacity automatically when it is nearly full. The point of enabling it is to prevent the service disruptions that would otherwise occur when an instance runs out of space. It is not unlimited, though. The same 64 TB maximum still applies, and once an instance reaches that limit, manual intervention is required.
Two properties of this feature are worth keeping straight for the Professional Cloud Database Engineer exam, because they are easy to confuse. Automatic storage increase counts as vertical scaling, since it increases the capacity of an existing instance rather than adding new ones. It does not qualify as autoscaling, because the additional storage is never reclaimed. Once the storage grows, it stays at the expanded size, and there is no scale-down. We would treat any answer that describes this feature as autoscaling, or as something that can shrink an instance again, as incorrect.
Beyond the physical size of storage, there is a logical constraint on how many tables an instance can hold, and it is tied directly to the machine you provision. By default, an instance with less than 32 vCPUs or 200 GB of RAM has a limit of 50,000 tables. At that configuration the 50,000 limit is a hard boundary, because managing the metadata for tens of thousands of tables takes significant memory and processing power. You can raise the limit by upgrading the hardware. An instance with at least 32 vCPUs and 200 GB of RAM increases the table limit from 50,000 to 500,000, which gives much more headroom for large-scale data architectures. The reason for the jump is that larger machine types provide the overhead the database engine needs to track and manage a far larger number of table files efficiently. These specific numbers, 50,000 and 500,000 against the 32 vCPU and 200 GB threshold, are the kind of detail a question can hinge on.
Our Professional Cloud Database Engineer course covers Cloud SQL provisioning and resource allocation alongside high availability and read replicas, with practice questions that drill these distinctions.
