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
Network topology and latency constraints describe how application tiers and databases are placed in Google Cloud and how that distance affects performance and cost. In the baseline design, web-tier virtual machines (VMs), application-tier VMs, and the database sit in one zone and share one network, so traffic travels the shortest path. Spreading tiers across zones or regions improves resilience and reach but adds network hops, cross-location traffic, and cost.
Virtual Private Cloud (VPC) (opens in a new tab) is the global networking system that connects application and database resources in Google Cloud. The baseline zonal design places load balancers, Compute Engine (opens in a new tab) VMs, and database VMs in a single VPC network and a single subnet. That design can grow to multiple VPC networks or multiple subnets by using VPC Network Peering, Private Service Connect, private services access, and Shared VPC.
A multi-region layout keeps one VPC network but divides it by region and purpose. The VPC network in that design has a subnet in each region for web-server VMs, a subnet in each region for application-server VMs, and a proxy-only subnet in each region for the cross-region internal load balancer. As an alternative to one shared VPC network, an organization can create a separate VPC network in each region and connect the networks with Network Connectivity Center.
Private connectivity lets application VMs reach managed databases and Google APIs without public internet addresses. In the reference design, Compute Engine VMs do not need inbound access from the internet, so no external IP addresses are assigned to the VMs. Google Cloud resources that have only a private internal IP address can still reach certain Google APIs and services by using Private Service Connect or Private Google Access.
This private path matters because teams can replace a self-managed database on a VM with a fully managed service like Cloud SQL or AlloyDB for PostgreSQL and reach it without exposing VMs. For secure outbound connections from private-only VMs, traffic flows from the VMs to the internet through Cloud NAT or Secure Web Proxy. If a self-managed third-party database on a VM is kept, the application depends on an internal load balancer or other mechanism to stay connected when the primary database fails.
The request flow is the ordered path that user and application traffic follows from the edge inward to the database. Each hop can add latency, especially when tiers sit in different zones or regions:
When all hops stay in one zone and one subnet, there is no cross-zone traffic between components. When tiers spread across zones or regions, each hop between locations adds latency and network charges.
Zonal, regional, and multi-region designs trade component-to-component latency and cost against user latency and resilience. A distributed design provisions more resources, carries more cross-location traffic, and replicates more data, so cost and operational complexity rise. For business-critical applications the availability gain may outweigh that cost, while for batch computing that needs low-latency and high-bandwidth links between VMs, a single-zone design is often better and reduces data-transfer costs.
| Deployment scope | Component-to-component latency and cost | End-user and resilience effect |
|---|---|---|
| Single-zone deployment | Lowest latency between VMs and database; no cross-zone traffic and no cost for intra-zone traffic | Users must come to one zone; a zone or region outage stops the application because the load balancer has no available backends |
| Single-region, multi-zone deployment | Low latency within the region; traffic stays in the region with no cross-region charges, but intra-region network costs still apply | Better resilience to a zone outage because regional MIGs and synchronous database replication keep serving from the surviving zone |
| Multi-region deployment | Highest cross-location traffic, cost, and complexity from replication and cross-region load balancing | Lowest latency for globally spread users and resilience to regional problems when traffic is distributed across regions |
Region choice further shapes latency, cost, and compliance for any scope. When choosing regions for applications and databases, evaluate:
These factors often conflict, since the most cost-efficient region may not have the lowest latency to users or the lowest carbon footprint.
Exam tip: There is no cost for intra-zone traffic in a single-zone design, but intra-region network costs still apply when traffic moves between zones in the same region.
Application data access patterns describe how application logic reaches the database layer and how that connection behaves as the application grows. The pattern includes where the database runs, how connections are reused, how reads and writes are replicated, and how many data models one interface can serve. On Google Cloud this means choosing between provider-managed, partner-managed, and self-managed databases on Compute Engine, sizing connection use, and matching replication and data-model support to transactional versus analytical needs.
A connection pool is an application-side set of pre-created database connections that application requests reuse instead of opening a new connection each time. Requests are taken from the pool without waiting for connections to be created, which improves efficiency and reduces latency. When best practices are followed, each application service instance creates its own pool with a minimum set of connections.
Traffic flows from each application service instance through its own pool to the shared database, so the database depends on the combined total from all pools. First an instance starts and pre-creates its minimum connections, then each additional instance adds another full set of connections to the database. Because databases cannot support unlimited connections, uncontrolled application scale-out can overload the database and must be managed.
Exam tip: Each new application instance adds its pool's minimum connections to the database total — scaling the app also scales the connection count.
A full database evaluation is the practice of checking a database system against all application requirements before selection. The evaluation covers provider-managed databases such as Spanner, partner-managed databases, and self-managed databases running on Compute Engine (opens in a new tab). No single stateful application architecture fits every multicloud use case, so the choice depends on whether the application needs multi-region scale inside one cloud or portability across clouds.
Data flows from the application to the selected database system, and the system choice controls replication options and operational load. A multi-regional managed database serves applications deployed in multiple regions within one cloud, while a platform-independent database such as AlloyDB Omni (opens in a new tab) or PostgreSQL serves applications that must move across clouds. The analytics hybrid and multicloud pattern reflects the same split by separating transactional workloads from analytics workloads so each can use the access path it needs.
The best-fit versus portable decision compares selecting the best database in each cloud against using one database system that runs in all required clouds. Using the best database in each cloud can optimize each location but requires connecting different systems based on the use case. Using one portable system may be less ideal for any single application but is easier to implement, operate, and maintain.
| Approach | Replication effort | Management tradeoff |
|---|---|---|
| Best database in each cloud | Significant effort for one-directional or bidirectional replication between different systems | Harder to implement and maintain across systems |
| Portable system in all clouds | Less cross-system replication work when the same system runs everywhere | Easier to implement, operate, and maintain |
A concurrent evaluation compares the advantages and disadvantages of both approaches to provide a solid basis for selection. If the systems differ, one-directional or bidirectional replication requires significant effort, so the best-system approach is justified only when its benefit outweighs that effort. Portability avoids much of that cross-system work by keeping the same system in every location.
Replication for distributed data access keeps a database system present in all deployment locations across zones, regions, or clouds. The documented forms are asynchronous replication, bidirectional replication, and fully synchronized active-active replication. Not every database system supports all three forms, so the application design must match its consistency and availability needs to what the system can provide.
When a system lacks built-in support, the architecture depends on an external service or add-on to move data between locations. Evaluating built-in versus external approaches reveals tradeoffs in complexity and coverage before the application depends on cross-location reads and writes. That comparison helps determine whether the database or an additional replication layer owns consistency between locations.
A multi-model database is a single database system that supports document, graph, key-value, column-family, and relational models under one unified query interface and storage engine. The application sends different shapes of work to the same system instead of connecting to and synchronizing separate databases. This single-system access is designed for flexible, scalable management in cloud and real-time applications, including combined relational and AI-powered needs.
Spanner is an example of a multi-model database with PostgreSQL dialect support. Applications send both relational and NoSQL work to Spanner through that interface to build AI-powered features. The same system supports Spanner Graph for querying complex relationships and vector search for semantic search, so graph, relational, and search access share one storage engine.
Security, identity, and access dependencies define how an application proves who it is, what database resources it can touch, and how data stays protected as it moves and rests. In Google Cloud, Identity and Access Management (IAM) controls who has what access, service accounts provide identity for applications, VPC Service Controls enforce network boundaries, and encryption protects data at rest and in transit. A database design must map each application requirement to the right identity, role, boundary, and key control.
A service account is a special account used by an application rather than a person, and it is identified by a unique email address. The application authenticates as the service account to reach Google Cloud resources without sharing a human user's login credentials, which prevents unauthorized access when credentials would otherwise be shared. For database workloads, the application depends on its service account, and the database depends on IAM to verify that identity before allowing control-plane or data access.
Secure use of service accounts follows least-privilege and separation practices:
Because the default service account can include permissions the workload does not need, creating a dedicated service account with only essential permissions reduces the blast radius if the application is compromised.
Identity and Access Management (IAM) (opens in a new tab) provides unified control over permissions for Google Cloud resources by binding an identity to a role on a resource. Access control policies applied to a parent resource in the resource hierarchy, such as an organization or project, are inherited by child resources such as virtual machines (VMs) or Cloud Storage buckets. This inheritance means an application dependency on a project-level role automatically extends to the databases and storage inside that project unless a tighter policy overrides it.
Custom roles allow fine-grained permissions tailored to a specific need, such as allowing a service account to read and write data to a Cloud Storage bucket but not delete it. You create custom roles in IAM and assign them to users, groups, or service accounts so each identity holds only the permissions required for its task. For Cloud SQL, Cloud SQL IAM database authentication extends this model into the database by providing a single interface to manage database access for users and service accounts centrally.
Centralized database access with Cloud SQL IAM database authentication follows an ordered dependency:
Authentication requirements differ for people, for code, and for integration connections, and each maps to a different Google Cloud mechanism. Humans doing interactive work authenticate with user credentials in the Google Cloud console or with gcloud auth login for the gcloud CLI, while Cloud Shell reuses the console session credentials. Workloads running locally, in Google Cloud, on-premises, or in another cloud most flexibly authenticate through Application Default Credentials (ADC) (opens in a new tab), where client libraries check known locations in the environment for credentials so the same code can run unchanged with user credentials locally and short-lived service account credentials in production.
External identities and connections add two federation dependencies plus stored connection credentials:
An integration therefore depends on its authentication profile to reach a database or API, and the database depends on federation or ADC to verify that the incoming workload identity is trusted. Enabling multi-factor authentication, managing API keys, and managing service account keys further protect these human and workload paths.
VPC Service Controls help enforce data residency and prevent exfiltration by creating a service perimeter that defines the virtual boundaries from which a service can be accessed. Data flows only between resources inside the same perimeter, and requests from outside the perimeter are denied even when the caller is authorized by IAM policy. For Cloud SQL, the perimeter can restrict import and export through the Cloud SQL Admin API or Cloud Storage API, so data stays within selected network locations.
Secure connectivity dependencies reinforce that boundary at the network layer. VMs without external IP addresses can still reach Google APIs through Private Service Connect or Private Google Access, and outbound traffic from private VMs flows through Cloud NAT or Secure Web Proxy. Identity-Aware Proxy (IAP) creates a central authorization layer that verifies user identity and context before granting HTTPS or TCP access, while Cloud Next Generation Firewall (NGFW) policies control traffic between resources inside the architecture.
Exam tip: VPC Service Controls can block data movement outside a perimeter even if the user is authorized by IAM policy.
Encryption in Google Cloud protects customer content at rest and in transit automatically, with no customer action required for the default protection. Customer-managed encryption keys (CMEK) add another layer where Cloud SQL uses customer-controlled keys to access data on every API call, which is intended for sensitive or regulated data. The choice of where the key lives determines who manages the hardware, where residency is enforced, and whether Google infrastructure holds the key.
| Key option | Who manages the key | Where the key is stored |
|---|---|---|
| Google-owned and Google-managed keys | Managed by Google by default for Hyperdisk, Filestore, and Cloud SQL | |
| Cloud Key Management Service (Cloud KMS) customer-managed keys | Customer in Cloud KMS | In the location set when the key is created |
| Cloud Hardware Security Module (Cloud HSM) keys | Customer in Cloud HSM | Inside a physical hardware security module in the chosen region |
| Cloud External Key Manager (Cloud EKM) keys | Customer in third-party product | In a third-party key management product deployed outside Google infrastructure |
The application lifecycle depends on this chain: data in transit is encrypted between application and database, data at rest is encrypted under Google-managed keys, and CMEK wraps that protection when regulatory control is required. Access Approval adds a final dependency by requiring explicit customer approval before Google support or engineering personnel can access data or configurations.
Last updated