Choosing a Database on Google Cloud: A Decision Tree
Database selection questions appear on almost every Google Cloud exam. Here is a decision tree that answers most of them.
Table of contents
Why this keeps appearing
Database selection is a favourite exam topic because it is a genuine judgement call with a defensible right answer. Four options, all of which would technically store the data, and one set of constraints that makes exactly one correct.
It also matters in real work. Choosing wrong is expensive to undo once data and application code have accumulated around the decision.
The decision tree
- 1Is the workload analytical — scanning large volumes for aggregates? → BigQuery
- 2Is it unstructured files, media or backups? → Cloud Storage
- 3Does it need relational transactions, and fit on one machine? → Cloud SQL
- 4Does it need relational transactions AND horizontal write scale or global consistency? → Spanner
- 5Is it very high throughput key lookups over terabytes, with simple access patterns? → Bigtable
- 6Is it application state needing a flexible schema, real-time sync or offline clients? → Firestore
- 7Is it caching or ephemeral session data needing sub-millisecond reads? → An in-memory store
The distinctions people get wrong
- BigQuery is not an operational database. It is superb at scanning a billion rows and poor at fetching one row quickly. If the scenario describes serving a user request, it is the wrong answer.
- Cloud SQL scales reads, not writes. Read replicas distribute read load; every write still goes to one primary. A scenario emphasising write throughput beyond one machine rules it out.
- Spanner is not the premium version of Cloud SQL. It costs substantially more and is correct only when you genuinely need horizontal scale or global strong consistency. Choosing it for a workload that fits on one machine is over-engineering, and the exam penalises that.
- Bigtable has no joins, no SQL and no multi-row transactions. Its enormous throughput comes precisely from omitting them. Any scenario needing transactional correctness across rows rules it out.
- Firestore is not a relational database with flexible fields. It deliberately does not support queries that would scan the whole collection, which is what keeps it fast. You model around your queries.
The constraints that decide it
| If the scenario emphasises | Lean towards |
|---|---|
| Ad-hoc analysis, aggregates, years of history | BigQuery |
| ACID transactions, existing SQL application | Cloud SQL |
| Global, strongly consistent, horizontally scaling writes | Spanner |
| Millions of reads per second, simple key lookups, petabytes | Bigtable |
| Mobile, offline support, real-time synchronisation | Firestore |
| Sub-millisecond latency, caching, session state | In-memory store |
| Migrating an existing MySQL or PostgreSQL app unchanged | Cloud SQL |
Watch the scale numbers
Exam scenarios include volume figures deliberately. Forty terabytes and 500,000 reads per second is not decoration — it rules out Cloud SQL entirely. Two hundred gigabytes and a few hundred transactions per second rules out Spanner as over-engineering.
When you see numbers in a database question, use them. They are almost always the deciding constraint rather than background detail.
Related Certifications
Related Articles
- How to Read a Cloud Exam QuestionCloud exam questions are written carefully. Learning to read them is a distinct skill worth practising separately from the material.
- Grounding or Fine-Tuning? The Question Every AI Exam AsksWhen a generative model gives a wrong answer, the fix depends entirely on why it was wrong. Here is the framework.