Scaling is how a database handles a larger workload, and there are two ways to do it. Horizontal scaling, also called scaling out, means adding more servers, instances, or nodes so the work is distributed across them. Vertical scaling, also called scaling up, means adding more compute such as CPU, GPU, or RAM to the servers you already have. The Professional Cloud Database Engineer exam expects you to know the difference between the two, and more specifically which method each managed database service supports, because the services do not all scale the same way.
Horizontal scaling expands a system outward. Instead of making any single machine more powerful, you add more identical machines and spread the load across them. This is good for distributing traffic and for keeping a system reliable, since the work no longer depends on one server. Vertical scaling goes the other direction. You keep the same machine and give it more resources, increasing its CPU, GPU, or memory so it can handle more work on its own. The advantage is that you can boost performance without changing the architecture of the system.
Both are standard strategies in cloud computing, and neither is strictly better. The right choice depends on the workload and on what the service actually allows. Serverless services on Google Cloud handle scaling for you. Some of them autoscale horizontally, some autoscale vertically, and some do both. Horizontal autoscaling is the more common of the two.
Once you have the two definitions, the useful work for the exam is mapping them onto specific services. Several Google Cloud databases support both methods, some support only one, and the serverless options take care of it on their own.
Cloud SQL supports both. You scale it vertically by increasing the number of vCPUs or the amount of RAM on an instance, which gives that single instance more power. You scale it horizontally by adding read replicas, which take read-only traffic off the primary and spread it across additional instances. The horizontal path for Cloud SQL is read-only, so it adds read capacity rather than write capacity.
AlloyDB works in a similar way. You scale vertically by adjusting the vCPUs and memory of the primary instance, and you scale horizontally by adding read pool instances, which are nodes built to serve read-only workloads at scale. As with Cloud SQL, the horizontal option here is for reads.
Spanner is built for large scale and treats scaling differently. It does not use traditional vertical scaling. Instead it scales horizontally by increasing the number of nodes in the instance, and it offers autoscaling so compute and storage expand without manual resizing. If a question describes Spanner and asks how to add capacity, the answer involves nodes, not changing the size of a single machine.
Bigtable follows the same horizontal-only pattern. To increase throughput or storage, you increase the number of nodes in the cluster, and autoscaling can adjust that node count based on demand. This lets it handle large workloads without resizing individual servers by hand.
Memorystore depends on which variant you are running. Standard Memorystore for Redis scales vertically, meaning you change the instance size. Memorystore for Redis Cluster scales horizontally, meaning you adjust the number of shards in the cluster. The two share a name but scale in opposite ways, which is the kind of distinction the exam tends to test.
The serverless options handle scaling automatically. Firestore scales horizontally by default as it grows, managing document storage and retrieval without capacity planning. BigQuery allocates compute based on query demand and complexity, so performance scales without managing any infrastructure.
A clean way to hold this for the Professional Cloud Database Engineer exam is to group the services by what they allow. Cloud SQL and AlloyDB scale both ways, with reads being the horizontal path through replicas or read pools. Spanner and Bigtable scale horizontally by node count and do not use vertical scaling. Memorystore splits by variant, with standard Redis scaling vertically and Redis Cluster scaling horizontally. Firestore and BigQuery are serverless and scale on their own. Knowing which bucket each service falls into is usually enough to separate the correct answer from the distractors, since the wrong choices often propose a scaling method the service does not actually support.
Our Professional Cloud Database Engineer course covers horizontal and vertical scaling alongside read replicas and per-service autoscaling behavior, with practice questions that drill these distinctions.
