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
Analyzing workload characteristics for compute sizing is the process of translating expected database demand into the right vCPU and memory allocation. The analysis starts with forecast load and current inventory, then maps that demand to a Compute Engine (opens in a new tab) machine family or a Cloud SQL instance size, and finally validates the choice with benchmarking and monitoring. Correct sizing protects throughput and CPU utilization, while undersizing can cause database errors, slow migrations, and application slowdowns.
Forecasting load means estimating how much work the database must handle now and in the future. A complete forecast accounts for user count and request rate, plus historical trends, seasonal variations, spikes during special events, and growth from business changes such as expansion to new geographies. This forecast sets the baseline for how many vCPUs, how much memory, and how much disk throughput the target system will need.
Building an inventory grounds the forecast in measured facts about the source system. For migrations from Amazon RDS or Amazon Aurora, the inventory should capture engine version and edition, CPU and memory size, topology, backup policies, parameter settings, and special customizations. Useful assessment sources include:
Benchmarking ties inventory to future capacity by measuring resource efficiency, which is the relationship between application load and the CPU and memory the application consumes. Efficiency can deteriorate when load is exceptionally high and can change over time, so performance data should be collected during inventory and repeated for both normal and peak conditions.
Estimating capacity means deciding the quantity of Google Cloud resources needed to handle forecast load while meeting performance and reliability objectives. For Compute Engine based databases, this includes VM machine type, managed instance group size, and number, type, and size of disks. For managed databases, disk size and throughput, input and output operations per second (IOPS), and vCPU count matter most, because disk performance is based on disk size and the number of vCPUs.
Oracle Database (opens in a new tab) workloads on Compute Engine divide by demand profile, which determines whether a general-purpose or memory-optimized family is appropriate:
| Workload profile | Machine series | When to choose |
|---|---|---|
| Basic and less-demanding | N4 series and C4 series | Transaction volumes, concurrency, and working set fit within general-purpose CPU and memory ratios |
| Complex and memory-intensive | M4N series | Large working sets, complex queries, or high concurrency need a higher memory-to-CPU ratio |
For Cloud SQL, the instance should not be constrained on memory or CPU before scaling for other reasons. For performance-intensive workloads, the instance should have at least 60 GB of memory, and Cloud SQL Enterprise Plus edition should be considered when higher machine limits and data cache are needed. Compute Engine also provides machine type recommendations that match observed utilization to a machine type, and custom machine types allow tuning vCPU and memory independently for workloads with predictable requirements.
Exam tip: Choose N4 or C4 series for basic Oracle workloads and M4N series for complex, memory-intensive Oracle workloads; for Cloud SQL, disk performance scales with both disk size and vCPU count.
Concurrency and query complexity determine how efficiently vCPU and memory convert into throughput. More concurrent users and higher request rates increase CPU and memory consumption, and resource efficiency can drop sharply under exceptionally high load, which raises CPU utilization faster than throughput grows. Complex queries, large numbers of tables, and unnecessarily large database files add further CPU and memory pressure and can affect instance performance, availability, and service-level agreement (SLA) coverage.
Query-level analysis shows where CPU is actually spent. The Query Insights dashboard in Cloud Monitoring identifies the most expensive commands so they can be optimized rather than solved only by adding vCPUs. Location also matters for perceived throughput: sending writes or reads over long distances between writer, reader, and database introduces latency, so slow inserts, updates, deletes, or reads may reflect distance rather than a vCPU shortage. When rightsizing, source and target parameter settings and statistics should be compared so performance differences reflect true workload needs and not mismatched configuration.
Validation confirms that the selected vCPU and memory allocation sustains both normal and peak load with headroom. Load tests for normal and peak conditions measure throughput against CPU and memory consumption, and benchmarking should be repeated at regular intervals because efficiency changes over time. Adequate redundancy should be planned for every component, such as N+1 redundancy where each tier has at least one component beyond the minimum needed for forecast load, so a single failure does not force the remaining CPUs into saturation.
Ongoing monitoring keeps sizing aligned as concurrency and query patterns evolve. Cloud Monitoring provides predefined dashboards for Cloud SQL health and capacity utilization, including CPU, memory, and disk signals, which support rightsizing without adding capacity risk. Automatic storage increases with buffer for peak workloads should be enabled, at least 20% available disk space should be maintained for maintenance operations, and committed use discounts should be used for workloads with predictable vCPU and memory needs once steady-state size is confirmed.
Determining scaling units for distributed database services means choosing the right amount of compute capacity to meet throughput, storage, and latency goals without overprovisioning. For Spanner (opens in a new tab), the scaling unit is compute capacity expressed as nodes or processing units, and that choice directly sets how much storage and throughput the instance provides. The instance can then be resized manually or automatically as load and performance requirements change.
Spanner compute capacity is the amount of compute reserved for a Spanner instance and is specified as a number of nodes or processing units. Compute capacity is provisioned when the Spanner instance is created, and the operator monitors resource utilization of the Spanner instance to scale that capacity. Scaling can be performed manually or automatically, so capacity can track daily peaks, growth, or new regional traffic without rebuilding the database.
Spanner compute capacity controls both storage and speed because adding nodes or processing units increases space and throughput together. Read and write throughputs scale linearly with compute capacity, which makes performance requirements translate directly into a size decision. Costs remain predictable because the workload pays for only what it uses, and the size of the Spanner instance can be adjusted when workload needs change to keep spending aligned with demand.
Spanner scaling is the choice between manual resizing by the operator and automatic adjustment by the managed autoscaler. The managed autoscaler dynamically adjusts compute capacity for Spanner databases based on CPU utilization and storage needs, so manual monitoring and resizing are not required when it is enabled. A minimum capacity is often required even for small workloads, which means very small databases still reserve a baseline of nodes or processing units. Synchronous replication and automatic failover are built in, so maintenance and failover occur with zero downtime for the application and without separate replication configuration.
Spanner regional configuration is the choice of single-region or multi-region placement, and it changes the latency behavior that scaling must support. With a multi-region configuration, Spanner replicates data synchronously across multiple regions, which enables low-latency read operations from multiple locations. The tradeoff is higher latency for write operations because the quorum replicas are spread across multiple regions and must agree. To minimize latency for read-write transactions in a multi-region configuration, Spanner uses leader-aware routing, which is enabled by default and directs transactions toward the leader replica.
Exam tip: More Spanner compute increases storage and throughput together, while multi-region placement favors reads from many locations at the cost of higher write latency; leader-aware routing is on by default to reduce that write penalty.
Spanner cost efficiency means keeping enough nodes or processing units for peak throughput and storage while keeping average cost close to actual use. For stable production load, committing to baseline capacity lowers the price compared with paying fully on demand. Three options work together to control cost:
Together these options let an architecture reserve capacity for peaks while discounts and autoscaling reduce waste during normal operation.
Evaluating storage performance and capacity means matching IOPS, throughput, and total space to what the workload actually needs over time. Cloud SQL (opens in a new tab) instances serve reads and writes from attached storage, so slow or undersized storage increases latency and limits how many requests the database can handle. Capacity planning combines current data size, growth projections, and headroom for maintenance to keep performance stable as the application scales.
Storage performance planning starts from the application's latency needs and access pattern. IOPS measures how many small read and write operations storage can handle per second, while throughput measures how much data can move per second, and both directly affect query response time. Performance-sensitive workloads such as online transaction processing (OLTP) need high IOPS and high throughput with low latency, especially when the working set must stay responsive under many active connections.
Traffic flows from the application to the database process and then to the storage layer, so slow storage backs up every upstream request. Persistent disks of type pd-standard cannot provide the high IOPS and low latency that databases require, so attaching a database to standard HDD storage creates a performance bottleneck. Load testing with realistic traffic is required to validate the choice, because connection count, working-set size, and background overhead all change memory and storage demand in production.
Cloud SQL storage type is determined by the machine type selected for the instance, because each machine series offers different storage options. Google Cloud Hyperdisk Balanced is a scalable, high-performance storage service tied to newer machine series, while SSD and HDD remain options on other series. The decision depends on whether the data needs fast, frequent access or low-cost retention.
| Storage option | Latency and throughput | Choose when |
|---|---|---|
| SSD | Lower latency and higher data throughput | The instance runs production or frequently accessed data, the default for the N2 machine series |
| HDD | Higher latency and lower throughput at lower cost | The data is long-term storage or rarely accessed and does not need high-performance access |
| Google Cloud Hyperdisk Balanced | Scalable, high-performance storage service | The instance uses C4, C4A, or N4 machine series, where it is the default and only value |
For the N2 machine series, SSD is the default value and HDD is the cost-saving alternative for cold data. For the C4, C4A, and N4 machine series, Hyperdisk Balanced is both the default and the only available choice. Enterprise general-purpose shared or dedicated-core instances can use either SSD or HDD, so the same latency-versus-cost tradeoff applies.
Exam tip: Choose SSD or Hyperdisk Balanced for frequently accessed database workloads that need low latency, and reserve HDD only for long-term or rarely accessed data where lower cost matters more than performance.
Storage capacity planning protects both data growth and database maintenance operations. Cloud SQL can automatically increase storage as data grows, but when automatic increases are disabled or capped, the instance must keep at least 20% available space for critical maintenance tasks that Cloud SQL may perform. Monitoring disk utilization with an alert that fires when use rises above threshold at a value of 0.8 warns before space falls below that 20% reserve. This reserve sits between live user data on one side and system maintenance needs on the other, so filling the disk fully risks failed maintenance and outages.
Growth projections must also consider heterogeneous storage, where different parts of an application use different storage types. A transactional service may need SSD or Hyperdisk Balanced for its hot tables, while audit logs or archives from the same application can live on lower-cost HDD storage. Separating hot and cold data this way keeps high-performance capacity focused where latency matters while total retained data continues to grow.
A cache increases data retrieval performance by reducing the need to access the slower disk-based storage layer. Requests flow from the application to the cache first, and cache hits are served from memory without touching the database disks, which lowers storage-layer latency and reduces IOPS demand. Lower disk load then flows downstream to the database itself, allowing the database and other services that depend on it to handle more requests.
Memorystore for Redis (opens in a new tab) provides this caching layer as a fully managed service powered by the Redis in-memory datastore. Memorystore for Redis delivers low-latency access and high throughput for heavily accessed data, so repeated reads do not repeatedly consume database storage performance. It can be deployed in a high-availability configuration that provides cross-zone replication and automatic failover, which keeps the fast access path available even when one zone fails. Caching also supports graceful degradation, because the cache can continue serving requests, even with incomplete or stale data, when the underlying storage is overloaded or unavailable.
Last updated