Book TOC · Previous · Chapter 6 of 6

Chapter 6: Master Look-Alike Tool Comparison & Decision Playbook

Chapter Focus: Side-by-side comparison of look-alike PDBE services, a 5-Step Architecture Decision Framework, cross-domain production patterns, and the Top 25 Golden Rules.

1. The PDBE Look-Alike Service Disambiguation Matrix

In complex Google Cloud Certified Professional Cloud Database Engineer architectures, multiple Google Cloud services often appear to solve similar problems. Use the matrix below to distinguish between closely related services based on latency, scale, security boundaries, and operational overhead.

2. The 5-Step Architecture Decision Framework

When evaluating a multi-service Google Cloud design, apply this structured 5-step architectural review:

1. Step 1 — Pinpoint Core Workload & Non-Functional Requirements: Identify the primary workload driver (e.g., sub-10ms OLTP vs. petabyte OLAP, synchronous REST vs. asynchronous event streaming, strict regional data residency vs. global active-active availability).
2. Step 2 — Prefer Managed, Cloud-Native Services First: Default to fully managed, serverless, or Google-curated services before introducing self-managed VMs, custom glue scripts, or unscalable manual operations.
3. Step 3 — Enforce Zero-Trust Identity & Keyless Authentication: Replace static credentials, long-lived service account JSON keys, and broad basic roles (Owner/Editor) with Workload Identity Federation, attached service accounts, and predefined IAM roles.
4. Step 4 — Verify Network Isolation & Data Perimeter Guardrails: Combine private connectivity (Private Service Connect, Private Google Access, IAP TCP forwarding) with VPC Service Controls and Organization Policy constraints.
5. Step 5 — Optimize for Cost, Observability, and Day-2 Reliability: Validate autoscaling boundaries, SLO burn-rate alerting, sink-level log filtering, and automated rollback pipelines before production rollout.

3. Review: Architecture Decision List

