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
Implementing dynamic scaling and capacity rightsizing means matching database and supporting compute capacity to actual workload demand over time. Rightsizing corrects the size of existing resources, while autoscaling adds or removes capacity automatically as demand rises and falls. Together they prevent waste from over-provisioning and bottlenecks from under-provisioning while keeping performance stable.
Rightsizing database resources is the continuous process of monitoring use and adjusting allocation to match real demand. Over-provisioned instances and storage create unnecessary cost, while under-provisioned resources cause bottlenecks that slow queries and hurt user experience. A proactive rightsizing loop uses observed metrics rather than initial estimates to keep allocation aligned with demand.
Cloud Monitoring (opens in a new tab) provides real-time visibility into CPU utilization, memory load, disk-space use, active connections, replication lag, and transaction rates. Recommender analyzes that utilization history and suggests smaller or more cost-effective instance types, while custom metrics and alerts warn when thresholds are crossed. For Cloud SQL, rightsizing also includes starting with minimum required storage and compute, enabling automatic storage increases, removing unneeded tables, and removing high availability or disaster recovery from instances that do not require them.
Storage and commitment choices for Cloud SQL balance cost against performance and stability:
Configuring autoscaling means defining minimum and maximum capacity and the conditions that trigger scaling as workload changes. A typical policy adds capacity when CPU utilization reaches an upper threshold and removes capacity when utilization drops below a lower threshold. When traffic rises the platform scales up to handle load, and when traffic falls it scales down to reduce cost for idle capacity.
Google Cloud autoscaling options divide by the type of capacity being managed:
| Option | What scales | Scaling trigger |
|---|---|---|
| Compute Engine managed instance groups (MIGs) | Group of virtual machines (VMs) managed as a single entity | CPU utilization or other policy thresholds within minimum and maximum VM counts |
| Google Kubernetes Engine (GKE) autoscaling | Nodes, Pod replicas, Pod requests and limits, and node pools | Pod resource demands, CPU, memory, custom metrics, and usage patterns |
| Cloud Run | Serverless container instances | Incoming request traffic with built-in scale up and scale down |
| Cloud Spanner Autoscaler tool (opens in a new tab) | Cloud Spanner instance compute capacity | CPU utilization and latency metrics against recommended thresholds |
GKE autoscaling combines four tools that work together to preserve performance while improving utilization. Cluster Autoscaler adds or removes nodes based on Pod resource demands, while Horizontal Pod Autoscaler changes the number of Pod replicas based on CPU, memory, or custom metrics. Vertical Pod Autoscaler fine-tunes Pod resource requests and limits based on usage patterns, and Node Auto-Provisioning automatically creates optimized node pools for the workloads.
The Cloud Spanner Autoscaler tool runs outside the database and adjusts Spanner capacity from its signals. The tool can be deployed to Cloud Run functions or to GKE, and its own compute, memory, and storage consumption is minor. When deployed to Cloud Run functions, its use of Cloud Run functions, Cloud Scheduler, Pub/Sub, and Firestore is usually within the Free Tier, while the managed Spanner instances still incur normal Spanner charges.
Exam tip: The Spanner Autoscaler tool itself is often Free Tier eligible, but that does not include the Spanner instances it manages, which are billed separately.
The iterative optimization loop is a repeatable sequence for tuning a deployed environment until it meets reliability, availability, and cost goals. The loop matters because pricing models change and workload patterns grow over time, so capacity must be rechecked regularly. Each cycle refines both the environment and the process used to manage it:
Custom dashboards and reports support this loop by visualizing cost and performance by project, department, resource type, or time period. Labels applied consistently to resources allow costs to be allocated to the correct owners and filtered for the target audience. Regular review of pricing, utilization, and new features then feeds the next assessment so capacity continues to track demand.
Analyzing cost trends and optimization recommendations is the continuous practice of reviewing database spending, finding waste, and applying savings without harming performance. In Google Cloud, Cloud Billing reports (opens in a new tab) show what was spent, billing exports and labels explain who spent it, and Recommender suggests what to change. Together they help teams rightsize instances, remove idle resources, and choose lower pricing across Cloud SQL, BigQuery, Compute Engine, and Cloud Run.
Cloud Billing reports are built-in dashboards and tables that show usage costs, invoice details, cost breakdowns, and pricing tables for every project under a billing account. Database teams review these reports regularly to track spending trends, forecast short-term costs, and spot sudden increases in storage, compute, or network charges. When built-in views are not detailed enough, billing data can be exported from Cloud Billing to BigQuery for custom SQL analysis by project, service, label, or time period. The FinOps hub centralizes this monitoring so finance and engineering teams share the same view of spend and optimization maturity.
Recommender (opens in a new tab) is a Google Cloud service that analyzes resource utilization data and produces actionable recommendations to optimize allocation. Active Assist is the collection of intelligent Recommender capabilities that runs at no cost and without configuration across Cloud SQL, BigQuery, Compute Engine, and Cloud Run. These recommendations highlight idle resources, idle VM instances, over-provisioned machine types, and underutilized commitments that are common sources of database waste. Cloud Monitoring (opens in a new tab) supports this work with real-time CPU, memory, and storage metrics plus custom metrics and alerts that trigger when right-sizing is needed.
Common Recommender findings for cost review include:
Acting on these findings reduces spend by removing what is not needed and matching remaining database and supporting resources to actual demand.
Cost attribution turns raw billing data into trends that show which team, environment, or workload created the cost. Labels are key-value pairs attached to resources, such as project, team, environment, or cost center, that allow costs to be filtered and grouped in billing reports and BigQuery exports. Consistent labeling enforced with automation like Terraform keeps billing data organized so historical spend can be compared, high-usage resources can be isolated, and chargeback or showback can assign costs fairly. Custom dashboards built with Looker or Data Studio on top of BigQuery exports and Cloud Monitoring metrics then visualize those trends and surface anomalies or unexpected spikes.
Cost optimization applies report and Recommender insights as repeatable governance and reduction processes. A practical order flows from visibility to control to savings: first monitor costs with reports and exports, then control provisioning with reviews and policies, and only after that reduce costs by decommissioning, rightsizing, and repricing. Control actions include reviewing infrastructure changes before they are applied, documenting the preferred state of each environment, detecting drift with Cloud Asset Inventory, and limiting creation with organization policies, quotas, and least-privilege access. Reduction actions include decommissioning unneeded resources, rightsizing over-provisioned hosts, enabling autoscaling, and migrating suitable self-managed workloads to managed services.
Discount and pricing choices provide additional savings once utilization is efficient:
| Option | How it works | Choose when |
|---|---|---|
| Committed use discounts (CUDs) | Discounted price in exchange for committing to minimum use or spend for one year or three years | Usage is predictable and steady, including BigQuery slots |
| Sustained use discounts | Automatic discount credits for Compute Engine and GKE after continuous use beyond thresholds in the billing cycle | Resources run consistently but were not covered by a commitment |
| Spot VMs | Access to unused VM capacity at a significantly lower price, but Compute Engine can preemptively stop instances | Workloads are fault-tolerant and flexible, such as batch jobs without high-availability needs |
Cloud Billing budgets and budget alerts complete the loop by tracking actual spend against planned spend and sending notifications when thresholds are crossed.
Exam tip: A budget alert is a notification when a spending threshold is crossed, not a hard spending cap that stops resources, and alerts can be delayed by billing data processing time.
Evaluating pricing models and architectural trade-offs means comparing how commitment discounts, on-demand rates, and deployment locations affect total database cost. Committed Use Discounts (CUDs) (opens in a new tab) lower the hourly rate for steady usage, while regional and multi-regional choices change compute, storage, and network charges. A cost-efficient design matches stable baseline capacity to commitments and keeps variable or burst usage on pay-as-you-go rates.
Discount and commitment pricing models reduce the billing rate applied to Google Cloud usage without changing the underlying resources consumed. The central FinOps team typically manages these discounts because it can see requirements across the organization and aggregate commitments for maximum savings. Individual product teams remain responsible for rightsizing resources, while FinOps optimizes the rate paid for those resources.
Three main discount types divide by what is committed and where the discount applies:
CUDs can be used on top of enterprise discounts for significant additional savings. Other rate-reduction options include Spot VMs for fault-tolerant workloads at more than 80% lower cost than regular VMs, and BigQuery on-demand versus edition-based pricing with commitments and autoscaling to lower cost per slot. Pricing models change over time, so committed and on-demand options should be reviewed regularly against current usage.
Cloud SQL (opens in a new tab) CUDs are spend-based commitments that provide deeply discounted prices for continuously used database instances in a particular region for a one-year or three-year term. The commitment is measured in dollars per hour of equivalent on-demand spending for vCPUs and memory, and the discount automatically applies to aggregate eligible usage in that region. After purchase, the commitment cannot be canceled and the fee is billed monthly for the full term even if actual vCPU or RAM use drops, while any usage above the commitment is charged at the on-demand rate.
| Commitment term | Discount on covered usage | Committed hourly spend basis |
|---|---|---|
| 1-year Cloud SQL CUD | 25% discount in every region | 1-year CUD price as committed hourly spend |
| 3-year Cloud SQL CUD | 52% discount in every region | 3-year CUD price as committed hourly spend |
Cloud SQL CUDs apply to CPU and memory for MySQL, PostgreSQL, and SQL Server instances in the committed region, including both Cloud SQL Enterprise edition and Cloud SQL Enterprise Plus edition. Cloud SQL CUDs do not apply to shared-CPU machine types such as db-f1-micro and db-g1-small, and they do not apply to storage, backups, IP addresses, outbound data transfer, or licensing. Because the discount follows total vCPUs and memory in the region rather than a specific machine type, an Enterprise edition commitment can cover all or part of an upgraded Enterprise Plus instance in the same region.
A regional example shows why commitments are sized per region from stable baselines. For 100 high availability instances with 2 vCPUs and 7.5 GB RAM, on-demand cost for 730 hours is about $19,345 per month in us-central1 versus $25,550 per month in asia-southeast1. A 25% one-year CUD lowers those to about $14,508 and $19,162 per month, saving about $4,837 and $6,388 per month respectively. Production instances that run 24/7 are commonly covered at 100% of baseline, while burst, development, or staging instances with intermittent use are left on on-demand rates.
Exam tip: Cloud SQL CUDs must be purchased separately in each region and cover only vCPUs and memory in that region — storage, backups, network egress, and licensing always remain at on-demand rates.
Regional versus multi-regional deployment trade-offs compare lower single-region cost against higher availability and distribution cost across regions. Compute prices vary by region, so the same vCPU and memory configuration costs more in asia-southeast1 than in us-central1, and region choice must also satisfy latency, sustainability, and compliance needs. The Google Cloud Region Picker helps compare cost, sustainability, and latency, while the Pricing Calculator estimates provisioning cost in a target region.
Multi-regional resources add replication and network charges on top of regional price differences. Cloud Storage dual- and multi-region buckets are billed at different prices than single-region buckets and incur charges for inter-region replication, so they should be used only when reliability needs justify distribution. Google Cloud charges traffic between regions as network egress, which means closely related resources that exchange data should be concentrated in the same region where data is replicated. Migrating across regions also creates data-transfer costs, potential duplicate provisioning during cutover, and collateral costs for planning, training, and operations.
Product-specific storage controls further shift cost without changing architecture. Cloud Storage Object Lifecycle Management automatically moves or deletes objects by age or condition, and Autoclass automatically moves objects between storage classes based on access patterns. These controls reduce spend for backups, exports, and infrequently accessed data, which is important because Cloud SQL CUDs never discount storage. Combining regional commitments for stable compute with lifecycle management for growing data keeps long-term value high while preserving reliability where it is required.
Last updated