3.2.1. Choosing Data Products
💡 First Principle: Data product selection on Google Cloud comes down to answering three questions in order: is this transactional or analytical, is the data structured/relational or flexible/document-shaped, and does it need to scale globally or is a single region sufficient — the answers narrow the field to essentially one correct product.
| Product | Data Model | Best For |
|---|---|---|
| Cloud SQL | Relational (MySQL, PostgreSQL, SQL Server) | Transactional apps needing familiar SQL, moderate scale |
| Spanner | Relational, globally distributed | Transactional apps needing global scale with strong consistency |
| AlloyDB | PostgreSQL-compatible | High-performance transactional + analytical hybrid workloads |
| Firestore | Document (NoSQL) | Mobile/web app backends needing real-time sync |
| Bigtable | Wide-column (NoSQL) | Massive-scale, low-latency time-series or IoT data |
| BigQuery | Analytical warehouse | Large-scale analytics and reporting (OLAP) |
| Dataflow | Stream/batch processing | Transforming and moving data between systems |
| Pub/Sub | Messaging | Asynchronous, decoupled event delivery |
| Memorystore | In-memory cache | Sub-millisecond caching (Redis/Memcached-compatible) |
Dataflow and Pub/Sub aren't storage at all — Dataflow processes data in motion (ETL/ELT pipelines), and Pub/Sub delivers messages between decoupled systems. Google Cloud Managed Service for Apache Kafka serves teams already standardized on the Kafka protocol who want a managed alternative to self-hosting it.
⚠️ Exam Trap: A scenario needing global strong consistency across a relational schema at massive scale is describing Spanner specifically — Cloud SQL tops out at a single region's scale, so a scenario emphasizing "global" and "relational" and "strongly consistent" together nearly always rules Cloud SQL out.
Reflection Question: A scenario describes an application needing real-time data sync across mobile clients with an offline-first experience. Which data product is purpose-built for that pattern, and what rules out a traditional relational database here?
