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
Evaluate Compute and Memory Utilization is the practice of tracking CPU and memory use over time to find performance bottlenecks and choose the right instance size. Cloud Monitoring (opens in a new tab) collects CPU Utilization, which is the percent of CPU used by the instance, and Memory Utilization, which is the percent of memory used. Sustained high values mean the workload is pressing against available capacity, while consistently low values mean the instance is overprovisioned. Right-sizing means increasing the machine type when resources are saturated and decreasing it when capacity is wasted.
Viewing compute metrics in Cloud Monitoring is the workflow that moves from the VM Instances page to detailed observability views. Full metrics, including memory and disk-space utilization, require the Ops Agent (opens in a new tab) installed on the virtual machine (VM), because default metrics do not show complete memory behavior. Data flows from the monitoring backend into Overview, CPU, Memory, Network, and Disk sections for analysis.
The ordered workflow for finding hot spots is:
The Overview page concentrates key health signals for database hosts. The following peer metrics indicate instance performance:
Custom dashboards and alert policies build on these same metrics. Set baseline alerts on CPU utilization and memory load to detect resource pressure before queries begin to degrade.
CPU Utilization measures the share of virtual CPU capacity consumed by all activity on the instance. Each virtual CPU (vCPU) is implemented as a single hardware multithread on a CPU processor, and by default two vCPUs share one physical CPU core. Instance performance therefore depends on three related factors: the hardware the instance runs on, the workload running on the instance, and the machine type that defines available vCPUs and memory.
High CPU utilization slows queries and increases latency and should trigger root-cause analysis. Common causes include poorly written queries, long-running transactions, and a high number of concurrent connections whose combined demand is high. The CPU usage metric shows whether the instance has enough CPU for application needs, and if the value stays persistently high, increasing the size of the machine type gives the instance more CPU capability.
Memory Utilization measures the percent of memory used by the instance, excluding disk caches, and for Linux instances it also excludes kernel memory. The exclusion matters because operating-system caches can make memory look full when application memory is still healthy. The amount of memory in use guides whether the machine type provides enough headroom for buffers, connections, sorts, and concurrent queries.
Read and write operation metrics clarify whether memory is the bottleneck. The Number of Reads metric counts read operations served from disk that do not come from cache, so a rising value suggests the working set no longer fits in memory. The Number of Writes metric counts write operations to disk, and write activity occurs even when the application is idle because managed database instances write to a system table approximately every second. When memory is undersized, the instance serves more reads from disk instead of cache, which raises latency and disk reads.
Diagnosing bottlenecks and right-sizing instances connects high CPU and memory signals to specific queries, connections, and sizing actions. Query Insights detects, diagnoses, and prevents query performance problems by showing which queries consume the most CPU and by providing visual query plans and end-to-end tracing. Query Insights integrates with Cloud Monitoring, so teams can create custom dashboards and alerts on query metrics with notifications through channels such as email, SMS, Slack, and PagerDuty.
Operating-system and database views add per-process and per-connection detail when pressure points to the database layer. The following tools isolate the source of CPU pressure:
Connection state explains how cumulative demand builds. If the active count is high, check for long-running queries or blocking wait events, including queries active for more than five minutes. If the idle count is high, terminate approved idle backends with pg_terminate_backend after obtaining approvals, and use EXPLAIN PLAN to rewrite poorly written queries. States such as active, idle, and idle in transaction show different kinds of pressure.
Exam tip: Memory Utilization excludes disk caches and, on Linux, kernel memory, so cache growth alone does not prove memory pressure — confirm with disk-served reads and sustained high utilization.
Right-sizing decisions depend on whether telemetry shows persistent overprovisioning or underprovisioning:
| Recommender | Signal | Sizing action |
|---|---|---|
| Overprovisioned instance recommender | Instance is unnecessarily large for the workload | Reduce costs by resizing to a smaller machine type |
| Underprovisioned instance recommender | High CPU and/or memory usage with risk of bottlenecks or out-of-memory events | Increase size to relieve CPU and memory pressure |
An idle-instance signal provides a third outcome where shutting down an inadvertently idle instance saves cost rather than resizing it. After resizing, continue monitoring to verify that CPU Utilization, Memory Utilization, and disk-served reads stabilize at healthy levels.
Analyze Storage and I/O Performance is the practice of examining how fast data moves to and from database disks and whether capacity is sufficient to keep writes flowing. Cloud Monitoring (opens in a new tab) collects throughput, input/output operations per second (IOPS), and disk-space signals from database VMs and managed instances. Interpreting those signals guides decisions about disk type, disk size, provisioned performance, and automatic capacity growth.
Cloud Monitoring is the service that displays storage performance for Compute Engine VM instances that host databases. Full metrics require the Ops Agent installed on the VM, and metrics are viewed from the VM Instances page by opening the instance Details page and then the Observability tab. That tab also shows the five instances consuming the largest amount of a resource.
Storage investigation centers on five related signals:
Throughput and IOPS must be read together with I/O size and queue depth. Small 4 to 16 KiB random operations are usually limited by IOPS, while sequential or large 256 KiB to 1 MiB operations are usually limited by throughput. To reach the performance limits of disks, use a high I/O queue depth. Persistent Disk (opens in a new tab) and Google Cloud Hyperdisk (Hyperdisk) are networked storage and generally have higher latency than physical disks or Local SSD disks.
Exam tip: Small 4 to 16 KiB random I/O points to an IOPS limit, while large 256 KiB to 1 MiB sequential I/O points to a throughput limit.
Persistent Disk and Hyperdisk performance is the maximum throughput and IOPS that provisioned disks can sustain for attached VMs. For Cloud SQL (opens in a new tab) instances, disk performance is based on the disk size and the number of vCPUs. For Hyperdisk volumes, performance depends on the Hyperdisk type and the machine type of the VMs to which the volumes are attached.
Hyperdisk lets performance and capacity scale dynamically by adjusting the provisioned IOPS, throughput, and size of each volume to match workload needs. This dependency means a database slowdown can come from either side of the attachment: an undersized volume that caps IOPS or throughput, or a VM machine type that caps what the volume can deliver. Continuous tracking of CPU, memory, throughput, IOPS, and latency helps detect pressure before queries degrade.
Storage type selection balances performance, access pattern, and cost:
| Storage type | Choose when |
|---|---|
| SSD (solid-state drive) | Most database use cases where efficiency and consistent performance matter |
| HDD (hard disk drive) | Datasets are large at 10 TB or more, latency-insensitive, or infrequently accessed |
For most use cases SSD is the most efficient and cost-effective choice. HDD is appropriate only when large size and infrequent, latency-tolerant access outweigh the need for higher performance.
Capacity management is the practice of keeping enough free disk space for growth while avoiding over-provisioned disks and snapshots. Cloud SQL supports automatic storage increases that scale storage capacity automatically as data grows, but instances still need buffer for peak workloads because database workloads tend to increase over time. Predefined Cloud Monitoring dashboards help identify health and capacity utilization for Cloud SQL and other components.
Rightsizing and cleanup reduce cost and prevent write halts without changing performance:
Alerts complete the loop from observation to action. Baseline alerts on disk-space utilization warn before the disk fills, while service-status alerts notify when databases unexpectedly stop. For high-availability deployments, tracking unplanned failovers preserves visibility during automated recovery events.
Investigate Audit Logs and System Events is the practice of using audit and system signals to answer who did what, where, and when. Cloud Audit Logs (opens in a new tab) record activity when resources such as projects, Cloud SQL instances, and service accounts are created, changed, or accessed. For databases, this history is combined with engine and infrastructure events to track administrative changes, monitor data access patterns, and support security and auditing requirements.
Cloud Audit Logs are organized into four categories that record different kinds of activity against Google Cloud resources. Each category has a different owner and purpose, from user actions to automated Google system actions.
Admin Activity entries provide accountability for control-plane changes, while Data Access entries show data-plane access patterns. System Event entries help separate Google-initiated events from customer-initiated changes during an investigation, and Policy Denied entries help confirm whether a failure was caused by policy rather than by missing credentials or connectivity.
Administrative changes are tracked primarily in Admin Activity audit logs, which store the actor, the action, the resource, and the time of each change. Typical database-relevant examples include creation of a service account, a SetIamPolicy change, and creation of a service account key with google.iam.admin.v1.CreateServiceAccountKey. These logs are useful for forensics after a breach and for explaining production issues caused by a policy change.
Cloud Logging (opens in a new tab) retains audit logs for a default retention period, so longer history requires export through a log sink. Admin Activity audit logs are always written and cannot be configured, excluded, or disabled, even if the Cloud Logging API is disabled. Because they are always on, organizations build policies, procedures, and log-based alerts around them, such as flagging unauthorized virtual machine creation or IAM privilege escalation.
An investigation of IAM lifecycle events in the Google Cloud console follows an ordered workflow:
SetIamPolicy, google.iam.admin.v1.CreateServiceAccount, and google.iam.admin.v1.CreateServiceAccountKey.Exam tip: Admin Activity audit logs are always written and cannot be disabled, while Data Access audit logs must be explicitly enabled.
Data access and system-event monitoring shows how databases and surrounding infrastructure are being used and whether activity falls outside expected patterns. Data Access audit logs must be enabled before they can reveal read and write access to data, while System Event logs provide the Google-side counterpart for automated actions. Policy Denied logs add the denial signal, showing when access was blocked by policy so investigators do not misattribute the failure to the database engine.
For Cloud SQL for PostgreSQL, engine flags extend this visibility into database internals. Enabling log checkpoints records checkpoint activity and enabling log temp files records temporary file usage, which help explain I/O, storage, and performance anomalies. Related controls turn off verbose planner, parser, executor, and statement statistics logging and turn off log hostname logging to keep audit records focused on relevant security information. Network and access signals complete the picture through firewall rule logging, Virtual Private Cloud (VPC) flow and DNS logging, continuous network traffic monitoring, and monitoring of group membership, service accounts, and service account keys.
Meeting auditing requirements means defining what is logged, protecting the logs, keeping them long enough, and reviewing unusual activity on time. Organizations establish and document which metadata, data, and system events should be logged, allocate audit log storage capacity, configure security logging policies for Google Cloud services, and retain audit records beyond the default period when compliance requires it. The documented scope is reviewed at least annually or whenever the threat environment changes.
Retention depends on Cloud Logging sinks that export copies of logs to long-term destinations. Creating a log sink sends audit entries to BigQuery or another sink destination for aggregate analysis over time, where a subset of columns can be selected and analyzed across dimensions. Access to audit logs is restricted to authorized personnel with unique accountability, and Admin Activity logs from Cloud Identity or Google Workspace, such as user login events, are shared into Google Cloud so all sources can be managed centrally. Security-related events then feed alerts to responsible stakeholders, with a defined process to review anomalies and take timely action.
Centralized observability for Cloud SQL gives every team member one place to see database and instance behavior during troubleshooting. Cloud SQL uses built-in agents to collect query telemetry, and Cloud Monitoring collects measurements from the service and the Google Cloud resources it depends on. The platform provides a predefined Cloud SQL monitoring dashboard, while teams can create custom dashboards to watch RAM, CPU, storage, and I/O metrics and set alert policies for timely notification.
Query-level investigation uses the predefined Query Insights dashboard in Cloud Monitoring and engine-native features to identify the most expensive commands for optimization. When deeper correlation is needed, exported audit and event data in BigQuery supports analysis of access patterns and anomalies over longer periods. Third-party monitoring solutions integrated with Google Cloud, such as Datadog and Splunk, can also consume the same telemetry when an organization already standardizes on them.
Last updated