1. Cloud Spanner exports use Dataflow jobs to ensure scalability and performance.
2. Native Spanner backups are different from Avro exports; backups are for restore, exports are for data portability.
3. Cloud Scheduler is the primary tool for triggering recurring serverless tasks on Google Cloud.
4. Cloud SQL operations (import/export) are executed by the instance's Service Account, not the user's account.
5. For cross-project imports, you must grant the Cloud SQL Service Account read access (Storage Object Viewer) on the external bucket.
6. Always adhere to the principle of least privilege; do not use public access for private data transfer.
7. Standard IAM roles in Spanner (Reader, Writer) apply to the entire database.
8. Use Fine-Grained Access Control (FGAC) for table-level or column-level restrictions.
9. FGAC uses SQL-based Database Roles (CREATE ROLE, GRANT SELECT).
10. To enforce FGAC, an IAM principal must authenticate with the spanner.databaseRoleUser permission.
11. Cloud Data Fusion provides a visual, code-free interface for building ETL pipelines.
12. Cloud Dataflow requires coding (Java/Python) and is suited for data engineers.
13. Cloud Composer uses Python for workflow orchestration.
14. Datastream is best for CDC and replication, not visual transformation design.
15. Heterogeneous migrations (e.g., Oracle to Postgres) require schema and code conversion.
16. Automated tools like the DMS conversion workspace accelerate the process but manual verification is usually needed for complex code.
17. Native backup/restore tools (like pg_dump) generally do not work across different database engines.
18. Cloud Bigtable offers two storage types: SSD (hot/fast) and HDD (cold/dense).
19. Use HDD storage for large datasets (>10 TB) where low latency is not required, such as archival data or batch analytics.
20. Use SSD storage for most operational workloads requiring predictable low latency.
21. Storage type is chosen at instance creation and cannot be changed without migrating data to a new instance.
22. Cloud SQL is a fully managed service that reduces operational overhead by automating backups, patching, and failover.
23. Compute Engine requires you to self-manage the database, including all maintenance and configuration tasks.
24. Always choose managed services when the goal is to reduce toil and the team size is limited.
25. Monotonically increasing primary keys (like Timestamps) cause hotspots in distributed databases like Spanner.
26. Hotspotting results in uneven resource usage: one node is overloaded while others are idle.
27. Scaling out (adding nodes) does not fix hotspotting on a single split.
28. Key Visualizer is the primary tool for diagnosing access patterns and identifying hotspots (look for diagonal lines).
29. Average metrics can mask individual node issues in distributed systems.
30. Always compare Average CPU with Hottest Node CPU in Bigtable.
31. A large gap between Average and Hottest Node CPU indicates uneven traffic distribution (hotspotting).
32. Hotspots are often caused by poor schema design, such as monotonically increasing row keys.
33. Use Bigtable Garbage Collection to manage live data size and costs automatically.
34. Garbage Collection policies are set at the Column Family level.
35. Backups are distinct from GC and are used for long-term retention and recovery.
36. Always prefer built-in managed features (like GC) over custom deletion scripts.
37. Cloud SQL for PostgreSQL supports standard open-source extensions like pgvector.
38. Use CREATE EXTENSION vector; to enable vector storage and similarity search in PostgreSQL.
39. To minimize refactoring during migration, choose a managed service that matches the source database engine (e.g., Postgres to Cloud SQL for Postgres).
40. Never hardcode sensitive information like passwords in Terraform configuration files.
41. Use the random_password resource to generate secrets dynamically during provisioning.
42. Store secrets in Google Cloud Secret Manager for centralized and secure management.
43. Integrate Secret Manager with Cloud SQL in Terraform to automate secure database provisioning.
44. Heterogeneous migrations (different DB engines) require schema conversion before data movement.
45. The Schema Conversion Toolkit (SCT) translates proprietary database code (like PL/SQL) into open-source compatible formats.
46. Database Migration Service (DMS) is used to replicate data after the schema has been prepared.
47. Cloud SQL Private IP instances live in a managed service provider VPC, not your own VPC.
48. VPC Peering connects your VPC to the managed VPC.
49. Routes to on-premises networks (custom routes) are not propagated to the managed VPC by default.
50. You must enable 'Export custom routes' on the private services access peering connection to allow Cloud SQL to reach on-premises networks.
51. Bigtable autoscaling helps balance cost and performance for variable workloads.
52. CPU utilization is the primary metric for scaling compute-intensive operations like heavy writes.
53. Native autoscaling is preferred over scheduled scripts or manual intervention because it reacts to real-time load changes.
54. Always set a target CPU utilization (e.g., 70%) that allows headroom for sudden spikes.
55. Cloud Spanner is the go-to choice for global applications requiring strong consistency and high availability (99.999%).
56. Cloud SQL is primarily regional; cross-region replicas result in eventual consistency.
57. Cloud Bigtable is for high-throughput NoSQL workloads, not transactional relational data.
58. Strict consistency is critical for inventory systems to prevent overselling.
59. Cloud Spanner compute capacity is defined in Nodes or Processing Units (PUs).
60. 1 Node equals 1,000 PUs.
61. Use PUs (starting at 100) for granular sizing and cost savings on small workloads.
62. The Cloud Spanner Emulator is for local testing, not production deployment.
63. Cloud Spanner has native Backup Schedules; external schedulers are no longer required for standard use cases.
64. Backup Schedules allow you to define recurrence using cron syntax.
65. You can specify retention periods directly in the schedule configuration.
66. Point-in-Time Recovery (PITR) is for continuous protection with a shorter retention limit (max 7 days), not for long-term monthly storage.
67. Use Query Insights as the primary tool for diagnosing query performance issues in Cloud SQL.
68. Avoid manual log parsing for performance aggregation when a specialized visualization tool is available.
69. Distinguish between solving a problem (scaling) and diagnosing a problem (identifying queries).
70. Understand that pg_stat_activity is for real-time snapshots, not historical analysis.
71. High Availability (HA) provides redundancy across zones within a single region.
72. Disaster Recovery (DR) requires redundancy across different regions to survive region-wide outages.
73. Cross-Region Read Replicas are the primary mechanism for Cloud SQL DR strategies, allowing promotion to primary during a regional failure.
74. Firestore creates single-field indexes for all fields by default, facilitating immediate querying but increasing storage and write costs.
75. Unused indexes consume storage space and add overhead to every write operation.
76. Creating single-field index exemptions prevents Firestore from indexing specific fields.
77. Exemptions are the primary method to optimize write performance and storage costs for documents with many unqueried fields.
78. Cloud SQL HA failover preserves the instance's IP address.
79. Existing connections are always dropped during a failover event.
80. Applications must implement retry logic with exponential backoff to handle temporary unavailability gracefully.
81. Cloud Logging has default retention limits suitable for operations, not long-term compliance.
82. Use Log Router Sinks to export logs to other services.
83. Cloud Storage is the preferred destination for long-term, low-cost log archival.
84. Avoid building custom scripts for tasks that managed platform features can handle.
85. Bigtable instances can span multiple regions by adding clusters in those regions.
86. Replication between Bigtable clusters is automatic and eventually consistent.
87. Use Multi-Cluster Routing (in App Profiles) to route traffic to the nearest cluster and enable automatic failover.
88. Single-Cluster Routing pins traffic to a specific cluster and does not support automatic failover.
89. Cloud Audit Logs consists of Admin Activity logs (default on) and Data Access logs (default off).
90. Admin Activity logs track configuration changes.
91. Data Access logs track data reads and writes.
92. Compliance often requires enabling Data Access logs to audit who viewed sensitive data.
93. Datastream is the primary tool for serverless Change Data Capture (CDC) on Google Cloud.
94. Use Datastream for BigQuery when you need to replicate data from operational databases (Oracle, MySQL, PostgreSQL) to BigQuery for analytics.
95. Schema Drift refers to changes in the source structure; Datastream handles this automatically for BigQuery destinations.
96. Avoid using batch processes (like cron jobs or scheduled exports) when near real-time data is required.
97. Memorystore for Redis Basic Tier provides a single node and no high availability.
98. Memorystore for Redis Standard Tier provides high availability using a primary and a replica in different zones.
99. Standard Tier automatically fails over to the replica if the primary zone experiences an outage.
100. Use Standard Tier for production workloads where availability and data persistence are critical.

Book TOC · Previous · Chapter 6 of 6