Memory hook: Choose by access pattern, not by the largest feature list.
Must remember
| Requirement | Candidate |
|---|---|
| Managed familiar relational engine | Cloud SQL; assess engine, HA, replicas and backups. |
| PostgreSQL-compatible demanding enterprise workload | AlloyDB where its architecture fits. |
| Horizontally scalable relational transactions | Spanner, with deliberate schema/key and location design. |
| Document-oriented application data | Firestore, with document/query/index design. |
| High-throughput wide-column/key access | Bigtable; design row keys to avoid hotspots. |
| Analytical SQL over large datasets | BigQuery; separate from OLTP assumptions. |
| Durable object data | Cloud Storage. |
Availability replicas, read scaling and backup/PITR solve different problems. Verify automatic failover behavior, replication scope/lag and tested restoration for the chosen product. A read replica does not necessarily protect against a destructive write replicated from the primary.
Pub/Sub transports asynchronous messages; Dataflow runs Apache Beam batch/streaming processing; Dataproc runs managed Spark/Hadoop-style workloads. Select by existing code, operational burden, state/window requirements and integration. Inspect job status and logs, not merely the existence of a job resource.
BigQuery organizes projects, datasets, tables and jobs. Partition pruning and clustering can reduce scanned data; selecting needed columns and applying suitable filters controls cost/performance. Load jobs, streaming and external data access differ in latency and economics. bq and SQL query tools operate under the actual caller's IAM permissions and chosen processing location.
Migrate data with supported transfer/replication tools, consistent snapshots or exports, schema conversion where needed and a controlled cutover. Match storage/data-processing locations to avoid unsupported operations, latency or transfer cost. Protect secrets, database network access and service identities; a private IP is not database authorization.
Review details
Cloud SQL regional HA maintains a failover standby with synchronous cross-zone protection; it is different from an asynchronous read replica serving read traffic. Read-after-write through a lagging replica can return old state. Spanner supplies strongly consistent relational transactions; Firestore provides strongly consistent document reads/queries and supported transactions. Bigtable supports strongly consistent reads in a single cluster, while multi-cluster replication/routing can introduce eventual consistency. Choose the documented mode rather than equating “NoSQL” with eventual consistency.
Cloud SQL/AlloyDB auth proxies or connectors simplify supported authenticated TLS connections, but do not create a missing private route. Database users/object privileges are separate from cloud-resource administration. Bound application connection pools across maximum instances.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Global relational consistency and scale | Evaluate Spanner rather than treating all SQL services as interchangeable. |
| Petabyte analytical scans | BigQuery with partition/clustering design. |
| Existing Spark pipeline | Dataproc may reduce migration work. |
| Managed event-time stream processing | Dataflow/Beam with appropriate windows and state. |
Traps
- Bigtable row-key design can create severe hotspots.
- BigQuery is not a direct substitute for a high-frequency transactional database.
Active recall
1. Cloud SQL versus BigQuery?
Cloud SQL serves relational application transactions; BigQuery is designed for analytics.
2. Why avoid sequential hot Bigtable row keys?
Traffic may concentrate on a small key range/tablet.
3. What does Dataflow run?
Apache Beam pipelines for supported batch and streaming processing.
4. Does replication replace recovery history?
No. Corruption or deletion can replicate.
5. Why align dataset and processing locations?
To meet compatibility, residency, latency and cost requirements.