Learning Objectives
By the end of this chapter, you will be able to:
- Analyze relevant variables to perform database capacity and usage planning, including machine-type and storage selection from workload metrics
- Evaluate database high availability (HA) and disaster recovery (DR) options across zonal, regional, and multi-regional postures, plan maintenance windows, and plan in-place upgrades
- Determine application-to-database connectivity with Cloud SQL Auth Proxy, AlloyDB Auth Proxy, Private Service Connect, CMEK, SSL certificates, session poolers, and auditing policies
- Evaluate appropriate database solutions on Google Cloud across managed and unmanaged services, SQL and NoSQL workload shapes, cost, compliance, organization policies, multi-database strategies, and vector workloads for generative AI
Executive Summary
- Capacity planning starts from peak queries per second, working-set size, write throughput, and 99th-percentile latency targets, then maps them onto Cloud SQL machine types, AlloyDB primary plus read-pool topology, Spanner processing units, or Bigtable nodes
- HA on Google Cloud is region-local for Cloud SQL and AlloyDB and inherently regional or multi-regional for Spanner and Bigtable; DR requires a separate decision about cross-region read replicas, secondary clusters, or multi-region instances
- Connectivity choices balance security and performance: Cloud SQL Auth Proxy and AlloyDB Auth Proxy provide IAM-authenticated TLS tunnels, Private Service Connect terminates database endpoints inside the consumer VPC, and PgBouncer or AlloyDB's built-in pooler prevents connection-storm collapse under load
- Service selection on Google Cloud is driven by data shape, consistency, and scale: Cloud SQL for single-region relational OLTP, AlloyDB for Postgres-compatible mixed workloads with vector and columnar acceleration, Spanner for global strongly consistent SQL, Bigtable for wide-column time-series, Firestore for document workloads with mobile sync, and Memorystore for caching only
Assumptions
- Service names follow Google Cloud canonical forms: Cloud SQL, AlloyDB, Spanner, Bigtable, Firestore, Memorystore, BigQuery
- Region and zone identifiers use the canonical format (for example
us-central1,us-central1-a) - All gcloud examples assume the database engineer has already selected the active project with
gcloud config set projectand has the predefined roles required for the target service - The chapter targets the Professional tier audience, so basic SQL, replication, and transaction concepts are not redefined