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
Translating baselines to Google Cloud resource configurations means converting measured workload needs into specific machine sizes, storage tiers, and service scaling units. A baseline includes workload type, throughput, CPU and memory use, I/O profile, data size, and expected growth. The goal is to pick a configuration that matches current performance while leaving headroom for spikes and future growth.
The sizing baseline is the set of workload facts used to choose Cloud SQL (opens in a new tab), AlloyDB for PostgreSQL (opens in a new tab), and Cloud Spanner resources. Establishing the baseline comes before choosing vCPUs, memory, disk size, or node counts because each service scales on a different primary unit. Growth over time must be included so storage limits and compute headroom do not block writes later.
The baseline captures four peer facts:
Cloud SQL maps baselines to vCPU, memory, and persistent disk SSD storage on a single instance that can scale up or scale out with read replicas. If memory metrics stay high, the instance may be undersized or have a custom configuration that uses too much memory, and scaling up increases memory size. Changing memory size requires an instance restart, and if the instance is already at maximum memory size, the database must be sharded across multiple instances.
Keep at least 20% available disk space for maintenance operations performed by Cloud SQL, aim for under 10,000 tables per instance to limit upgrade time, and size for transaction and binary log retention on high-write instances. Enable automatic storage increases to grow storage capacity automatically, and route reads to a read replica when vertical scaling and tuning are no longer enough. Only Cloud SQL instances configured for high availability (opens in a new tab) with at least one dedicated CPU are covered by the service level agreement (SLA), while shared-core and single-zone instances are not covered.
For Cloud SQL for SQL Server (opens in a new tab), baseline I/O capacity before deployment because throughput is throttled when the workload reaches the IOPS limit or throughput limit. A disk size of 4 TB or greater provides more throughput and IOPS, higher vCPU provides more IOPS and throughput, and issuing I/O in parallel achieves higher queue depth. A representative test-run configuration uses 40 vCPU, 262144 MB of memory, maximum degree of parallelism (MAXDOP) of 8, cost threshold for parallelism of 120, 8 pre-sized tempdb files to prevent autogrowth, user database files with autogrow set to 64-128 MB and pre-sized, and storage of 4 TB or greater for best IOPS.
AlloyDB for PostgreSQL is a cloud-scale system with disaggregated compute and storage and a multi-tier cache architecture. Writes are acknowledged as soon as write-ahead log (WAL) files persist on regional storage, while block materialization is offloaded to storage. Data is placed automatically between buffer cache, ultra-fast cache, and the intelligent storage engine, so input and output operations per second (IOPS) are not a useful comparison metric and TPS and TPM provide the meaningful comparison.
The primary sizing metric for AlloyDB for PostgreSQL is TPS. To estimate the required size from an existing PostgreSQL or commercial database baseline, follow this ordered workflow:
Deploy AlloyDB for PostgreSQL as a zonal single-node instance or as a highly available two-node instance, with optional read pool instances and a secondary cluster in another region for geographically distributed workloads or disaster recovery (DR). Aim for steady-state CPU utilization of about 60-70% to avoid operating system scheduling overhead and leave margin for spikes from client applications. The following TPC-C results with about 65% reads and 35% writes show how TPS scales with machine type and caching:
| AlloyDB machine type | Workload scenario | New orders per minute | Converted TPS |
|---|---|---|---|
| 16 vCPU | 30% cached, 3200 warehouses | 252,970 | 9,706 |
| 16 vCPU | 100% cached, 576 warehouses | 428,316 | 16,238 |
| 64 vCPU | 30% cached, 12800 warehouses | 589,598 | 22,853 |
| 64 vCPU | 100% cached, 2304 warehouses | 716,138 | 27,757 |
Exam tip: For AlloyDB for PostgreSQL use TPS and TPM for sizing parity, not IOPS, because disaggregated storage and multi-tier caching make IOPS incomparable to other systems.
Cloud Spanner maps baselines to compute capacity measured in processing units (PUs), where 1000 PUs equals one node, plus storage allotment tied to that compute capacity. Storage is measured in binary gigabytes, where 1 GB equals 2^30^ bytes and is also called a gibibyte (GiB), and 1 TB equals 1024 GB. Spanner bills for storage actually utilized, not for the total allotment, but Spanner may reject writes if data exceeds the allotment for the current compute capacity.
| Instance size | Storage allotment per database |
|---|---|
| Smaller than 1 node (1000 PUs) | 1024.0 GiB of data for every 100 PUs |
| 1 node and larger | 10 TiB of data for each node |
For example, a 300 GB database can start at 100 PUs and stay below the limit until the database grows past 1024.0 GiB, then another 100 PUs must be added to allow growth. Instances with fewer than 1000 PUs suit smaller data sizes and workloads, while larger workloads on small instances may show non-linear scaling and intermittent latency increases. Peak read and write throughput for a given compute capacity also depends on instance configuration, schema design, and dataset characteristics.
Spanner distributes each instance's server resources across the zones in its regional, dual-region, or multi-region configuration, with each per-zone resource using the data replica in its zone. For instances of 1000 PUs and smaller, Spanner allocates a single server task per zone, while for instances larger than 1000 PUs, Spanner allocates multiple server tasks per zone with one task for each 1000 PUs. Multiple tasks per zone improve performance and allow Spanner to create database splits for even better performance. Compute capacity can be increased later, usually within minutes and rarely up to an hour, and can be reduced except when data exceeds 10 TiB per node.
Spanner Omni maps baselines to host virtual machine (VM) or Kubernetes node resources plus durable block storage. Each VM uses a dedicated, persistent, and attachable solid-state drive (SSD) with an ext4 file system, and local disks are not supported. Allocate 500 GB of storage per vCPU, and size disk I/O to achieve 500 IOPS and 30 MB per second per vCPU.
On Google Cloud, a Google Kubernetes Engine (GKE)-based deployment requires nodes with at least 4 vCPU and at least 16 GB of random access memory (RAM) with zonal persistent disk (pd-ssd) or Hyperdisk Balanced storage. A VM-based deployment on Google Cloud requires a VM with 4 vCPUs and 16 GB of RAM with the same zonal pd-ssd or Hyperdisk Balanced storage. This 4 vCPU and 16 GB minimum with SSD-backed zonal storage provides the baseline unit for preserving performance parity when moving Spanner Omni workloads onto Google Cloud infrastructure.
Evaluating current workload performance metrics means measuring how an existing database uses resources today to establish a performance baseline for migration. The baseline captures peak CPU utilization, memory residency, disk I/O patterns, and network throughput under both normal and peak load. That baseline is then used to choose the size and configuration of the target Cloud SQL (opens in a new tab) instance so it can deliver similar performance after migration.
The target Cloud SQL instance must be sized to match the source database for similar performance needs. Pay special attention to disk size and throughput, IOPS, and number of vCPUs, because disk performance is based on the disk size and the number of vCPUs. Incorrect sizing can cause migrations to struggle or fail and can lead to long migration times, database performance problems, database errors, and application performance problems. A correct baseline therefore prevents both under-provisioning and costly over-provisioning.
CPU and memory analysis starts with peak utilization, not average use, because the target must handle the busiest periods without becoming constrained. For performance-intensive workloads, ensure the instance is not constrained on memory or CPU, with at least 60 GB of memory as a guideline for demanding workloads. Use Cloud Monitoring predefined dashboards to observe health and capacity utilization, and use Query Insights to identify the most expensive commands that drive CPU and memory consumption.
Memory residency is evaluated with two related signals that must be interpreted together. The total usage metric observes the percentage of available memory used by the Cloud SQL instance, including memory used by the database container and memory allocated by the operating system cache. By observing the difference between container-focused usage and total usage, you can identify how much memory is used by processes versus how much is used by operating system cache that can be repurposed. If both metrics appear high, the instance might be low in memory because of custom configuration, because the instance is undersized for the workload, or a combination of both.
Scaling memory requires changing the instance size, which requires an instance restart. If the instance is already at the maximum memory size, you must shard the database across multiple instances. Very large table counts can also affect instance performance and availability, so keep the table inventory part of the memory and CPU baseline. This link between workload shape and instance limits is why CPU, memory, and schema size are collected together.
Exam tip: In Cloud SQL, disk performance is based on disk size and number of vCPUs — size both together, not storage capacity alone.
Disk analysis establishes the I/O baseline the target must sustain, including IOPS, throughput, and growth over time. Benchmarking helps define the right architecture by collecting performance information that estimates the needs of the Google Cloud target environment. Run load tests for both normal and peak conditions to determine resource efficiency, which is the relationship between application load and resources such as CPU and memory consumed. Repeat benchmarking at regular intervals because efficiency can deteriorate under very high load and can change over time.
Storage headroom and storage type are part of the same disk baseline. Configure storage so the instance keeps at least 20% available space to accommodate critical maintenance operations, and create a metrics-based alert for disk utilization. Enable automatic storage increases to scale capacity as data grows, while still keeping buffer for peak workloads. Choose the storage type based on access pattern and size:
| Storage type | Best fit | Tradeoff |
|---|---|---|
| SSD | Most use cases, where efficiency and consistent performance matter | Higher cost per TB than HDD for very large cold data |
| HDD | Datasets 10 TB or more that are latency-insensitive or infrequently accessed | Not suitable when low latency or frequent access is required |
Network analysis measures how fast data moves between clients, the database writer, readers, and the storage layer. Test and verify network latency between the source environment and the target environment to understand copy time, and compare latency from clients and external environments to the target versus the source. For slow inserts, updates, or deletes, check the locations of the writer and database because sending data over long distances introduces latency. Check reader and database location as well, because latency affects read performance more than write performance.
Placement decisions flow directly from those measurements. To reduce communication time, outbound data transfer cost, and I/O operations between layers, store data in the same zone where it is processed. Keep the data storage layer separate from the data computation layer on separate platforms in the same zone and region, so computation can scale or stop without forcing storage to stay running. For example, data flows from Cloud Storage (opens in a new tab) to a Managed Service for Apache Spark cluster for computation, then results flow back to the target system.
A performance baseline depends on a complete and accurate inventory, so automate collection rather than relying on manual methods that are prone to error. The inventory includes generic properties such as database engine version and edition, CPUs, and memory size, plus topology, backup policies, parameter settings, and special customizations. Amazon RDS or Aurora and Cloud SQL may differ in infrastructure, storage, authentication and security, replication, backup, high availability, resource capacity model, engine features, extensions, and default parameter values. Benchmarking during inventory building captures how those differences will affect the target architecture.
Forecasting extends the current baseline into future requirements. When forecasting load, consider historical load trends, seasonal variations, load spikes during special events, and growth from business changes like expansion to new geographies. When estimating capacity, provide adequate redundancy for every component, such as N+1 redundancy where each layer has at least one redundant component beyond the minimum needed for forecast load. Review resource quotas and API rate quotas, which can be zonal, regional, or global, and request adjustments when quotas are insufficient for needed capacity. A Compute Engine reservation (opens in a new tab) provides assured capacity in a specific zone for a chosen machine type.
Three assessment tools divide this discovery work:
The migVisor output provides comprehensive discovery, a migration-complexity report based on proprietary features, a financial report with savings and operating budget, and a phased migration plan. Note that migVisor temporarily increases server utilization by typically less than 3%, so it can run during non-peak hours. Together, automated inventory, peak-load benchmarking, and these tools produce the baseline used to select vCPUs, memory, disk size, throughput, and network placement for the target instance.
Projecting future capacity and high availability requirements means building a sizing model that handles more than today's load. The model starts from current workload metrics, adds expected business growth and seasonal peaks, and then adds resource overhead for high availability (HA) and disaster recovery (DR) so the database remains scalable and reliable over time.
Forecasting future load is the practice of estimating how many users and requests the system must handle in the future. A complete forecast combines historical load trends with forward-looking changes that increase demand over time. Traffic and load (opens in a new tab) flow from users and applications to the database tier, so underestimating demand leaves the database tier without enough CPU, memory, throughput, or IOPS when peaks arrive.
A complete forecast combines three peer factors:
The forecast becomes the input that all later sizing and redundancy decisions depend on.
Translating the forecast into database sizing means choosing the quantity and configuration of Google Cloud resources that can carry the expected load while meeting performance and reliability objectives. For Cloud SQL, sizing focuses on disk size and throughput, IOPS, and number of virtual CPUs (vCPUs), because disk performance depends on both disk size and the number of vCPUs. For compute layers, sizing includes the size of each managed instance group (MIG), virtual machine (VM) machine type, and the number, type, and size of persistent disks. Teams can estimate cost with the Google Cloud Pricing Calculator and use assessment tools like Migration Center (opens in a new tab) and migVisor to receive size and configuration recommendations and a total cost of ownership report.
Incorrect target sizing causes long migration times, database errors, and application performance problems. Sizing must therefore account for both steady-state load and peak load, plus buffer for growth, because database workloads tend to increase over time.
High availability overhead is the extra capacity required so the system keeps serving traffic when a component or zone fails. The baseline rule is N+1 redundancy, which means every component in the application stack has at least one redundant component beyond the minimum necessary to handle the forecast load. In each region, designs should leverage three zones rather than two and overprovision capacity by a third more than the estimate so failover can succeed.
Cloud SQL in HA configuration provides synchronous replication between zones within a single region and fails over automatically from the primary database to the standby database without changing the database endpoint. For read-heavy workloads, read replicas offload traffic from the primary instance, while replicas across zones create a topology that is near active-active with a recovery point objective (RPO) close to zero. Mission-critical workloads also benefit from deletion protection, automated and on-demand backups, and Cloud SQL Enterprise Plus edition for increased availability and near-zero downtime planned maintenance.
Disaster recovery overhead is the additional storage, replication, and failover planning needed to survive zonal and regional outages. Recovery planning uses two business metrics: recovery time objective (RTO), or how long after a disaster before the system is running again, and recovery point objective (RPO), or how much data can be lost in a disaster. Data flows from the primary region to the secondary region or bucket through asynchronous replication, and dual-region buckets can use turbo replication for faster replication.
| Approach | Scope | Replication and recovery |
|---|---|---|
| High availability (HA) | Regional deployment within one region | Synchronous replication between zones with zero or near-zero RTO and RPO and active-active topology without a single point of failure |
| Disaster recovery (DR) | Multi-region deployment across two or more regions | Typically asynchronous replication to a secondary region with defined RTO and RPO and manual or semi-automated failover |
DR overhead includes cross-region replicas, snapshots stored in multi-region locations, and backups stored in dual-region or multi-region Cloud Storage buckets so data remains restorable if a region is unavailable. Managed multi-regional services like Spanner and Cloud Storage provide built-in redundancy and synchronization across regions for active-active designs. Migrate from Amazon RDS for SQL Server (opens in a new tab) guidance covers sizing and replication choices that affect this cross-region overhead.
Exam tip: HA applies to regional deployments with synchronous replication between zones, while DR applies to multi-region deployments with typically asynchronous replication between regions.
Validating the sizing model means proving through testing that the chosen resources deliver the expected efficiency under real load. Resource efficiency is the relationship between application load and resources such as CPU and memory consumed, and efficiency can deteriorate when load is exceptionally high or change over time. Teams run load tests for both normal and peak conditions and repeat benchmarking at regular intervals to detect that drift.
Sustaining the model requires monitoring utilization and reassessing requirements periodically. Storage should retain at least 20% available space for maintenance operations, with alerting on disk utilization, and instance storage must account for transaction log retention because high write activity can consume significant disk space. Quotas and reservations also constrain long-term scalability, since quotas limit resource creation and API request rates per project by zone, region, or globally, while a Compute Engine reservation provides assured capacity in a specific zone for a chosen machine type.
Solution sizing connects three decisions in order: first measure peak CPU, memory, I/O, and network use to form a baseline, then translate that baseline into Cloud SQL, AlloyDB for PostgreSQL, Cloud Spanner, or Spanner Omni units, and finally enlarge the result for growth, seasonal peaks, and HA and DR overhead. Validation through load testing and ongoing monitoring keeps the model aligned as efficiency drifts and quotas, storage limits, and replication needs change.
Last updated