Choosing a Database - Worked Scenarios
The single most-tested database skill is scenario matching: read a workload and name one product. The decision chart gives the general path; this page walks it end-to-end on three realistic applications. The method is always the same two-step funnel, then a scale/consistency tiebreak:
- What kind of data? Structured (rows and columns), unstructured (images, audio, free text), or both. This picks the family - relational vs NoSQL. When an app mixes both, weigh which dominates; unstructured content usually points to NoSQL, but news or social text that gets processed into scores and keywords is really structured.
- What must the app prioritize? Throughput and latency for real-time interactions, scalability for surging load or large gen-AI indexes, cost, and specialized features like vector embeddings or similarity search.
- Read the tiebreak signals - global scale, strong consistency, HTAP, caching - to land on the exact product.
Scenario 1 - EdTech chatbot (Firestore)
Study Buddy is an AI-powered EdTech chatbot delivering a personalized learning experience. It must store diverse learning content (text, images, videos, quizzes, interactive exercises), manage student profiles and progress, stay responsive under high concurrency, absorb frequent content updates, and serve personalized recommendations.
Student profiles, quiz scores, learning paths, and progress are structured; the learning content itself is unstructured (text, images, video, interactive simulations). Because the content is diverse and evolving, a NoSQL document store beats a relational schema overall.
Scenario 2 - Real-time mobile game (Spanner)
A popular gaming company is building a mobile game with real-time multiplayer battles, a fluctuating in-game currency and item economy, player progression and achievements, and social features (friends, guilds, events).
Chat logs and player-created content may be unstructured, but the core mechanics - player data, currency and items, friend lists and guilds, leaderboards, match history and stats - are structured, and in-game transactions need ACID guarantees. Spanner is globally distributed, horizontally scalable, strongly consistent, and highly available.
You could split the workload - Spanner for core game data, Cloud SQL for less-critical data like player history - to optimize cost. But for a single database that meets every requirement, Spanner is the answer. Firestore (NoSQL) misses the strong-consistency need, and BigQuery is an analytics warehouse, not a low-latency transactional store.
Scenario 3 - Fintech analytics platform (AlloyDB)
MarketMind is a fintech platform offering real-time financial analysis, risk assessment, and investment predictions: it ingests massive market-data streams, runs predictive AI models, personalizes portfolio optimization, detects fraud in real time, and generates automated reports.
The functionality centers on structured data - numerical stock prices, time-series price movements, categorical company classifications. Unstructured inputs like news articles and social sentiment are processed into structured features (sentiment scores, extracted keywords) before the models use them. AlloyDB, especially with its AI capabilities, excels at predictive modeling, personalized portfolio optimization, fraud detection, and automated reporting.
Recap
Match the data shape to the family first, then let the priority signals pick the product.
| Scenario | Data shape | Priorities | Answer |
|---|---|---|---|
| EdTech chatbot | Both (mostly unstructured) | Scale, flexibility, integrations |  Firestore |
| Real-time game | Mostly structured | Low latency, scale, consistency |  Spanner |
| Fintech analytics | Structured | Throughput, scale, AI/ML |  AlloyDB |
Building a gen AI app on top of one of these? See Generative AI workloads for vector search and embedding selection.