Design, migrate, and run scalable, highly available databases on Google Cloud across relational and NoSQL services, and track your readiness for the Professional Cloud Database Engineer exam.
Prepare and test your skills
Prepare and test your skills
Vertical scaling is the practice of increasing the resources of a single database instance to handle more load. Cloud SQL (opens in a new tab) scales vertically by adding vCPUs, memory, and storage to one primary instance. Larger resources improve compute capacity and storage throughput, but changes to CPU and memory can restart the instance and briefly interrupt connections. Vertical scaling therefore requires both correct sizing and operational planning for maintenance.
Instance sizing for Cloud SQL means matching vCPUs, memory, disk size, throughput, and IOPS to the workload so performance stays stable. Incorrect sizing can cause slow queries, database errors, long migration times, and application slowdowns. Correct sizing starts with assessment of the source workload and selection of a target configuration that covers peak demand:
An instance constrained on CPU or memory shows slow inserts, updates, or deletes and high memory pressure. Cloud Monitoring (opens in a new tab) provides predefined dashboards and the total usage metric to compare database memory use against operating system cache use. This comparison identifies under-provisioned or over-provisioned instances. If an instance is already at maximum memory size, vertical scaling is no longer possible and the data must be sharded across multiple instances.
Storage performance in Cloud SQL depends directly on the combination of disk size and number of vCPUs. A larger disk provides higher throughput and IOPS, while a larger machine type with more vCPUs lets the instance use that storage performance. CPU and storage must therefore be scaled together rather than in isolation. Storage type also controls the balance of cost and performance, and automatic storage increases can expand capacity as data grows.
| Storage type | Performance profile | Choose when |
|---|---|---|
| SSD | Most efficient and cost-effective for general use | The workload needs consistent latency and high IOPS |
| HDD | Lower cost for large, cold data | Datasets are 10 TB or larger, latency-insensitive, or infrequently accessed |
Cloud SQL Enterprise Plus (opens in a new tab) raises vertical limits with larger machine configurations and a data cache that improves read performance. For imports on small instances, temporarily increasing CPU and RAM speeds loading of large datasets, then the instance can be scaled back down. Table counts also affect upgrades, so keep below 500 databases per instance and fewer than 50,000 tables per instance, or 500,000 tables only with 32 or more cores and 200 GB or more memory. Instances should also keep at least 20% free disk space for maintenance operations that Cloud SQL performs.
Exam tip: Changing Cloud SQL memory size requires an instance restart, while enabling automatic storage increases lets storage grow without a manual resize — keep at least 20% free disk space and alert on disk utilization.
Maintenance windows in Cloud SQL control when disruptive updates, resource modifications, and system maintenance can occur on the primary instance. During maintenance the instance becomes unavailable for a brief period and existing connections are dropped. Applications must use connection pooling, exponential backoff, and small transactions so they reconnect cleanly after the interruption. Operational discipline reduces risk during vertical scaling.
Configure a maintenance window for the primary instance, test application behavior with self-service maintenance and manual failover, and create a metrics-based alerting policy for disk utilization below 20% free space. Do not start a new administrative operation before the previous operation has completed, because overlapping changes can extend downtime and cause failures.
Trade-offs in consistency, latency, and cost describe how the choice between regional and multi-regional scaling changes guarantees, response speed, and spending. A regional deployment keeps data close together for lower cost and lower latency but cannot survive a region loss without recovery work. A multi-regional deployment keeps copies in separate geographic locations for higher availability and stronger consistency across regions but adds replication, transfer, and capacity costs plus longer write paths.
Regional versus multi-regional deployments differ in locational scope, failure coverage, and operating cost. A regional deployment places primary resources and standby copies in different zones of one region, so traffic stays within the region and latency and cross-region transfer costs stay low. A multi-regional deployment spreads application tiers and database replicas across at least two regions and three zones within each region, so the system can withstand zone and region outages but must pay for extra capacity, replication, and cross-region networking.
Google Cloud guidance prefers resources with wider locational scope when resilience matters: use regional resources instead of zonal resources, and use multi-regional or global resources instead of regional resources. In each region, leverage three zones rather than two and overprovision capacity by a third more than the estimate so surviving zones can absorb failover traffic. Distribute user traffic across regions with Cloud DNS (opens in a new tab) and regional load balancers, or a global load balancer depending on requirements, and store data in multi-region services like Spanner (opens in a new tab) and Cloud Storage (opens in a new tab) when data replication is critical.
Region selection itself involves competing goals:
The most cost-efficient region might not have the lowest latency or lowest carbon footprint, so the choice balances performance, compliance, and budget.
Consistency and replication behavior depend on whether scaling stays within one region or extends across regions. High availability (HA) generally applies to regional deployments and uses synchronous replication between zones within a single region by default, which supports zero or near-zero recovery time objective (RTO) and recovery point objective (RPO). Disaster recovery (DR) generally applies to multi-region deployments without multi-regional services and typically uses asynchronous replication, which requires a defined replication strategy and manual or semi-automated failover.
Managed database services implement this split in different ways. Cloud SQL (opens in a new tab) configured for HA is a regional instance with a primary instance and a standby instance in primary and secondary zones, with automatic failover from primary to standby. Cloud SQL cross-region read replicas can be promoted to standalone instances after a disaster, read replicas can be configured for HA in advance, and read replicas can have their own cascading cross-region replicas for immediate protection after promotion. Spanner as a regional configuration maintains three read-write replicas, each in a different zone of that region, where each replica holds a full copy able to serve read-write and read-only requests so a single-zone failure leaves the database available.
Other storage services show the same regional to multi-regional pattern. Bigtable production instances have a minimum of two clusters in unique zones of a region, replication between clusters is automatically managed by Google with a separate independent copy in each zone, and incoming traffic can fail over to another cluster in the same instance. Firestore in a regional location operates in a multi-zone replicated configuration, while Firestore in a multi-region location operates in a multi-zone and multi-region replicated configuration that can withstand loss of entire regions. Cloud Storage regional buckets replicate data synchronously across zones in the region, while dual-region or multi-region buckets store data redundantly in at least two geographic locations where metadata is written synchronously and data is replicated asynchronously.
| Deployment pattern | Replication | Consistency and recovery |
|---|---|---|
| Regional HA | Synchronous replication between zones in one region | Zero or near-zero RTO and RPO with automatic failover |
| Cross-region replicas for DR | Typically asynchronous replication to another region | Higher RTO and nonzero RPO with promote-and-failover steps |
| Multi-regional active-active | Built-in redundancy and synchronization across regions | Strong consistency across regions with minimal manual recovery |
For dual-region buckets, turbo replication provides replication across the region pair with an RPO of 15 minutes. A Spanner multi-region deployment provides a consistent environment across multiple regions with two read-write regions and one witness region containing a witness replica.
Exam tip: HA means synchronous replication within one region with zero or near-zero RTO and RPO, while DR across regions is typically asynchronous unless the workload uses a managed multi-regional service like Spanner or Cloud Storage.
Latency effects come from the distance between writers, readers, and database copies. Sending data over long distances introduces latency for slow inserts, updates, or deletes, so the locations of the writer and the database must be checked together. Reader location also matters because latency affects read performance more than write performance, which makes cross-region reads and distant primaries a direct scaling cost even when throughput looks sufficient.
Aggregate availability falls as more dependent tiers are chained together. The aggregate availability of a chained multi-tier stack is tier1_availability x tier2_availability x tierN_availability, so four tiers at 99.9% each yield only about 99.6% overall. Parallelized services use 1 minus (1 minus A) x (1 minus B), so two 99% services in parallel yield 99.99% because each service runs independently, while the same two services chained yield only 98%. Choosing parallelization over chaining where feasible therefore raises end-to-end availability without adding another nine to every component.
Cost and performance scaling decisions weigh larger single instances against more replicas and wider geographic coverage. Scaling up means ensuring the instance is not constrained on memory or CPU, with at least 60 GB of memory for performance-intensive workloads, optimizing expensive queries with Query Insights, and considering Cloud SQL Enterprise Plus edition for higher machine limits, data cache, higher availability, and near-zero downtime maintenance. Scaling out means adding read replicas for read-heavy workloads, adding Bigtable clusters or Spanner replicas for regional and multi-regional coverage, and using autoscaling stateless managed instance groups for the application tier.
Higher availability generally costs more because extra zones, regions, replicas, and overprovisioned capacity must be paid for continuously. Three nines of availability at 99.9% allows about 86 seconds of downtime in 24 hours, while two nines at 99% allows 864 seconds, which is ten times more downtime for a lower price. Cost controls include rightsizing with Cloud Monitoring dashboards and machine-type recommendations, removing HA or DR from instances that do not need it, deleting unneeded tables or archiving them to Cloud Storage, choosing SSD for most uses and HDD only for datasets of 10 TB or more that are latency-insensitive or infrequently accessed, enabling automatic storage increases with buffer for growth, purchasing committed use discounts for predictable needs, and using Active Assist recommendations for idle and overprovisioned instances. The application tier must also manage database connection pools so each new application instance does not overload the database with new connections.
Horizontal scaling architectures add separate database capacity to handle more reads and more concurrent connections, instead of making one instance larger. Vertical scaling makes a single Cloud SQL (opens in a new tab) instance larger by adding CPUs, memory, and storage up to 30 TB, which also increases disk throughput and IOPS. Horizontal scaling keeps the primary instance from becoming overloaded by spreading read traffic to replicas, clusters, or distributed copies. The choice affects both performance under high concurrency and cost, because each additional replica or cluster adds capacity and availability but also adds ongoing expense.
Cloud SQL read replicas are separate instances that serve read workloads to scale horizontally. Application reads flow from clients to the replicas, while writes continue to flow to the primary instance, so heavy reads no longer compete with writes on the primary. This separation protects the performance and availability of the primary instance during read-heavy workloads. In cases of read-heavy workloads, adding read replicas is the recommended way to offload traffic from the primary.
Cloud SQL read replicas also support regional failover and disaster recovery across regions. A cross-region replica holds a copy of primary data in a different region, and that replica can be promoted to become the new primary if a disaster occurs. Read replicas can be configured for high availability (HA) in advance, so a promoted replica already has a primary instance and a standby instance across two zones. A replica can also have its own cross-region replicas, called cascading replicas, which continue to provide protection immediately after the middle replica is promoted.
Cloud Spanner (opens in a new tab) scales horizontally through a distributed design that places full copies of data in multiple zones and regions. In any regional configuration, Spanner maintains three read-write replicas, with each replica in a different zone in that region. Each read-write replica contains a full copy of the operational database and is able to serve both read-write and read-only requests. Because requests can be served from any of the three zones, Spanner remains available if a single zone fails.
A Spanner multi-region deployment extends the same idea across regions with two read-write regions and one witness region. The witness region contains a witness replica, which helps maintain consistency without holding a full data copy. Data flows synchronously between the replicas, which provides built-in redundancy and synchronization across regions. This active-active style distribution lets Spanner absorb high-concurrency traffic without depending on manual promotion of a standby.
Cloud Bigtable (opens in a new tab) scales horizontally with clusters placed in unique zones inside a region. A production instance has a minimum of two clusters, and those clusters must be in unique zones in the region. Replication between the clusters is automatically managed by Google, so the application does not manage copying. Bigtable synchronizes data between the clusters, creating a separate, independent copy of data in each zone where the instance has a cluster.
Incoming traffic normally flows to an available cluster, and replication makes it possible for traffic to fail over to another cluster in the same instance. Because each cluster holds an independent copy, the loss of one zone does not remove access to the data. Adding clusters in this way increases both read and write availability while keeping copies close to applications in the same region.
Comparing horizontal scaling choices shows that the three services use different horizontal units but all move read pressure away from a single location. The table below summarizes the unit, traffic flow, and copy behavior for each service. The comparison helps match the service to the workload pattern and recovery need.
| Service | Horizontal unit | How traffic and copies behave |
|---|---|---|
| Cloud SQL | Read replica instance | Reads flow from clients to replicas; writes flow to the primary; a replica is promoted to primary for regional recovery |
| Cloud Spanner | Read-write replica across zones and regions | Each regional replica holds a full copy and serves reads and writes; multi-region uses two read-write regions plus a witness replica |
| Cloud Bigtable | Cluster in a zone | Each cluster holds an independent copy; Google automatically synchronizes clusters and traffic can fail over between clusters |
Choose Cloud SQL read replicas when one relational primary is constrained by reads and the goal is to isolate read traffic on separate instances. Choose Spanner when the workload needs distributed read-write capacity with synchronous copies across zones and regions. Choose Bigtable when the workload needs zonal clusters with automatically managed copies and fast failover inside an instance.
Exam tip: A Cloud SQL read replica serves reads only until it is promoted to primary, while each Spanner regional read-write replica can already serve both reads and writes.
Last updated